Users App (UXPROD-784)

[UXPROD-206] Field Restrictions in User Management Created: 16/Feb/18  Updated: 05/Mar/20  Resolved: 30/May/18

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Users App

Type: New Feature Priority: P3
Reporter: Cate Boerema (Inactive) Assignee: patty.wanninger
Resolution: Won't Do Votes: 0
Labels: usermanagement
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to UIU-10 HOLD: Permissions: Can View User Prof... Draft
Epic Link: Users App
Analysis Estimator: Khalilah Gambrell
Front End Estimate: Small < 3 days
Front End Estimator: Jakub Skoczen
Back End Estimate: Large < 10 days
Back End Estimator: Jakub Skoczen
Estimation Notes and Assumptions: An easier solution would be to just flag a certain address type as restricted and not display in the UI but it would still be available by back end, so it's not secure, but easier

Otherwise we need restrictred vs basic as original proposal

But address is actually a separate endpoint which makes it easy to add a permission. This would make it medium on back end.

 Description   

Background:

  • Requirement is to enable permission control over specific fields on the user record (and other record types that need it).
  • Original plan was to have two levels of fields: basic and restricted. We would then offer a "basic" and "all" version of each user permission. For example: "Users: Can view user profile (basic fields)", "Users: Can view user profile (all fields)", "Users: Can edit user profile (basic fields), Users: Can edit user profile (all fields)" etc.
  • For the initial version, we might set which field were basic vs restricted on a system level. Future iterations might include tenant-level configuration.
  • So far, the only user field that SMEs have identified as needing to be permission-controlled is Address (for privacy reasons). And, actually, we need to be able to make just certain types of addresses restricted (addresses have a "type" which are defined by the library in Settings). Given we only had one use case, we had held off on implementing this feature.
  • We need to determine whether we should continue with the originally planned approach or if there is a simpler way to handle control of just the Address field (maybe when you are CRUDing address types, you can flag them as sensitive?)

There was a user story drafted for the original approach and it waits in the backlog on hold and in draft state: UIU-10 Draft



 Comments   
Comment by Khalilah Gambrell [ 30/May/18 ]

5/30/2018: Per UM SIG - stick with current approach - leverage permissions. Ensure dev can support flexibility in case we need it in the future.

Comment by Cate Boerema (Inactive) [ 05/Mar/20 ]

Hi patty.wanninger and Khalilah Gambrell. In the RA SIG meeting, it sounded like folks wanted to resurrect this issue. Any objections?

+ Andrea Loigman

Generated at Fri Feb 09 00:06:32 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.