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
When logged in: On a page with a path prefix it shows the language of the prefix. On the front page if I add the path prefix it shows the language of that prefix...
Language negotiation only working when logged in
Hi! The description is still very vague and lacks step-by-step instructions on how to reproduce. It doesn't include the version of Backdrop either, nor a list of contrib modules you are using...
Problems with HTML content and text formats
Sorry, it did seem confusing when I read it back... So if I add some html to a text field, for example in a page or a block, whatever the text format of the field may be (raw html or basic...
Problems with HTML content and text formats