Added view/edit user contact information permission (take 2)#18903
Open
Added view/edit user contact information permission (take 2)#18903
Conversation
…rmission to edit censitive fields
snipe
changed the title
Not up to standards ⛔🔴 Issues
|
| Category | Results |
|---|---|
| UnusedCode | 2 medium |
🟢 Metrics 92 complexity
Metric Results Complexity 92
TIP This summary will be updated as you push new changes. Give us feedback
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
(I had tried this before, but too much changed since then so I just started again, building off what I had before.)
This is primarily targeted towards special cases such as domestic violence centers where a stalker might end up volunteering for the shelter. This allows the volunteer to be able to edit basic information, checkin/checkout assets, etc - but they cannot see or edit the users':
This also fixes #18659.
This thing is an absolute beast, but I had to make sure I wasn't missing any potential spots where we could leak information. I've added a ton of tests to hopefully prevent any regressions.
This adds a migration to automatically add the
users.contactpermission to any user/group who hadusers.editaccess, because this permission is more restrictive and could cause confusion if we took it away and someone didn't notice.One of the reasons why this ended up touching so many files and being super complicated is because there are lots of clever ways people could try to figure out someone's information even if we're not displaying it directly, for example searching on an old, known phone number could still reveal more information than we want, either through the user search API or by searching the activity report for the "old" value - so I had to build workarounds for that. (In other words, even if the response payload masked phone/email values, a known old phone number could still be used as a search term to produce a hit.)
We also had to suppress the sensitive fields on the edit, view and clone screens, and suppress the edited fields in the
log_metaon display.Aaaand we had to skip the sensitive fields in the user import. We now flash a warning that those fields will be skipped if the user doesn't have permission to view those sensitive fields:
Superadmin View
Contact info DENIED