@cedric This looks really good. I can see use of repos positioned in the future as more for additions of new feature. Given the options related to not seeing other users, it could provide more of what I would call a “passbolt for professionals” where it’s a 1 to many use case and the many don’t know each other.
One point of feedback: For the options where there is the use of password/passwords it’s not clear what difference plural makes from singular. Meaning, I think singular can always be used and it would be natural to assume it to mean “any and all applicable password(s)”.
Also, although it adds another step of complexity, it would/will be nice to have a middle option for a user who can be granted admin rights on a feature while retaining the role of user. I can think of two directions to go on this.
Idea 1: provide ability to create a custom role. It does say Moreover in this first version it will not be possible to create other roles than the defaults, e.g. user and admin. This feature will not allow changing the default roles for administrators (they will still be able to do everything). so if at some point that is offered then this is related to what I mean.
Idea 2: In comparison to idea 1, and in addition, also making a user list admin role (or other role) grant on any feature. If the UI is like the permissions list table, for example, an additional column that has a button (indicating also when users have been granted overrides) which when selected opens a modal for list management. Users are searched and added or removed, to admin role grant (or other role) for that feature. For some this might be a more practical UI option when compared to creating a whole new role. It would also consolidate viewing any grants given into one place. I suppose in the backend the app could in reality create a custom role for a selected user, but just not display it as such. Any other grant for a given user on other features would consolidate into their one undisplayed custom role. Yet, it’s not handled in the UI as a “role” and would not be assigned to multiple users. Technically it is a role, but it is practically differentiated. This keeps custom roles management tidy and more general while overrides use the same underlying architecture but have an additional attribute of “override role” or something like that so it displays differently.
Thanks for posting!