Skip to content

Course specific roles

For each course (edition), the roles of "supervisors" differ. It should be possible to specify the "supervisor" roles on a course (edition) basis.

Examples

  • Software Project
    • Client - Person who supervises the team from the company
    • Coach - TU Delft staff supervising the team
    • TA - TU Delft TA acting as daily supervisor for the team
    • Examiner - SP Course coordinator involved in grading the project
  • Research Project
    • Responsible Professor - The faculty assistant/associate/full professor responsible for the project (Possibly the one who proposes the project)
    • Daily Supervisor - Someone with a master's degree, supporting the responsible professor in the supervision
    • Examiner - A faculty assistant/associate/full professor not involved in supervision, but only in grading the project
  • Technical Medicine
    • Technical Supervisor
    • Medical Supervisor

Details

  • For permissions purposes, all supervisors are equal.
  • For exports, the different kinds of supervisors should be shown separately in the export columns, replacing the "coach 1, coach 2, additional coaches" with " " (column number depends on max amount of these in a project
  • When the role is assigned through non-admin means, a notification should be sent (#250 (closed))
  • Publically available there should be information pages about roles, showing the public description (#218 (closed))
  • Associated to a role there should be:
    • Name
    • Type: Supervisor (future-proof for different types of course specific roles)
    • ProjectPass: boolean (indicates that the role is specified on the project, and that the role is passed onto the group when one is created)
    • Required: boolean (required to specify a person with this role on project creation)
    • Public description (markdown) (#218 (closed))
    • Automatic notification message (can be empty for no message) (#250 (closed))

Required implementation steps

Phase 1: Course specific roles

  • Create CourseSpecificRole model.
  • Rename the rolify role "coach" to "supervisor"
  • Add callbacks to CourseSpecificRole to add/remove the rolify "supervisor" role when the CourseSpecificRole is created/removed (check if there are other CourseSpecificRoles for the user before altering the rolify role)
  • Make roles required, optional, or non-specifiable by the client

Phase 2: Adding course specific roles to users

  • Create a model to add user specific roles OR decide to use rolify for managing these roles.
  • Create a migration to add CourseSpecificRole for "coach" to all existing course editions. Add a role "coach" for all users with a "supervisor" rolify role. (non-specifiable)
  • Test that the logic works

Phase 3: Adding UI

Course Specific Roles:

  • Management Panel: Add partial for course edition to specify the roles using cocoon (+ Model)
  • By default, there should be a "Supervisor" role specified for the course. (non-specifiable)
  • Make sure course-specific roles are copied when duplicating course edition (!606 (merged))
  • Add a confirmation dialog when deleting course-specific roles
  • Fix company and course label on second step of project proposal form
  • Make the second page of the form be rendered using a GET instead of a POST (and extract common logic)
  • Show emails of users assigned to roles on the editing page
  • Allow clients to assign users to roles on the editing page (but do not allow them to remove users)
  • Fix project editing form being disabled

User Roles:

  • Add partial for specifying the roles of those involved in the project (= a cocoon), and add this to the project proposal page. The only options are the roles defined for the course edition. This partial is only shown if any course edition specific roles are defined.
  • In project creation controller (and/or project model), add validation that all required roles are specified.
  • Add management panel way to add project roles to users
  • Add management panel way to add group roles to users (on group edit page?)
  • Transfer project roles onto groups upon group creation when a student creates a group but not when groups are created or imported in the management panel (?)
  • Remove coach assignment UI from management interface
  • Add a boolean on course-specific role defining whether this role can be invited by students
  • Students should be able to invite coaches with certain course-specific roles (change invitation logic)
  • Change all pages where coaches are listed to display the name of the course-specific role
  • Change the "interested coaches" functionality?
  • Remove coach assignment from user management page
  • Change the "Stop coaching" functionality ("If this person is the coach in question, show button to stop coaching the group")
  • Make "Remove role" button on group page red

  • Remove medical and technical supervisors

  • Approval of new role assignments when editing projects?

  • Make all new features work with internships as well

Phase 4: ???

WIP

Follow up

Things to think about

  • What to do with all existing coach roles?
    • Create a coach CourseSpecificRole for all existing courses. Add this role to all existing coaches.
  • Do we want to use rolify roles to add the course specific user roles for convenience, or do we define our own model?
    • rolify
  • Some roles are applied to projects, only to apply them to all groups created for said project. How do we deal with this?
    • Transfer all roles on projects onto groups upon creation of the groups. Main issue is when the project attached user(s) change. For these changes we probably need to ask if groups should also be updated.

Time estimation

  • Phase 1: 2-4 hours
  • Phase 2: (rolify) 2-4 hours
  • Phase 3: 12-16 hours (change options based on selected course is complicated)

Total: 16-24 hours

Extensions:

Total with extensions: 54 - 80 hours

Useful resources

Contacts

For more information on the requirements, contact: @Tarovk @mdeweerdt @Migut

Edited by Martin Mladenov