OF-2760: Adds option to retire a MUC room name on deletion #2630
Conversation
Tomb-stoning a room means that this room's name is retired on room deletion and cannot be used again. Where a MUC may have particular meaning to plugins or to other systems, assume that deletion is explicit and intentional. Do not allow the MUC name (and so JID) to be repurposed, preventing impersonation / corruption / access of MUC history, or other unforeseen side effects.
- Renames "tombstone" to "retire" everywhere - Adds admin page to list & delete retired rooms
viv
changed the title
xmppserver/src/main/java/org/jivesoftware/openfire/muc/MultiUserChatManager.java
Outdated
Show resolved
Hide resolved
xmppserver/src/main/java/org/jivesoftware/openfire/muc/MultiUserChatManager.java
Show resolved
Hide resolved
xmppserver/src/main/java/org/jivesoftware/openfire/muc/spi/MUCPersistenceManager.java
Show resolved
Hide resolved
Makes it more clear that deleting a retiree is bringing it out of retirement.
Adding the service ID to the log could help chase down issues.
Only setting the fetch size is not sufficient to prevent the entire result set from being loaded in memory (at least not for MSSQL). That requires a bit more configuration of the query/result set, added in this commit.
This data is not yet exposed on the admin console retirees page.
I'll pick this up on Monday morning. |
This change helps admins better understand and manage retired rooms. - Created MUCRoomRetiree.java for structured data access - Updated MultiUserChatManager to expose new fields - Enhanced muc-room-retirees.jsp to display additional information
|
I think this is ready for another review. |
|
Rooms that are non-persistent but do have 'retire-on-delete' set, do not retire. I think in principle, the setting should be honored. It might be desirable to have a different default setting for 'retire-on-delete' for persistent vs. non-persistent rooms (but I'm happy for that improvement to go in a new ticket). |
|
The 'retire-on-delete' option should be changeable through the room configuration form. In the screenshot below a new config setting that we've recently added does pop up, but not 'retire-on-delete'.
|
I've re-reviewed it, and left some suggestions to be improved in this PR, but also raised a couple of tickets for us to tackle outside of the scope of this PR (OF-2933, OF-2934). Are you aware of the 're-request review' functionality in GitHub? That has the benefit of sending out all the required emails etc. |
With this change rooms that are non-persistent, but do have 'retire-on-delete' set, will be retired when they are deleted.
Retiring a room means that this room's name cannot be used again after the room is deleted.
Where a MUC may have particular meaning to plugins or to other systems, assume that deletion is explicit and intentional. Do not allow the MUC name (and so JID) to be repurposed, preventing impersonation / corruption / access of MUC history, or other unforeseen side effects.