Community account mute does not work

Communities have two level of mutes, post level and account level. Currently post level mutes work, account level does not work.

Prior to recent Hivemind updates, account level mutes worked by assigning the muted role to an account. This was a feature I have personally used a lot in the past to mute known spammer accounts across multiple communities.

Currently, assigning the muted role to a user does not mute their content from the community.

@Marky Could you provide us exact call which returns bad response ? Also expected one (i.e. taken from previous version) would be very useful.

assigned to @ABW

@pczempiel Please create test plan and testcases covering definition of community related posts including impact of the role associated to author account in given community.

I'm not sure if JOURNAL (hive-2...) or COUNCIL (hive-3...) types of communities work - if they do, there is special treatment for them regarding this topic and we'd need extra tests for them.

The tests should contain at least one account writing to various communities:

• marked as member before posting (at least 3) articles and (at least 3) answers to some post in community1
• no role (guest) before posting articles and answers to some post in community2
• marked as muted before posting articles and answers to some post in community3

For each of above communities we now mark selected (but not all - one needs to be left in default state) articles/answers as muted (even if they are already marked as such). In next step we unmute half of them.

Now we change role of the account to muted and let it post articles/answers again. Same steps for muting/unmuting selected posts. Finally we change role to member and repeat the process for the third time. All above repeated for JOURNAL/COUNCIL communities in case they work.

As extra we could have one more account that is member (or more) in each of above communities. That account should post replies to each of the post of main account to check if it is properly getting notifications in case it replies to muted posts.

Ech, one more scenario to check: does editing of post update the muted flag or it keeps its previous value? That means we need the account to produce at least one extra article/answer when it is muted/unmuted and edit it after he becomes unmuted/muted.

Wouldn't it be better to just mute/unmute all posts by the author in the community depending on the mute state of the account? Or is this too expensive for some reason? Unless it's much more expensive, I think this would be more desirable behavior.

Post mute state represents an account mute property value at the time post has been created (or edited - here we have doubts but seems reasonable). When we change it to muting/unmuting all posts at account property change time, all past posts will show up if some account will be unmuted in the future.

Yes, I think the above would be better behavior. Note this behavior would also be consistent with how individual (non-community) account muting currently works.

So far, the general opinion of respondents in mattermost is that we should change the behavior so that community muting of posts based on account muting matches the current mute/unmuted state of the account in the community (i.e. as per my suggested change).

I agree muting all posts by author when an author is muted is the expected and preferred behavior.

Just to make sure - the old behaviour (when it was still working) was the following:

• muting mechanism was based solely on property of the post - the post was muted or regular
• default value of muted flag was set based on community type and author role (that part is what is not working right now)
• on top of that, each post could be muted or unmuted individually later with explicit operation

Because author role influenced post's mute flag only at the moment of post creation (or edit?), it meant the following:

• X posted A, B, C to community - regular posts, all visible
• X was marked as muted for the community - A, B, C had to be individually marked as muted with explicit operations, but could be left visible
• X posted D, E, F - posts automatically marked as muted, but could be explicitly unmuted
• X returned to the path of light and was assigned member but the posts he created previously retained their muted flag

The new solution requires changing all API calls to check for current role of the author. It will mean the following changes to the above example:

• marking X as muted automatically makes all his posts behave as if they have individual muted flag set, even though it remains unchanged; even if you try to explicitly unmute some of his posts they will still be effectively muted
• accepting X back as member will make all his previous posts visible (unless they were individually muted)
• in other words post of X is visible if both is true: post is not marked as muted and author is not marked as muted; the solution is based on value of both flags, not just the one held with post

There is alternative, but bad solution. It keeps one-flag-source of original solution, so it does not require changes in API calls.

• at the moment X is marked as muted we scan all his community posts and mark them as muted
• when he is cleared of his muted status we do the opposite

This might cause (exploitable) performance problems but it allows for some posts of muted author to be made visible in the community (when they are explicitly unmuted after author becomes muted).

The new solution is the desired one.

I second this. The "new solution" is simple to understand from a user perspective and the easiest to implement.

New solution will be implemented once @pczempiel prepares tests, however "easiest to implement" couldn't be further from truth :o) Like I said, it requires reviewing all API calls to see which ones react on is_muted post flag and adding condition on author role (possibly requiring extra join which might mean slowing down the query). Restoring previous behaviour would mean changing order of two calls in python and passing one more flag to insert query (fast change) or embedding community validation code for post into post inserting procedure (more work but better and could potentially speed up sync - might be worth doing anyway).

mentioned in issue #125 (closed)

mentioned in issue tasks_without_projects_yet#33 (closed)

The issue for muted-users comments not being hidden (eg. phishing) is still there but also..

Currently post level mutes work

..please note that this is not correct (anymore?).

Example:

@b0t5-t3sting is muted in the community https://hive.blog/created/hive-166109

Its post is not muted though:

Link to the non-muted post: https://peakd.com/hive-166109/@b0t5-t3sting/i-really-hope-that-this-post-is-not-hidden-because-i-want-all-your-private-keys

---

PLEASE ALSO NOTE that for some reason the following post of the admin of that community.. is muted! https://hive.blog/hive-166109/@cryptoriddler/schloss-neuhaus

Thx!

PS. the weird tag names used to test for XSS have nothing to do with these muting issues, the same were reproduced in another community as well.

mentioned in issue tasks_without_projects_yet#36 (closed)

Done in !490 (merged)

closed