Add "Center" and "Class" group types

[georgiastuart]

In addition to PI groups, it would be great to have the following:

Center Groups

Some faculty are in collaborative research groups ("Centers") where they share data and software. A center group would be composed of a center admin, faculty members, and students. The center admin can add and remove faculty members and both the center admin and faculty have the privileges to add students. This should trigger the creation of a work directory for the center. Students should be able to be solely in center accounts but not other faculty PI accounts.

Class Groups

Some classes are now using Unity for class projects. We'd like a "Class" group type that is composed of an instructor and students. Instructors should be able to set a time frame for their class where students are automatically removed upon expiration. There should be a work directory created for the class.

[georgiastuart]

@tlbernardin feel free to add any further requests here.

[hakasapl]

Unfortunately, implementing this in a robust way is not all that trivial, so here goes... (I'm going to update this as discussions happen)

New Permission Definitions for Groups

Permissions should be hardcoded in the resources/defs/perms.php file (doesn't exist yet).

The following permissions will be defined to start:

• unity.approve_user - Allows user to approve a user within a group
• unity.deny_user - Allows user to deny a user within a group
• unity.grant_role - Allows user to grant any role with a lower priority than theirs
• unity.revoke_role - Allows user to revoke any role with a lower priority than theirs
• unity.admin_no_grant - Allows for every permission within a group, but you cannot make others admins
• unity.admin - Allows for every permission within a group, including assigning this permission

In perms.php, we should define each permission as follows:

array(
    "unity.approve_user" => array(
        "name" => "Approve Users"
    ),
    ...
)

Admins should by default have unity.admin on every group, but this does not have to be explicitly defined, there should be a check for the relevant methods in UnityGroup that checks if the requests is coming from an admin.

New Group and Group Roles System

Roles will be defined in MySQL (initially only be able to be defined through mysql, later integrated into the admin panel)

MySQL Table groupRoles

• id - Autoincremment (PRIMARY)
• name - Display Name (Professor, Student, etc.)
• slug - Slug Name (professor, student, etc.)
• priority - Integer value of priority, where a higher number is a higher role (ie. center admin has a higher number than student)
• color - Front-end color of the role (will come with a later iteration, but put the column in now and have it default to #000000 (black))
• perms - List of permissions given to user. This is a stored VARCHAR which is the PHPß enumeration of a PHP array of permissions.

MySQL Table groupTypes

• id - Autoincremment (PRIMARY)
• name - Display Name (Center, Class, etc.)
• slug - Slug Name (center, class, etc.)
• color - Frontend color of the group
• time_limited - Boolean, stores whether this group should have defined start and end dates
• def_role - Slug of the default role in this group
• av_roles - List of available roles for group (php enumeration)
• can_request - Boolean value which stored whether this group type can be requested, or whether it can only be created from an admin panel.

MySQL Table groupRoleAssignments

• id - Autoincremment (PRIMARY)
• user - UID of the user being assigned the role
• role - slug of the role being assigned
• group - slug of the group the role is being assigned on

MySQL Table groupRequests

• id - Autoincremment (PRIMARY)
• group_type - Type of group being requested slug
• group_name - Name of group being requested
• requestor - UID of user requesting the group
• requested_on - Timestamp of request
• start_date - Starting date if time_limited is true
• end_date - Ending date if time_limited is true

MySQL Table groupJoinRequests (Already exists in a different form)

• id - Autoincremment (PRIMARY)
• group_name - Name of group being joined
• requestor - UID of user requesting to join the group
• requested_on - Timestamp of request

New SCHEMA for LDAP

We will need to define some new schema for LDAP to use. Each group should be a posixGroup with an additional class named unityGroup

unityGroup will have the following additional attributes:

• groupType = The slug defined in the MySQL groupTypes table
• startTime = Start time of the group
• endTime - End time of the group

With only the above 2 section, we have a system where groups can be manually created and permissions be assigned (but no one can actually use permissions)

Changes to the Existing PI Groups

In this system "PI" becomes a group type instead of a hardcoded group.

The UnityGroup class will need to be updated to be more generic to fit with the above model. In addition, that class will now need to check permissions for each operation, depending on who calls the operation to be made. This should also be part of the frontend, but the backend needs to verify in addition.

Currently, all pi groups are stored in ou=pi_groups - this will be renamed to ou=unity_groups, and will have all the old pi groups as well as the new group types in it.

Front-end

• The My PIs page becomes the My Groups page. On that page all groups the user is a member of will be listed, with the type being listed as well. The type's background should be the color defined in SQL, with 5px border radius. Each group should have a "view group" button next to it, but the entire line should activate said button.
• Clicking on a group on the my groups page now goes to a new page called view_group.php which will list all the members of the groups, and their assigned roles. On this page roles that have the approve_user or deny_user perm should be able to see pending group requests and be able to approve/deny them. In addition, this page should allow users with the grant permission to assign roles to other users.
• We can remove the expand arrows from the group.php page.
• The add group button will largely work the same, except that the search should now return the values of any group in the ou=unity_groups ou, instead of just pi groups like it is now.
• There will be a new "Request New Group" page on the menubar where the user will select from one of the available group types (radio button) from the sql table. The group name cannot have spaces (we will add support for display names later). The frontend should be able to tell the user if a group name is already taken without a page refresh (AJAX calls). This page should also ask for start and end dates for a group if that flag is defined in sql.
• The "Request PI Account" button on the account settings page now redirects to the request new group page, but with the PI group option pre-selected for the user.
• The admin panel should allow admins to approve/deny groups, add users to groups manually, remove groups from users, etc. No more dropdown pi group, in this case clicking on the group will open a similar page to view_group.php

PR split

We should split this up into the following PRs:

1. Implements the new permission definitions as the perms.php file (ANSHUL)
2. Defines the new MySQL tables in the boostrap file, and adds relevant methods to UnitySQL for adding and removing rows from them. (ANSHUL)
3. Defines custom unityGroup LDAP schema and adds to LDAP bootstrap (HAKAN)
4. Update the UnityGroup class to be more generic and work with all group types in a generic way. Most of the logic defined above will go here (This is the big one)
5. Frontend changes to allow users to join/request/view groups
6. Frontend admin panel changes

There is likely some oversight here, please feel free to comment. I will be updating this post.