Content
View differences
Updated by Max Mutzge over 5 years ago
The permission "edit project" should be more fine grained. This option contains permissions which might be useful for a project admin and some which should be excluded, like renaming of projects.
Renaming projects is usually not done by projectadmins and cause inconsistent links, paths and a bunch of work to get everything back to consistency. consistency.
I would suggest to introduce a new permission "rename project".
**Use case**
As an administrator you might have a naming convention for, e.g. LDAP groups etc. which might correlate with project naming. If projects are managed (create/archive/delete) in a centralized way, and a project admin is not allowed to create/archive/delete projects, it really s\*\*\*ks if project admins are still able to rename the project and more over change the ID. Changing the ID is a worse case; renaming the project might not be a worse as as changing the ID, but still is a huge problem.
Imagine you have a project "sales", which is reflected by groups in OP and LDAP with a similar name (e.g. for group sync purpose). For administration purpose this might a standard case. If now the project admin is renaming the project to something like "customerX", this would f\*\*\*up the whole concept of the sys admin and cause trouble (logging, debugging, security ....). The groups and URI might still work, but are not reflecting the purpose anymore. If the ID is changed, this scenario would be even more catastrophic.
Renaming projects is usually not done by projectadmins and cause inconsistent links, paths and a bunch of work to get everything back to consistency.
I would suggest to introduce a new permission "rename project".
**Use case**
As an administrator you might have a naming convention for, e.g. LDAP groups etc. which might correlate with project naming. If projects are managed (create/archive/delete) in a centralized way, and a project admin is not allowed to create/archive/delete projects, it really s\*\*\*ks if project admins are still able to rename the project and more over change the ID. Changing the ID is a worse case; renaming the project might not be a worse as as changing the ID, but still is a huge problem.
Imagine you have a project "sales", which is reflected by groups in OP and LDAP with a similar name (e.g. for group sync purpose). For administration purpose this might a standard case. If now the project admin is renaming the project to something like "customerX", this would f\*\*\*up the whole concept of the sys admin and cause trouble (logging, debugging, security ....). The groups and URI might still work, but are not reflecting the purpose anymore. If the ID is changed, this scenario would be even more catastrophic.