This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix adding excluded users to the private room sharing tables when joining a room #11143
Fix adding excluded users to the private room sharing tables when joining a room #11143
Changes from 7 commits
ed6bcec
60587bd
6b19eda
2a3c396
6238017
00c5d9e
56809e9
67f6373
02354e5
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it valid to register using a full user ID?
I guess it is since you're doing it, but it doesn't match the style above and draws too much attention to the server ID in the user ID (this isn't a remote user, right?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is cribbed from old tests, see e.g. here which I think is circa three years old.
I still don't really know how support users get created in actual usage. (If it's "make a normal user, then mark them as support in the DB", they'll get added to the directory on registration and then not removed when made support.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I see.
I did not notice you were using
self.store.register_user
here and notself.register_user
.I think (hope) that support users are born that way (e.g. using a CLI flag, or an admin GUI tool that will do shared-secret registration?):
Maybe we should one day extend
self.register_user
to allow passing a user type (it uses the shared-secret registration API, to my surprise — we could likely crib from the script linked above to add support under an optional kwarg).Happy for you to leave as-is if you like though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In keeping with remark above, I would probably prefer to do the invite & join dance rather than injecting the event (as surely the support user is a local user?). Maybe I'm being a hypocrite and we already do this nearby? :P
Though I do think I prefer to reserve injecting events for when we have to (e.g. simulating remote events or invalid events that we've already persisted for some reason)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a hypocrite. I do this elsewhere, but only because I don't know how to do better (as in the other comment).
I could use an appservice user instead. They're easy enough to register. (Though there is talk of not excluding AS users in the future..._
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leaving it at a support user seems sensible.
You can try
(these helpers sometimes work without access tokens. I'm not sure what the conditions are for that (seems to be controlled by a flag
self.hijack_auth
...), but if the above works, happy days. Otherwise, I guess we leave it as-is until we add user types support toself.register
...)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do this in a few places when trying to test room joins etc from support and deactivated users. But that's only because I didn't know how to do it better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No bueno I'm afraid:
I think that hijack mechanism only kicks in for one nominated user on the test case class.
So I think it might be best to (regrettably) leave this as it is for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough! Thanks for entertaining it anyway :)