People App Requirements Document

The below corresponds to ST#78166: CS People Database Project

• It follows on from initial work done as part of ST#55351: Improve handling of grad student desk assignments and computer equipment / GradOfficeWebApplication
• Status: as of April 2013, stalled due to lack of time and higher priorities.

Summary

There are many workflows involved with bringing new people into the school, allocating/updating resources for them, and reporting on people and resources.

• New grad students need to be assigned desks, computers, and be associated programmatically with supervisors, research groups, and subscription-codes
• Visitors also need to be assigned similar resources.
• The Research Support Group needs to be able to track grad students by subscription-code
• Staff need to produce lists of people grouped by Group/Research Area

Existing processes involve manual entry and synchronisation of multiple unnecessarily-duplicated data-sources:

• WatIAM
• Excel spreadsheets
• Filemaker database
• ST

Users: (version 1.0)

• Admin staff responsible for bringing in new grad students: grad office would greatly appreciate a simple database interface.
• Other admin staff needing read-only access
• CSCF staff: to read/update grad student computing data. Lawrence confirms this would be helpful for RSG.
• Other staff/faculty specifically involved with space alotments for groups/rooms

V.1.0 Project Scope

Version 1.0 Scope includes:

• pulling information from WatIAM, if present
• providing CSV export (suitable for feeding into the RSG subscriptions database)
• allowing CSV import for new entries.
• friendly user experience (UX) with jquery widgets

Version 1.0 Scope excludes:

• pushing information TO WatIAM
• pushing information directly to the RSG subscriptions database (perhaps for future version)
• interfacing with, or replacing, the Grad Office filemaker database. Grad office is comfortable with this decision. (perhaps for future version)
• Users: for a future version:
  • Grad students: read-access (or partial write access) to their own records
  • Faculty: read-access (or partial write access) to their own records, and records relevant to their research-groups / office areas
  • Staff: read-access (or partial write access)
• See PeopleAppProjectFutureVersion for a number of future extensions that meet particular school needs.

User Experience (UX)

• Friendly user experience (UX) including:
  • intuitive navigation
    • minimum amount of required clicking
    • clear and descriptive headings
    • links, buttons, etc, are clearly indicative of where they lead
    • complete history is visible, for a:
      • person
      • room
      • group
      • room_group
  • jquery widgets: fill-in field auto-completion
  • dates: in what format? TO BE DETERMINED

• role-based permissions
  • user's type determines access to restricted information
    • Grad Office staff: full access
    • Other Admin staff: read-only access
    • CSCF staff: full access
    • everybody else: initially: no access.

User Interfaces (DRAFT, to be further refined)

User interface for room

• date-entry field / calendar picker at top of page, for "view as of [ this date ]". Default is today.
• datatables list by room - using editable grid view (? possibly via edatatables.)
  • columns: room (name), occupied [ count(room_desk in this room) ], and room_capacity.
• at bottom: total: total occupied / total room capacity (total free)

User interface for room_groups

• same date-entry field at top;
• datatables list by room.
  • columns: room (name), different room_groups currently represented in the room.
• second table, list by room_group group_id; columns only list the rooms.

User interface for assigning people to rooms

• same date-entry field at top
• "total free rooms"
• datatables list of users with no room as of that date.
  • columns: person name, group, supervisor, date anticipated start, text-entry field for room-name to assign them to, date-entry field to add date-effective, button "pick random room", "save" button.
• save button will cause the entry to disappear IF the effective date is past the "view as of this date".

User interface for people [ to be added ] [ use the same editable datatables for people_* except for people_supervisor - see directly below ]

• fields that use lookups from people_* should be dropdowns.
• use the same editable datatables for basic_info - has multiple values
• viewing a person, you should also see datatable with their "history" (transactions affecting that userid)
  • displaying all fields except for id and userid (we may want to re-label the columns; TO BE DETERMINED)

User interface for assigning people to supervisors

• supervisor has multiple values
• on the edit people page, show editable datatable for people_supervisor showing entries matching that userid.
  • to add a people_supervisor, auto-complete edit field querying (people where type_id = 'faculty') TO BE DETERMINED: what values allowed? See below.

User interfaces for transactions

• There should be a tab for "history", with a datatable with all transactions (in future version, may want to limit according to permissions)
• there are also history datatables visible on page for a specific:
  • person
  • room
  • group
  • room_group

Remarks on logic, data-checks, and program flow

• room management vs. room_desk management
  • table `Room` properties are: name and number of desks. This allows us to create/edit/delete rooms.
  • table `room_desk` properties are: userid, room, and desk. This allows us to assign a person to a room/desk.
  • Actions that require both tables:
    • deleting a room requires checking that the room is empty of people- no matching `room_desk` properties.
    • editing a room (to change the name of the room): requires adding a transaction for each thing "in" the room: `room_desk`, `aux_desk`, `room_group`
      • the `room_desk` transaction should include the userid associated with that entry. the `aux_desk` and `room_group` transactions should not have a userid filled in.
      • otherwise, looking up the history of a person would not include the name-change.
• `group` vs. `room_group`
  • `group` is a property of people. eg., a grad-student could be associated with SCG / Symbolic Computation Group.
  • `room_group` is a property of a desk but also has a `group` id. eg., particular seats in DCxxxx are automatically associated with SCG
• desk management
  • on room creation OR on the first time a room's capacity is set: create the capacity number of desks in aux_desk, associated with the room, with 'desk' set to an incrementing number, 1 to n
    • a room can be created without the capacity being set.
  • on the room-edit page, there should be an editable grid view of desks, to edit all desk parameters - or delete a desk (if supported by the grid view; if not, we'll figure something else out).
  • to manually add desks to an existing room: from the room-edit page, under the grid view of desks, there should be an "add a desk" button.
    • adding a desk manually increases the room capacity- unless there are fewer desks listed than the current room capacity.
    • adding a desk (manually or automatically) should update transactions (without any user associated).
  • before allowing to delete a desk, query that the desk is un-occupied; if occupied, warn the user. Deleting the desk with an assigned user should leave the user with no assigned desk.
    • deleting an un-occupied desk should update transactions without any user associated.
    • deleting an occupied desk should update transactions with user associated.
• Values for people_type:
  • TO BE DETERMINED: how do we represent multiple types of faculty members, so they are all recognizable as valid supervisors. Daniel will investigate.

Security

• authentication is done by using $REMOTE_USER
  • dev version: Basic Apache Authentication
  • production version: CAS Authentication
• authorization: for now, only particular people are allowed access (by roles, above)
• automatic logging of all changes (see "Logs" below)
• TO BE DETERMINED: do we need to record student-id? If so, that adds an additional set of security requirements.

-- DanielAllen - 19 Mar 2013