Description of the need
It would be helpful to have additional permissions that control whether a role can view
(a) the user profile of a blocked user (b) any content that had been created by a blocked user
The need arose in connection with backdropcms.org, where potential spam accounts are (manually) blocked (based on various indicators of potential spamminess), and then blocked accounts are automatically deleted after two weeks. (The reason for not deleting them immediately is to avoid deleting a valid account that just looked spammy; with the delayed deletion, it gives the owners of real accounts a chance to flag the improper blockage before everything goes away.)
During the 2-week blockage, the user accounts are still accessible by anonymous users and show up in Google searches, etc. It would be nice if during the "penalty box" of account blockage, the blocked account was not publicly accessible. And along the same lines, if a blocked account had created additional content, it would be nice to have the option of blocking content that had been created by blocked accounts (similarly to the existing ability to delete content from an account when that account is deleted).
Proposed solution
In the User permissions section, there is a "View user profiles" permission. We could add a permission "View blocked user profiles" that is initially checked by default (to match current behavior) but that could be unchecked to hide blocked user profiles. We'd then need to change "View user profiles" to "View unblocked user profiles" (at least the display name, but presumably not the machine name).
In the Node permisisons section, there is a "View published content" permssion. We could add a permission "View published content from blocked users" that (like the above) is initially checked by default (to match current behavior). Same considerations would apply, e.g., making the original permission "View published content from unblocked users".
There may well be better names and splitting of permission functionality than the above; suggestions solicited.
Alternatives that have been considered
In the case of backdropcms.org, an alternative would be just a change of policy: if a user account is so obviously spammy that we don't want it visible, we could just go ahead and delete it immediately, and only use the "block-now, delete-later" approach for questionable accounts. But it seems like having the ability to distinguish visibility between blocked and active accounts would be a good and useful thing overall.
H/T @olafgrabienski.
Recent comments
Ruby Text can be a bit of a hassle to edit... Yes, I can imagine that. No idea, how an editor dialog (or whatever) for easier editing of those should look like - in terms of...
Specific tags to work in CKEditor 5
"why are these tags only relevant for admins?" I'm allowing the editor as well. That being said, Ruby Text can be a bit of a hassle to edit... easy to accidentally delete a tag or part of a...
Specific tags to work in CKEditor 5
Out of curiosity: why are these tags only relevant for admins? Don't "regular" editors on that site also need them under circumstances? Yes, the editors play nicely, no problem to...
Specific tags to work in CKEditor 5