Closed clarkwinkelmann closed 1 year ago
🤔 this is unfortunate indeed, best thing to do is accept that existing users are in the discussion and don't check their block state at all..
The best workaround might be to list which of the users are not allowed in the error message so you know who to kick out.
The information is public already because you can search users via the api with the filter to know which one allowed messages anyway.
Any progress with this?
I don't think anyone is actively working on it unfortunately.
We just noticed this as well here at @glowingblue. And apparently, a user who blocks PMs, cannot send PMs to anyone, as he would be in the recipient list and therefore gets a 403 error no matter what!
(cc @imorland)
On dev-master, users can block PMs.
When checking if recipients allowed PMs, every user is checked, including those already in the recipients list.
So suppose a private discussion with many recipients. At one point after the creation of this discussion, one or multiple of the recipients have changed their settings to "block private messages". Nobody is admin.
Later, one of the members wants to add a new recipients. This will fail with "you don't have permission to do that", because one of the existing members has disallowed PMs.
Additionally you have no way of knowing which users have blocked PMs, so you must try removing them one by one, or remove everyone and re-add them one by one :sweat_smile:
Currently it's not possible to observe the situation because admins can always add or remove users who blocked PMs, and #36 prevents non-admins from trying. But I just reproduced this locally after making the simple fix to workaround issue #36 on my local install