ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
ReThink the Create Project permission (Feature #204)
Description
A feature which is present in redmine/chiliproject, is the ability to authorize users to create projects.
This is done by setting this permission to the roles we want.
Now, here is a (I think) common case where it is a problematic choice :
In my company we use redmine (one day, chili will take its place I hope) for our forge.
All collaborators have access to this forge but our clients too.
Collaborators connect using LDAP and clients using internal auth.
Any collaborator must be able to create a new project so we allow Non Members to do it.
But ! It means that our clients can create projects too...
We wrote a small plugin to filter the permission based on the auth_source but I think it would be preferable to rethink the subject to make more logical.
Needing to already be member of something to create project is, to me, a non sens.
What do you think guys ? :)
Related issues
| duplicates Feature #121: Granular admin rights | Open |
History
Updated by Holger Just at 2011-02-18 02:13 pm
This issue could be solved with the introduction of global rights and roles (as proposed in #121)
Currently the "create project" right is really a bad hack. You gain this permission, by being member of any project with a role that has this permission. This should be changed to having real global permissions and being able to assign it to users and/or groups.
- Status changed from Open to Duplicate
Updated by S C at 2011-02-18 02:17 pm
Yup, sorry, didn't saw that one.