ST User Management Web Interface Requirements Document

The information presented below corresponds to ST#82920: ST User Management Web Interface

Summary

STAddingStaffMember describes a many-step process for adding new users to ST.

Every term, a staff member has to repeat these steps for any new CSCF co-ops, as well as 8 or so MFCF consultants and removing expired MFCF consultants. The first 4 steps are reasonable to automate using a web interface, and will reduce repetitive work for staff.

Overall design

  • intuitive navigation
    • minimum amount of required clicking
    • clear and descriptive headings
    • links, buttons, etc, are clearly indicative of where they lead
  • logical organisation of staff members
    • divided into MFCF vs CSCF
    • subdivided into
      • temporary (e.g. co-op, auditor)
      • regular (appear on Staff-List)
      • special access (access to the user management app)
  • common code base
    • good function abstraction
    • descriptive yet concise commenting
  • role-based permissions
    • as opposed to permission based
    • user's type determines access to restricted applications and information

Adding/Editing/Deleting Users

The application allowing user update will be solely accessible to users in special access roles (namely Stephen and Lori)
    • Lawrence: I'd like to also allow for some backup administrators (namely Trevor, Bill, me, maybe Dave)

Adding Users

  • requires input of WatIAM, MFCF vs CSCF, temporary/regular/special, start and expiration date
  • present faculty and employee type as options in drop-down menu
  • automatically generate first and last name corresponding to inputted watIam userid
  • deny access to expired users (ensure expired users stay in database)

Editing Users

  • only allow editing of user's start and expiration date/faculty and employee type
  • editing of WatIAM userid not presented as option
    • rather, users with changed names must be re-added
  • editing accessed from staff list, by clicking on user's name

Deleting users

  • "delete user" option placed either directly beside user's name or as button on edit user page
  • confirmation alert when delete option is selected
  • "undo delete" button which automatically re-adds newly deleted user
  • completely delete "deleted users" from database

Security

  • authentication is done by web server and verified by application using $REMOTE_USER
  • only special access members permitted access to app
  • automatic logging that keeps track of all changes (see "Logs" below)

Logs

  • automatically generated, kept on server or on main site
  • accessible to special access users
  • short description of all updates that occurred including
    • who/what was updated
    • date and time
    • who performed the update

Tables and other data

  • SQL tables:
    • three existing tables: "ownerOrganization", "owner", and "queue_acl"
    • former two tables only required when editing regular users -- rarely used
  • Other Data:
    • data contained in www.cs:/.software/regional/wwwdata_cs.uwaterloo.ca/data/vhosts/cs/cscf/internal/htaccess/staff-all for step 4 of STAddingStaffMember
    • WatIAM lookups (via command-line uwdir tool)

Attachments

Topic attachments
I Attachment Action Size Date Who Comment
Unknown file formatsql ST-users.sql manage 12.3 K 2014-01-07 - 10:45 DanielAllen owner, ownerOrganization, and queue_acl tables and data
Topic revision: r8 - 2014-01-07 - DanielAllen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback