Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Creating and deleting aliases could be more consistent #7320

Open
clokep opened this issue Apr 21, 2020 · 0 comments
Open

Creating and deleting aliases could be more consistent #7320

clokep opened this issue Apr 21, 2020 · 0 comments
Labels
T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks. z-p3 (Deprecated Label)

Comments

@clokep
Copy link
Member

clokep commented Apr 21, 2020

This is the promised follow-up to #7052 about how to creating and deleting aliases could be more consistent. In general these are implemented via the create_association and delete_association methods of DirectoryHandler.

The checks done for each of these (copied from #7052 and clarified a bit) below. They're a bit confusing (and maybe make more sense as the flow-charts I wrote out), but the overall checks aren't too complicated.

Creation

  1. Check if the length is valid.
  2. If require_membership_for_aliases is true in the config, the creator must be in the room or be a server admin.
  3. The spam checker's user_may_create_room_alias method is queried.
  4. The alias_creation_rules are checked from the config.
  5. Services are checked to see whether they have an "exclusive lock" on an alias.

Deletion

  1. Ensure that the user is the room creator, if one exists.
  2. Ensure that the alias points to a room ID.
  3. The user must be one of the following:
    1. A server admin.
    2. In the room and have sufficient power level to delete an alias (>= moderator).
  4. Services are checked to see whether the have an "exclusive lock" on an alias.

Potential improvements

There aren't too many changes I came up with, but see ideas below:

  1. Check require_room_membership_for_aliases during alias deletion.
  2. Ensure that a user has the proper power level during creation (but that probably only makes sense for the canonical alias, which already happens).

There's a chance that some of the code could be re-used by combining some of the checks, but probably not. Frankly this might just be good enough the way it is.

@clokep clokep added the z-p3 (Deprecated Label) label Apr 21, 2020
@reivilibre reivilibre added the T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks. label May 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
T-Task Refactoring, removal, replacement, enabling or disabling functionality, other engineering tasks. z-p3 (Deprecated Label)
Projects
None yet
Development

No branches or pull requests

2 participants