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.


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.


  • 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
Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r6 - 2013-10-18 - DanielAllen
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback