So the setting would be something like:
Enable invitations from: TL1</TL2</TL3</TL4/Only admins & moderators
2 Likes
What if one user wants to disable them altogether, while another user wants to allow them from all trust levels?
As the request is for a user preference, if this was implemented as requested each user would have the ability to decide independently.
1 Like
First step is, post a Forum Feedback topic asking people to desist from this. See if that helps, if not, we can look into code fixes, etc.
Muting another user in preferences, if it is a particular problem user, should block invitations as well, we can verify this is the case as well.
1 Like
OK - to be 100% clear, I should ask her to mute anyone who is doing this excessively.
When you say a “Forum Feedback” topic, what exactly do you mean? Like a Meta category post?
Yes, meta, we were afraid people would be scared and frightened of this strange word “meta” so we switched it to Forum Feedback. But same concept! The place you go to talk about the place…
4 Likes
@jomaxro could you verify this is indeed the case? Just to be absolutely sure, because unwanted invites is … unwanted.
This is not the case. I can receive topic invites from a user I have muted in my notification settings.
5 Likes
I believe we should not allow invitations for muted topics as well?
Added a check for muted users and topics. Here is the PR:
7 Likes
A bit off-topic, but I’m wondering what the precedence is when there is a conflict.
i.e. when notification levels are set for Category, Topic, Group and User where one is set say to Watching, but another is set to Mute, which one “wins”?
Pretty sure mute wins but you could test it and be sure if you are curious.
2 Likes
I was discussing with @techAPJ in the PR regarding how we should handle invitations from a user that the target user has muted. The way it is implemented now is that invitation is basically a no-op which means that a user would click invite and nothing would happen. I think this is confusing as my first assumption would be that invites are broken. I have two suggestions on how we can handle this:
-
Check for the users which have muted the current user and remove them from the autocomplete. If the user manually types the username into the form and submits, raise a generic message like “The current user is not accepting invitations at the moment”.
-
Invite the target user into the topic but automatically set the notification level to
muted. This way, we won’t complicate the invitation flow and the target user will not receive any notification.
2 Likes
The issue with this approach might be if a muted user invites another user to a certain topic that topic will become muted for invited user. They will not get anymore notifications from that topic just because a muted user invited them to that topic.
Also in case of PMs, inviting a user will create a small action post which will make other participants believe that invited user is aware of discussion/conversation, however since the invite was from a muted user the invited user will not be aware of the conversation, and moreover the future mentions will not create any notifications if we set notification level to muted for that PM.
This sounds like a better solution but the error message will raise eyebrows and the curious inviter might eventually realize that they have been muted? 
@codinghorror any thoughts about the potential solution here?
6 Likes
I think doing nothing is OK in this condition, I don’t want to overengineer this edge case.
1 Like
We already do this for muted users and PMs. I see the following if I try to PM a user who muted me:
Sorry, jomaxro-test is not accepting messages at the moment.
2 Likes
I personally think we need to at least display an error message here since no one would click a button and expect nothing to happen.
They can just assume the invite was sent, but it wasn’t. I think it’s fine as is.
I think it kind of makes sense to be silent, unless we already have an error message for when you try to invite someone to the same topic two times in a row? Then you would record the invite but not send a notification, so the “you already invited them” message still shows up.
“Not accepting messages” sounds like a reasonable state to be in, and white-lie rationalizing is good here because the whole point is to avoid further interactions.
“Not accepting invites” sounds a bit weird and more likely to tip off an uninformed user that something’s up.
3 Likes
We do but for this case the invite method is a no-op so you’ll get the same behavior even if you try again.
Invite being a no-op will either lead to a bug report or eventually the user will figure out that something is up as well.