Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tiered permissions - Managers can promote employees to managers, but not to admins. #5013

Open
1 task done
sjacobflaherty opened this issue May 16, 2024 · 1 comment
Open
1 task done

Comments

@sjacobflaherty
Copy link

sjacobflaherty commented May 16, 2024

Describe the feature you'd like

I would like to open the app up to be less managed by me and stakeholders, while also keeping empyrical permissions set in stone. This could be achieved by:

  • Adding "Tiered User Permissions" to the settings/features page as a checkbox. This would affect manage users and manage roles and permissions.

  • When Checked, tiered user permissions assignment would appear in /settings/roles below as a seperate card/body. Name of role and dropdown. 1-10. Looking like a separate set of settings.
    E.x. Default administrator role would be assigned "10" and the default guest role would be hardcoded "0"

  • Using this feature, any role trusted with manage users and manage roles and permissions could affect up to thier tier.
    e.x. A Manager could promote another employee(tier 1) to manager(tier 4) or developer(4), and adjust permissions for each, but cannot promote an employee to senior developer(5), Csuite(6), or admin(10). They could invite and onboard a contractor without me having to worry as much that a brain flub by the manager would accidentally give the contractor admin access. Talk about a nightmare.

The beauty of this is everything else could stay the same. Managers could add another user group like asst. manager(3) if they want. Asset privileges are unchanged for the most sensitive information, as they are set to visible for only specific roles anyway and can ignore tiers.

Describe the benefits this would bring to existing BookStack users

More granular control of user permissions. Allowing us to give trusted individuals more freedom, while also providing admins more security.

Can the goal of this request already be achieved via other means?

Not easily. I could code it if I get desperate enough. I'm more of a Nodejs/Typscript guy though.

Have you searched for an existing open/closed issue?

  • I have searched for existing issues and none cover my fundamental request

How long have you been using BookStack?

1 to 5 years

Additional context

No response

@ssddanbrown
Copy link
Member

Thanks for the request @sjacobflaherty. The fundamental need is very similar to #2713, so I may dedupe this down to that issue, with this referenced as a potential implementation idea.

Looks like a good potential solution if that issue was to be addressed, although I would look to avoid the settings checkbox to enable/disable the feature, as I try to avoid option driven features in BookStack, and instead prefer a forward compatible migrated route of some kind, with instead an added role level control that has to be assigned before user roles can be changed via such a mechanism.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants