Hide user details from certain body users

[jonkri]

Is your feature request related to a problem? Please describe.

It may not be necessary for certain body users to see user details, such as who has reported problems or made updates to reports.

For example, a municipality may work with a company to fix street lights, where the company may want to have a FixMyStreet account (to work with shortlists for example) but may not need to see who has created the reports.

Describe the solution you'd like

A user role which is not able to see user details (when users have created reports or updates anonymously).

Describe alternatives you've considered

We tried removing the Markup problem details role from these accounts. This did seem to hide the email but also seemed to cause the accounts to disappear from the assignment dropdown (see #4970).

Additional context

This would have benefits in terms of privacy.

[dracos]

As you say, without the report_inspect permission they probably can't see user details - so the issue then becomes that other ticket, if I understand it right? There's nothing to do if that ticket were dealt with, I mean.

[jonkri]

Thanks for getting back to us, @dracos!

Unfonrtunately, no.

We would prefer not having to remove the report_inspect (Markup problem details) role if possible.

Otherwise the users that cannot see the user details are unable to do things like change category, change status, make assignments, set priorities or provide detailed information.

[dracos]

So it's only the bit of the inspector form that shows user details that's the issue? I think that permission has always assumed it can see user details. I can't think of a particularly easy way of splitting that out, nor what it could be called (though having it actually /work/ seems quite straightforward, on the other hand). You could I guess have a 'negative' permission "Inspector who cannot view user details" that then hid that part of the blue form page, but that's not particularly nice. If we made it so inspectors couldn't see it by default and added a "User can see report's user details" permission, I guess that's nicer in a positive permission sense, but we'd have to migrate every current user to have that permission, which is bit fiddly but doable.
Do you have any users who you'd want to have report_inspect but not e.g. report_edit? Could you have it so on your cobrand it didn't show user details in the inspector form to anyone who didn't have both those permissions, perhaps?

[jonkri]

So it's only the bit of the inspector form that shows user details that's the issue?

Yes (but, unrelated to this issue, it would be nice to have more granular control over who can do what).

I think that permission has always assumed it can see user details. I can't think of a particularly easy way of splitting that out, nor what it could be called (though having it actually /work/ seems quite straightforward, on the other hand). You could I guess have a 'negative' permission "Inspector who cannot view user details" that then hid that part of the blue form page, but that's not particularly nice. If we made it so inspectors couldn't see it by default and added a "User can see report's user details" permission, I guess that's nicer in a positive permission sense, but we'd have to migrate every current user to have that permission, which is bit fiddly but doable.

I agree with the positive permission thing. I think it should be opt-in rather than opt-out so that these details can't be viewed by default.

So I think making it so inspectors can't see it by default and add a "User can see report's user details" permission would be the best way forward.

Do you have any users who you'd want to have report_inspect but not e.g. report_edit? Could you have it so on your cobrand it didn't show user details in the inspector form to anyone who didn't have both those permissions, perhaps?

We're actually not using the report_edit permission at all. Body users can moderate reports but actual editing is done by our admin. Every now and then we hide (test and spam) reports or receive GDPR requests which require editing reports, but it's quite rare.