Fix power levels being incorrectly set in old and new rooms after a room upgrade #6633
Conversation
synapse/handlers/room.py
Outdated
| power_levels["users"][requester.user.to_string()] = needed_power_level | ||
| # Perform a deepcopy of the dict in order to not modify initial_state, as its | ||
| # contents are preserved as the state for the old room later on | ||
| initial_state = copy.deepcopy(initial_state) |
There was a problem hiding this comment.
Do we really need to copy the entire state rather than just the power levels event?
(it might also be preferable just to copy the bits we know we want from the PL body)
There was a problem hiding this comment.
Changed to only deepcopy the power levels state. Let me know what you think.
|
Can we also have a test case for this? This way we ensure the fix works as intended and doesn't break in the future. |
|
I am not sure this is a good idea, because this is currently the only method to get control of IRC rooms that are managed entirely by e.g. matrix-appservice-irc, matrix-org/matrix-appservice-irc#408. Also if PL100 was required for upgrading rooms, only the appservice would be able to do that and I am not certain it's a good idea. |
|
@Mikaela you can still manually upgrade rooms and set whatever power levels you like when creating the new room: https://gist.github.com/turt2live/a99c8e794d6115d4ddfaadb72aabf063 |
Added tests. |
synapse/handlers/room.py
Outdated
| power_levels["users"][requester.user.to_string()] = needed_power_level | ||
| # Perform a deepcopy in order to not modify the original power levels in a | ||
| # room, as its contents are preserved as the state for the old room later on | ||
| existing_power_levels = initial_state[(EventTypes.PowerLevels, "")] |
There was a problem hiding this comment.
we've already got this, in power_levels (line 359)
Fixes #6632
Sytests: matrix-org/sytest#777
Fixes a bug introduced in #6237 where in which a moderator in a room upgrades the room, the following oddities occur:
Turns out the problem was due to modifying
initial_state, which was a dictionary representing the state of the old room. This modified object continues to persist however, and later on in_update_upgraded_room_pls, when we attempt to send a power level event to mute users in the old room, we end up grabbinginitial_stateagain, which contains the Mod as an Admin instead. At this point, the Mod is set to an Admin in the old room.Additionally, the way we downgrade the Mod back from an Admin to a Mod in the new room, is by simply applying the old room's power levels once again. But, since we're using the modified power levels object, which had the Mod as an Admin, the Mod remains an Admin in the new room.
Performing a deepcopy instead solves both of these problems.