You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although I'm testing this on the develop branch, I have database changes locally, related to the luap42/moderator_tools_improvements branch, so it would be useful if someone who has not tested that branch could confirm my observations on the develop branch. I'm not expecting that to be related but it would be good to have independent confirmation.
As a network admin, you can grant a user roles, including making them a community moderator or admin, or a network moderator or admin. You can also revoke each of these roles.
This process appears to be broken. Some abilities trigger changes in other abilities, but not the expected abilities. Some clicks on buttons make background changes that do not show up until you press another button afterwards. It's like playing a puzzle game.
It might be expected that granting network moderator would also grant community moderator. It does. However, it also grants community admin.
It might be expected that granting network admin would also grant community admin, and possibly network moderator. It grants neither of these, but does grant community moderator.
It might be expected that granting community admin would also grant community moderator. It does. However, it does not grant community admin (that's not a typo - it does not grant itself). That is, the button being pressed (grant community admin) grants only community moderator, and not community admin. Repeatedly clicking on community admin has no effect on that button, but does switch on and off community moderator. Clicking on grant or revoke community moderator only works if the community admin button has not been used, otherwise the community moderator button has no effect until the community admin button is pressed again, at which point the community moderator button goes back to working as expected.
To Reproduce
Go to the user profile page.
Click on "Moderator Tools".
Click on "privileges".
Scroll to the bottom of the page and try various combinations of the buttons under "Roles".
Expected behavior
To be discussed. Clearly what I describe above is not the correct behaviour, but there are several potential ways to make this work. Which is most intuitive is probably subjective. Whichever approach is chosen, my concern is that it be made clear and unambiguous.
When revoking network admin, should this also revoke community admin on every community? Intuitively, some might expect the answer to be "yes" if community admin was only a side effect of network admin, but "no" on any communities where community admin was already granted before network admin was granted. I can also imagine cases where someone would want to remove community admin on all communities at once, even if granted before network admin. Ideally the interface would cater to both situations. Similarly for revoking network moderator.
In addition to making these actions available, ideally the interface would make the consequences clear so that the system is not left in an unintended state. For example, if revoking network admin on a page that only shows network admin and community admin for this one community, then the revoker does not know whether community admin has also been revoked on other communities, and different revokers may make different assumptions. Could we list all of the communities on this page, so it is immediately clear what side effects each action has? This way a granter or revoker will not be relying on their own intuition about how the system should work, but will see clearly any places that do not match their expectation so they can override per community as necessary.
The text was updated successfully, but these errors were encountered:
Describe the bug
Although I'm testing this on the
develop
branch, I have database changes locally, related to theluap42/moderator_tools_improvements
branch, so it would be useful if someone who has not tested that branch could confirm my observations on thedevelop
branch. I'm not expecting that to be related but it would be good to have independent confirmation.As a network admin, you can grant a user roles, including making them a community moderator or admin, or a network moderator or admin. You can also revoke each of these roles.
This process appears to be broken. Some abilities trigger changes in other abilities, but not the expected abilities. Some clicks on buttons make background changes that do not show up until you press another button afterwards. It's like playing a puzzle game.
To Reproduce
Expected behavior
To be discussed. Clearly what I describe above is not the correct behaviour, but there are several potential ways to make this work. Which is most intuitive is probably subjective. Whichever approach is chosen, my concern is that it be made clear and unambiguous.
When revoking network admin, should this also revoke community admin on every community? Intuitively, some might expect the answer to be "yes" if community admin was only a side effect of network admin, but "no" on any communities where community admin was already granted before network admin was granted. I can also imagine cases where someone would want to remove community admin on all communities at once, even if granted before network admin. Ideally the interface would cater to both situations. Similarly for revoking network moderator.
In addition to making these actions available, ideally the interface would make the consequences clear so that the system is not left in an unintended state. For example, if revoking network admin on a page that only shows network admin and community admin for this one community, then the revoker does not know whether community admin has also been revoked on other communities, and different revokers may make different assumptions. Could we list all of the communities on this page, so it is immediately clear what side effects each action has? This way a granter or revoker will not be relying on their own intuition about how the system should work, but will see clearly any places that do not match their expectation so they can override per community as necessary.
The text was updated successfully, but these errors were encountered: