| Commit message (Collapse) | Author | Files | Lines |
|---|
|
https://github.com/matrix-org/synapse-dinsic/pull/51 added an option that would automatically bind a user's threepid to a configured identity server after they had registered. Unfortunately, when you bind threepids, ideally you would store that mapping in the database so that later on you can remove those mappings when you deactivate an account.
We found that due the fact that we did not store these mappings, threepids were not unbound upon user account deactivation.
This PR fixes the issue by creating the mappings again, meaning they will again be removed upon account deactivation.
|
|
If the last admin of a room departs, and thus the room no longer has any admins within it, we "freeze" the room. Freezing a room means that the power level required to do anything in the room (sending messages, inviting others etc) will require power level 100.
At the moment, an admin can come back and unfreeze the room manually. The plan is to eventually make unfreezing of the room automatic on admin rejoin, though that will be in a separate PR.
This *could* work in mainline, however if the admin who leaves is on a homeserver without this functionality, then the room isn't frozen. I imagine this would probably be pretty confusing to people. Part of this feature was allowing Synapse modules to send events, which has been implemented in mainline at https://github.com/matrix-org/synapse/pull/8479, and cherry-picked to the `dinsic` fork in 62c7b10. The actual freezing logic has been implemented here in the RoomAccessRules module.
|
|
This PR allows Synapse modules making use of the `ModuleApi` to create and send non-membership events into a room. This can useful to have modules send messages, or change power levels in a room etc. Note that they must send event through a user that's already in the room.
The non-membership event limitation is currently arbitrary, as it's another chunk of work and not necessary at the moment.
This commit has been cherry-picked from mainline.
|
|
Bug introduced in https://github.com/matrix-org/synapse-dinsic/commit/ff91a451b
We were checking whether the `nextLink` param was valid, even if it wasn't provided. In that case, `nextLink` was `None`, which would clearly not be a valid URL.
This would prevent password reset and other operations if `nextLink` was not provided and the `next_link_domain_whitelist` config option was in use.
|
|
|
|
|
|
#8037 changed the default `autoescape` option when rendering Jinja2 templates from `False` to `True`. This caused some bugs, noticeably around redirect URLs being escaped in SAML2 auth confirmation templates, causing those URLs to break for users.
This change returns the previous behaviour as it stood. We may want to look at each template individually and see whether autoescaping is a good idea at some point, but for now lets just fix the breakage.
|
|
this makes it possible to use from the manhole, and seems cleaner anyway.
|
|
I'd like to get a better insight into what we are doing with respect to state
res. The list of state groups we are resolving across should be short (if it
isn't, that's a massive problem in itself), so it should be fine to log it in
ite entiretly.
I've done some grepping and found approximately zero cases in which the
"shortcut" code delivered the result, so I've ripped that out too.
|
|
|
|
This will allow us to hit the DB after we've finished using the generated stream ID.
|
