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.

GitHub Issue #: 
6123