Closed cokernel closed 11 years ago
This all looks good and documents our discussion. As far as your concern about the blocking/banning of users, I would like to approach that from two angles. One, would it be best to institute some feature to facilitate admins being able to block/ban users (require coding or usually available with authentication systems?), or two, would it be best to not have self-registration but have the information sent to an admin instead of actually establishing an account in the system? Just a few thoughts. Thanks.
I think it's best to have self-registration rather than information being sent to an admin. We want this process to be as automated as possible.
Here's my implementation plan:
The Admin and Site Manager roles are global: the Admin can modify anything, and the Site Manager can modify any record and accept or reject any repository request. For this reason, these roles live in a roles mask attached to the user account. The Repository Manager and Repository Editor roles are relative to a specific repository, so my current plan is to create a membership model which is a binary relationship between users and repositories. By default, membership would grant the Editor role; a flag on the membership model could be used to grant or deny the Manager role. I'm using CanCan to declare the authorization rules.
Let's move forward with this implementation plan. Thanks!
I suspect that we will not need to be creating new repositories during the training sessions, so I would like to suggest that we create a new issue to handle repository creation requests and mark this issue as complete.
@libmanuk, any objections?
@libmanuk and I met yesterday to discuss the user and role system for this program. I've attempted to summarize the discussion below. Please take a look at this and try to find missing rules. (For example, I don't list any ability to block or ban users... combined with self-registration, this could be a problem.)
Roles and entities
Basic roles
Rules