-
Notifications
You must be signed in to change notification settings - Fork 56
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
Better power level checking, part 1 #799
Conversation
Quality Gate passedIssues Measures |
is it expected that this breaks compilation of code like
|
Rather not; I'll check what's going on. |
Checking whether an event is a state event only makes sense in room context, hence the moving. As for Quotient::isStateEvent(), this checks an event type id against known event types that are derived from StateEvent; the function will be used to simplify the API to check power levels in a later commit.
Allows to use designated initialisers, see the next commit.
This commit makes RoomPowerLevelsEvent _always_ available via currentState() - no need to query()/queryOr(), just get() and safely access all the members. This is possible because the spec defines default power levels for all kinds of cases; we can just inject a synthetic RoomPowerLevelsEvent object with those defaults into currentState() and once the real event comes (either from the homeserver or from the cache) it replaces the synthetic one by normal means of state processing. Thanks to that, Room::memberEffectivePowerLevel() implementation becomes much simpler; and to match it on the other side of power level checks, Room::powerLevelFor() is introduced as a unified call returning the power level necessary to send any specific event type, state or not.
c57e97a
to
0a2543f
Compare
Ok, I didn't intend to break the legitimate things; that being said, this one is not quite legitimate. Below is the write-up for documentation's sake; TL;DR is that you should avoid using empty JSON to initialise events, since pre-0.8 you should be able to "default-construct" (most of) them with an empty list of arguments instead. So, unimportant historical details: what used to be happening before is the empty Back to important stuff. To provide cross-compatible code, I can suggest explicitly creating a |
This was introduced in #799, only accidentally passing through tests.
This PR is the first, API-breaking, part of additional facilities to simplify answering a question "am I allowed to do X?". While porting Quaternion to libQuotient 0.9, I thought that it would be great to have something like
Room::canRedact()
- turned out though that actually figuring out whether you can redact a certain event is not that easy to answer (and the spec doesn't seem to be very clear in that part). So I will proposecan*()
methods as an API/ABI-compatible addition after 0.9.0 is out (once I make them right) but here's some groundwork that needs to come in 0.9.0.