group membership management

A Discussion of NUCYKLO-83

Current implementation

The security system of Cyklotron 2 addresses well the need to control what users that are the members of the organization, or specific site team/workgroup can and cannot do. It also addresses the need of controlling what anonymous, or registered but-non member users can do.

The part it address weakly is the process in which a registered user becomes a member of the organization, or site team/workgroup.

At this point the administrator needs to navigate to "Team member" role under "Access control" of the apopriate entity and then go to "Assign workgroup to users" (shouldn't it be the other way around?!) Then, find the user he needs to add to the team among all users of the system (think thousands of users) and assign him the role. All communication regarding the user's intention to join the team, or the organizations intention to take the user in must take place externally to the system.

Addional requirements

eNGO groups has a mechanism that brings a part of this proces into the system - some groups permit users to join freely, others allow users to apply for membership, and group administrator accepts or rejects these applications. The administrator may also ban a person from the group, which prevents the person for applying for membership afterwars (unless the ban is lifted). We intend to bring this mechanism into Cyklotron2.

If the users are not allowed to apply for the membership of the group, they obviously need to be added to the group by the administrator. The action is unilateral - it does not involve acceptance of this action by the user. Introducing a notion of giving users an invitation to a group that they can accept or reject would make the process more symmetric. This feature could be also useful for open groups especially in a virtual community with many groups and users on a single server.

Another missing piece of the puzzle is quitting the group - with the current setup the user must rely on group administrator in case he decides to leave the group. They should be able to leave on their own.

Proposed changes & additions

• group administrator
  • a screen under organization / workgorup (site) where the administrator sets the membership policy
  • a screen under organization / workgorup (site) displaying outstanding applications for membership, outstanding invitations, effective bans, users that may be invited + apropriate actions
  • clearing team_invited,team_applicant,team_banned roles when user is added to the team through assign privileges to users / assign workgroups to user screens (selecting all users vs. team members)
  • filter role list on security.AssignRoles so that system roles (like team_banned) don't show up
  • allow assigning all registered / unregistered users to a workgroup
  • filter out 'anonymous' user from the role/privilege assignments screens
  • revamp the user to workgroup assignment screen to use the same mechanism as team management screen (tabs, first letter filters)
  • revamp users.UserList screen to use the same commodities as the security screens
• user
  • additional sections on My Sites and Organizations screens displaying membership applications and invitations
  • a visual component on organization / workgroup (site) page (in the Dashboard view) displaying the current user's membership status, and apropriate action links for joining/leaving/applying for membership etc. depending on the status and team's policy.

Notes

User's can have the following relationship with a organization / workgroup (HLR) - they are all mutually exclusive

A HLR can have the following membership policies

• open (registered users can make themselves team members)
• application based (users may ask administrator to add them to the team)
• invitation based (administrator may ask users to add them to the team)