background

usually you have at least 4 groups of persons accessing a tool like that:

1. global admins (full access to everything, everywhere)
2. project admins (full access to a project - only)
3. project users (specific action permissions in a project, e.g ability to click the build button but not modding an inventory etc)
4. readonly users (no action permissions, never)

what I currently see in semaphore is 1. and partly 2 with some kind of non-admin access which basically is not what I would expect when thinking of a "non-admin" user.

Semaphore already has the ability to choose team members for a project which is great and should "just" ;) be extended to a more specific role / group based system. I have not looked into LDAP yet but when implementing that it should match LDAP groups/netgroups in order to make use these here, too (e.g. LDAP group "semaphore_projectadmin_abc" will become a project admin of project "abc" in semaphore).

Permissions

global admin permissions

• like the current admin user
• all permissions of a project admin but for every project (see next topic)

project admin permissions

basically this is what an admin and even a non-admin user (when added as a team member) can do already except the user management part, of course.

when a user is added to a project and having project admin rights he should have the permission to:

• add/remove other team members
• set/unset a team member as project admin
• set/unset a team member as project user
  • set/unset a project user permissions: allow edit inventories/repos/..., allow to build/rebuild, ..
• set/unset a team member as readonly user
• full access to everything in that project, i.e. add/remove inventories, tasks, etc and do actions (build,rebuild etc)

project user permissions

• whatever has been set by an admin or project admin (see above)

readonly user permissions

• basically view / show everything where that user is member of - without any ability to modify
• optionally it would be nice to block changes of the own account (password, mail,..) so one can share that account with a wider audience

conclusion

I strongly believe that enterprise users require the above and that prevents them for actually using semaphore or at least offer it to their users. I would really appreciate seeing the above or at least parts of it in semaphore as actually atm I cannot share it with others without these changes.. I would love to contribute but absolute zero experience with Go - while I really love the look & feel & idea of semaphore..

for a first run I would be more then happy if we could have a readonly user permission and a simple project user permission where everything is blocked but actions like build/rebuild are allowed. The rest would be step 2..N then :)

refs:

• Add non-privileged user role #405
• Add launch-only property for project users #413
• Add an authorization mechanism based on Casbin #368
• Simple authorization via LDAP #310