Modifying the front end

API & Customization issues
1

Hi,

Is there any manual to guide on modifying the admin UI ? We want to remove some functionalities like export, import, and disable password display for internal security concerns. Please help us in understanding the same.

Thanks
Dhiraj Bastwade

2

Hi @dhiraj.bastwade Welcome to the forum!

There is no official guide but I would recommend looking at the passbolt github repos - specifically the passbolt_browser_extension repo which gets built and incorporates the passbolt_styleguide repo. The passbolt_api repo is mostly the api backend but includes initial screens related to setup.

3

Hi @dhiraj.bastwade & @garrett,

We are currently working on a new feature name “Roled-based access control” which will serve this purpose. It will allow an administrator to customize what users can do based on their roles.

A first version of the feature is planned with the v4 and more settings will be added with coming versions.

Checkout the specifications for more information: RBAC - Functional and Technical - PUBLIC - Google Docs

Let us know what you think, your feedback are more than welcome.

1 Like
4

Hi Cedric,

This is exactly what we as an organization were looking for to customize our community edition setup. Great that this feature is already under consideration and due in a future release. I just had an overview of “RBAC - Functional and Technical - PUBLIC” but I would love to study this in detail and will surely share any feedback. It would be great if you can let us know if this feature would be available on the community edition and by when is team planning to release the same.

Thanks
Dhiraj Bastwade

5

@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!

1 Like
6

Thanks @garrett for your feedback.

Well noted for the singular/plural, we’ll adjust what could be prior to the launch, which should happen with the v4.1.0, if everything goes well.

Idea 1: Yes, later version will provide with the possibility for administrators to create custom role.

Idea2: For now we wanted to focus to the roles mechanism only, as this dimension might cover a large part of the needs. But we might extend it in the future to support more complex ones, in that case this is an approach we might consider.

2 Likes