As of today, when platform is configured to mandate login, there are 3 levels of project
- public incl. restricted: all authenticated users can access the project
- public: accessible only by active users
- private: accessible only be project members
It's proposed with this story to
- add a 4th level: "private without restricted".
- project admins cannot add as member someone who is restricted
- have 4 different icons that allows to clearly identify each level
- Project admin can no longer add restricted users to project members (and user groups)
- Users are not proposed in autocompletion
- Restricted users that try to access a "private w/o restricted" project doesn't have the possibility to request access, they are getting a 404 error.
- When a user is switched to restricted, the user is removed from all projects that are "private w/o restricted" (and all user groups)
- There is a warning message to confirm the action (User is going to be removed from X projects).
- When a project is switched to "private w/o restricted", all restricted users are removed from project members (and all user groups)
- There is a big warning message specific to this switch to confirm (when there are restricted): "X users are going to be removed from this project".
- Binding of user groups must filter restricted users when target group is a "private w/o restricted" project.
- On LDAP sync of user groups, the users are filtered to remove restricted that should land in "private w/o restricted" project.
- Warning, user filters (that control how users are created/updated on the platform from LDAP) must be applied before the "private w/o restricted" filter.
- XML export
- When platform is configured with access to "Anonymous" or "Authenticated", project are exported like
- When platform is configured with access to "Autenticated + Restricted", projects are exported like
- XML import should reject creation that doesn't comply with constraint
- When platform is configured with access to "Anonymous" or "Authenticated", projects can be imported with following access level (other levels trigger an error):
- When platform is configured with access to "Autenticated + Restricted", projects can be imported with following access level
- SOAP and REST API must also enforce the constraint
- The 4 level of project access must be managed a project creation
- Should be proposed in the web UI
- Should be managed as default value for project creation
- The local.inc config "$sys_is_project_public = 1;" is put in the DB (and can manage de 4 possible default values) and managable by the web ui and "tuleap set-config" CLI
The implementation is done with double safety in mind (aka ceinture & bretelles). That means that, in addition to ensure that when a user becomes restricted or when a project becomes private (w/o restricted), the people are removed from said projects. In addition to that, the implementation is done so if it ever happens that a restricted user ends-up being member of a private (w/o restricted) project, the checks are there to ensure they still cannot access it.
However this comes at a cost and limitations. The main limitation is that it cannot work for all UNIX related features:
- proftpd plugin
- direct ssh or ftp access
- cvs support
For those services, the only protection that will apply is "restricted users are removed from private projects".