Skip to content
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

Users who can't use PMs still have send PM options shown to user others #3031

Closed
Spuds opened this issue Oct 26, 2017 · 3 comments
Closed

Users who can't use PMs still have send PM options shown to user others #3031

Spuds opened this issue Oct 26, 2017 · 3 comments
Milestone

Comments

@Spuds
Copy link
Contributor

Spuds commented Oct 26, 2017

https://www.elkarte.net/community/index.php?topic=4731.msg34183

@Spuds Spuds added this to the 1.1.1 milestone Oct 26, 2017
@emanuele45
Copy link
Contributor

I tried these combinations:

  1. denied "read" denied "send" => no trace of the buttons
  2. given "read" denied "send" => menu entry with "read messages" still accessible, no trace of "send"
  3. denied "read" given "send" => the menu disappears but the send in the "mini profile" appears

Number 3 is slightly odd, though it's also an odd configuration to begin with, the only thing I can come up with is some check that specifically disable the "send" permission if the "read" is not set.

@emanuele45
Copy link
Contributor

Okay, more details: the issue is that when a member cannot read PMs, any other member that can send PMs will still be able to send that user a PM.
So:

  • User A has permission to read and send PMs
  • User B does not have permission to read PMs
  • User A is still able to send PMs to user B

As such, it is not a bug, because the behaviour has been like that since the beginning, so => feature request

Now, on the feature matter, I think the idea behind this behaviour is that admins sometime use to remove the read PM permission to for example banned members, and if other people would not be able to send them PMs, the status would be somehow revealed.
That said, I'm neither in favour nor, against the change, to me it's the same (especially considered most admins are actively searching for ways to mark the banned members as such).

@Spuds
Copy link
Contributor Author

Spuds commented Apr 13, 2024

Going to close as will not implement

@Spuds Spuds closed this as completed Apr 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants