Implement Users Profiles feature to enable Profile based configurations

[evilaliv3]

Proposal

This ticket, very related to ticket #2039 is to discuss an collect the requirements fro the implementation of a Profile based configuration for Users.

For what collected so far profiles should:

• Allow definition of Users profiles to organize unified privileges per-profile;
• Simplify users configuration replacing the current implementation that enables to change permissions per-users
• Require administrators to select a profile when creating users
• Enabling users to change the profile when editing users
• Be implemented with no breaking changes with respect to existing configurations;

Following this ideas the advantage will be:

• To make it possible for administrators to configure priviledges of users with same priviledges with a simplified and unified procedure
• To be able to get automatically reflected revision of the priviledges upon reconfiguration of the users profile on users configured

To implement non-breaking changes for existing users it is expected we could:

• Create automatically a profile for each existing user in the name of the exiting user and configured with the permissions currently associated to the existing user.
• Administrators of the existing setups after migration will have the possibility to continue using the system without applying any reconfiguration or decide at any time to create a single profile for their users where to configure properly a single user profile for each user role and assign them to their users (e.g. creating Admin Level 1, Admin Level 2, Recipients Level 1, Recepient Level 2)profiles to ender different levels of priviledges)

[evilaliv3]

It follows a set of evaluations performed by me and @msmannan00 in the previous months while designing this feature so to proceed with the analysis of the status of the work and discuss it with the community to prepare the next major release for 2025.

[evilaliv3]

Hello @msmannan02 , here are the main changes i suggest for the existing implementation to make it possible to keep solve the problems that we have identified.

Problems to address:

• the system should be very backward compatible
• old admin should continue to be able to operate as they where used to.
• we should not confuse old admin showing them a profile for every of the user considering there could be systems with 10k tenants and 1 single user per tenant we don't want them to have to deal directly with 10k profiles.
• we dont want to risk loosing escrow keys
• we do not want to risk to loose reports

Changes to current the implementation that i think would solve every of this problems.

• edit the /api/admin/user to accept all the variables like before (user configurations + users permissions)
• edit the admin users interface to make it possible to configure users priviledges if the user.profile is a profile with profile.custom.true and in this case save the permissions in profile.*
• when creating a user from profile admin, custodian, recipient or analyst create a copy of that profile and mark profile.custom = True
• avoid to list profiles with profile.custom in the profile TAB
• when changing the profile of a user, delete the initial profile if it is a custom profile (profile.custom = True)
• in the UI move "[X] Give this admin the possibility to change users password" from the profiles permissions to the users configuration, renaming this option as simply [X] Escrow key making it possible to give an escrow key to any type of user.
• prevent an administrator without escrow keys to change the profile of an admin user without escrow keys raising an Invalid Input exception.