Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OF-2916 and OF-2917 Add the option to control MUC history preservation #2621

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

hqv126
Copy link
Contributor

@hqv126 hqv126 commented Nov 26, 2024

No description provided.

“Huy added 5 commits November 26, 2024 13:48
…cRoom table creation scripts. This new field determines whether a room's chat history is preserved or removed upon its deletion.
…e MUCRoom class so it can be accessed during runtime.
…r to use the new preserveHistOnRoomDeletion field for processing room configuration.
…Manager to load and store room settings and history, incorporating the new preserveHistOnRoomDeletion field. 2. Add functionality to remove room history stored in ofMucConversationLog upon room deletion. 3. Add the new preserveHistOnRoomDeletion field to the MUC default room settings screen, as well as to the room edit and creation screens.
Copy link
Member

@guusdk guusdk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this! I've left some pointers in-line.

I assume that you deliberately didn't include code yet that actually makes use of the new setting that is introduced here?

@@ -278,6 +278,12 @@ private void processConfigurationForm(@Nonnull final DataForm completedForm, @No
room.setPublicRoom( parseFirstValueAsBoolean( field, true ) );
}

field = completedForm.getField("muc#roomconfig_preservehistondel");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This commit introduces a new form field, named muc#roomconfig_preservehistondel. As Openfire is an implementation of the XMPP standard, form named carry significance.

When creating a new field, the name should follow the guidelines as defined in https://xmpp.org/extensions/xep-0068.html#approach-fieldnames

Specifically:

he "namespace" of a field is assumed to be inherited from the FORM_TYPE. When an organization or project defines a field that is used in the context of a FORM_TYPE it does not manage (e.g., a non-XSF field contained in a form whose FORM_TYPE is managed by the XSF, or a third-party field contained in a form whose FORM_TYPE is managed by some other organization), the name of the field MUST be namespaced using Clark Notation [8], where the universal name portion SHOULD be a URI controlled by the extending organization or project, e.g., a field name of "{http://example.com/pubsub}time_restrictions".

Let's use something like {http://igniterealtime.org}muc#roomconfig_preservehistondel (or any better suggestion that you may have).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks guus, think I have made this change now.

fmucOutboundNode VARCHAR(255) NULL,
fmucOutboundMode INTEGER NULL,
fmucInboundNodes VARCHAR(2000) NULL,
serviceID INTEGER NOT NULL,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please change only the line that needs changing, instead of the entire table definition. Such a large change makes it difficult to track what the relevant change is.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The scripts use indentation for alignment. Since preserveHistOnRoomDeletion is a longer name, the indentation was adjusted. Don't you want to preserve alignment?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe use a shorter name?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I've added a shorter name.

fmucOutboundNode VARCHAR(255) NULL,
fmucOutboundMode INTEGER NULL,
fmucInboundNodes VARCHAR(2000) NULL,
serviceID INTEGER NOT NULL,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Openfire database scripts are versioned. When it is changed, a couple of things are needed:

  • the version number of the script needs to be increased (the version is found near the end of the file, it is currently 34 but should be 35)
  • a database update script should be added, in a new directory that is matches the update number (35). This script should update a pre-existing database (version 34) to version 35.
  • The Openfire code should be modified to start using the new version (instead of the old version). This is defined as a simple constant value in the SchemaManager class.

For inspiration, look at commits that have added database changes in the past, like this one: bf1382c

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks guus, think I have made the additional changes now.

@hqv126
Copy link
Contributor Author

hqv126 commented Nov 27, 2024

Thanks for this! I've left some pointers in-line.

I assume that you deliberately didn't include code yet that actually makes use of the new setting that is introduced here?

MUCPersistenceManager was changed to make use of the chat history preservation setting. Is this what you are asking about?

“Huy added 2 commits November 27, 2024 14:51
Add a preserveHistOnDel field to the OfMucRoom table to specify chat history preservation on the deletion of a chat room.
Updated MUCPersistenceManager to make use of the new preserveHistOnDel field.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants