School Administration Tools: Requirements

Requirements summary

• Facilitate Room/desk assignments:
  • record the purpose for a room (by association with parent Group responsible for it, such as "CSCF", "Bioinformatics")
  • Room is associated with a Group or multiple groups.
    • Group may have a lab manager contact-person.
    • Group should have a notes field
    • Group is associated with one or more parent-groups, which may be nested, such as "CS" "Math Faculty" "Central Campus"
  • Room may contain a customizable number of desks
    • a desk has a single person occupying it
  • A room may also contain a customizable number of people who are NOT associated with a desk, to support our course-masters room ("floating spaces" / "hoteling")
    • This difference- desk is assigned seating; room is unassigned- will work unless there's a situation where we need to assign arbitrary people to share a particular desk. Hopefully this simplification is sufficient for requirements.
  • Reporting who occupies the room/desk (current and history)
  • workflow to handle desk assignment changes
    • produce an inventory of rooms available by purpose - at any date
    • desk assignments to be made only by Greg (grad/sessionals/visitors) and Diana (faculty/staff)
  • workflow for incoming/outgoing people
    • automated access to lists of incoming undergrads/grads via OAT/Quest/WatIAM
    • manually recording incoming people who aren't on the automated lists: visitors, faculty, lecturers, co-op staff, sessionals
    • check that new person's start-date in a room / desk doesn't conflict with previous occupant(s) (keeping in mind that if the room is listed to have n occupants, there isn't a conflict unless there are >n simultaneous occupants)
    • check that changing a person's end-date doesn't conflict with next occupant(s)- automatically update the start-date for future occupants and inform the user.
    • possibly: push notifications when things change, looking ahead n-weeks
• "People" database - containing everyone with a WatIAM account
  • will need to keep lots of old data; eg., associations of people who have left.
  • basic WatIAM information:
    • phone extension
    • other contact information
      • eg: UW id, alternate email address, DOB (privileged),
  • Title - not the same as job duties (below); a person has a single title/position they are appointed to.
    • start / end date of appointment (undergrad and grad students: Quest. Others: manual input)
    • students: title is possibly Program combined with Plan
  • people_reports_to contains supervisory relationships - may be many-to-many
  • people_visitee records visitors and their "visitees" aka sponsors aka Principal Investigators
• Groups (also described above)
  • will be be potentially maintained by external software, later.
  • include: optional _effective date, optional _ending date, title of group, and zero or one of: user to whom it refers, or group to whom it refers.
  • Group view to add/remove users
    • need a means to activate changes to the external "sponsorship management system" - see directly below.
• Committees: will be out-of-scope for version 1. See below for details.
• Activating sponsorship-management system - updates sponsorship data - see /RT#777635 and SAT Accounts Management
  • This tool's UI can define "groups" to be used in the sponsorship-management system - they (Clayton/Isaac/Adrian) will take on our schema.
• Only administrative user access in version 1.
  • Administrators may:
    • assign people to rooms/desks
    • assign people to relationship-groups
    • assign rooms to groups
    • search and display any of the above; and print them (needs to display well for print)
  • Administrators are authorized by:
    • assignment to a group "Admin" AND/OR any group that has "Admin" as the parent group.

Future work

Additional aspects beyond the scope of version 1 / April 2019:

• workflow to handle change-requests
  • Clients might request a move
  • We may discover students swapped desks without official permission- need to notify the proper editor for them to check and rectify
  • "Proper editor" is associated with the Group
  • [ If out of scope for this version, we can simply email requests to the responsible person ]
• this app will feed student data into the Grad Office database
  • either by filemaker 16 reading our postgres data, or our app hitting an API on the filemaker server to trigger updates
• People data
  • accreditation
  • grants
  • awards won
• travel claim system
• non-administrative and administrative access by other permission levels controlled by groups - big area for improvement; could possibly use "Grouper" software.
• Committees: can be used to build "Administrative and Instructional Support Staff" sheet, and a dynamic version of the CS website's list of committees, among other purposes.
  • A committee consists of one or more groups, and has an associated unit_id (uw_unit.unit_code; such as "CS" or "MATHDEAN")
  • Top-level UI choice to view/add/edit committees;
    • display of committees should have two columns: Unit, and a comma-separated list of groups it consists of.
    • Requested by Isaac: a future version will have the ability to do "groups included" plus "groups excluded" - to remove members based on group membership.
  • Committees appear in the "Appointments" definitions; if an appointment is people_job_type "Committee Membership" (COMM) or "Committee Support Staff" (CSS) the associated committee can be chosen from a fill-in field that populates from the available list (restricted by unit_code of the appointment).
  • for implementation thoughts, see /RT#808697#txn-17492899
• Job Duties: "Who does what"
  • • also used for the "Administrative and Instructional Support Staff" sheet
      • eg., who is responsible for renovations, telephones, mailing lists, contact with Plant Ops, Classroom bookings
    • also used for Faculty Committee assignments
    • [ out of scope for version 1] could also be used for Grad Students- eg., TA for CSxxx - would be a linkage to existing TA databases

Requirements Gathering notes

Following are notes collected for requirements gathering, sorted by date.

2017-12-18- Meeting with Diana Timmermans

What administrative applications can we automate? What's done by hand/manual?

• Room/desk assignments
  • purpose for a room/desk
  • who is in the desk
  • students swapping desks without anybody knowing
  • time periods for desk allocation
  • work flow for incoming/outgoing people
  • push notifications when things change, looking ahead n-weeks
  • inventory of rooms available by type and dates
• "People" database
  • room/desk
  • phone extension
  • other contact information
    • eg: UW id, alternate email address, DOB (privileged),
  • start / end appointment
  • accreditation?
  • grants?
  • awards won?
• Relationships
  • new visitors and their sponsors
• Workflows
  • new people - visitors, grad students, faculty, lecturers, co-ops, sessionals
  • processes for travel claims (see below)
• Job duties / skill sets ("who does what")
  • CSCF Staff & Admin staff
    • eg: financial admin for Tamer Ozsu, who does renovations, telphones, mailing lists, Plant Ops, Classroom bookings
• travel claim system
  • 7 people doing travel claims
  • lots of work, things get lost
  • (consider: using RT?)
• VS: Central Campus classroom and Meeting room Booking- Diana says she should have access to the campus system, but doesn't any more.
  • She and Daniel will investigate.

2018-01-17- Meeting with Lawrence Folland

• Noting: Lawrence is definitely a user of these tools; data he can't currently get at.
• workflow for incoming profs: includes creating watIAM accounts ASAP, so they can have grad students associated with them. Currently Lawrence is doing this; is part of this automatable?
• workflow for outgoing grad students: we want alerts triggered when a grad is due to be vacating, so we can reclaim their equipment.

2018-01-22- Meeting with Diana Timmermans - Central Campus classroom and Meeting room Booking

Daniel and Diana looked at Ad Astra VII, the registrar's room-scheduling application, which is related to these requirements and could be useful.

• Astra maintains registrar-available rooms. Mostly, classrooms. Some meeting rooms.
• Bookings include class-times, mid-terms, and some meetings.
• Does not include ICR room bookings; eg., DC 1302 doesn't show any bookings though we know there's a SACA booking for tomorrow.
• Useful features:
  • Flexible. Can access data via: Room; Date; Event. Fairly complex search functions.
  • Reporting includes dozens of reports, such as "sections that are oversubscribed" and "ROI" (which seems to be a calculation of income-per-student minus cost-of-room)
  • Reporting also includes the ability to email reports in various formats such as CSV. If we needed a dump of this data, we could schedule a daily export.
• However, the data-set is restricted to a) things the Registrar is in charge of; and b) for CS admin purposes would be redundant with Quest feeds. Eg., Isaac's data already includes meeting locations and times for courses.
• The UI is OK but slow and appears to require lots of clicking to get your data. Reminds me of Infoblox. Observing it in operation, I hope we can do something more user-friendly.

2018-01-24- Meeting with Grad Office: Denise Schantz and Paula Roser

Precursor: Daniel did some digging into the Filemaker situation.

• Devon says the school is currently running a mix of versions and licenses; the Grad office is on Filemaker 12. He suggested I talk with Barb Daly about the plans going forward.
• Barb says there is a plan to bring the Grad Office app forward to Filemaker 16 server "fairly soon" but not this term. She has been doing updates to the code over the last 8 years to meet Grad office requests.
• Filemaker 16 is quite a bit more flexible: for example, it can produce "Webdirect" applications internally, which could provide data views needed by other users.
• She looks forward to meeting with us!
• A critical piece of whatever we work on is that it must include back-data for all students who are still here.

Met with Grad Office to see how they use the app.

• Main Entry page: fill in personal details from OGSAS.
  • "Milestones": lower-right portion of page. tabs for Masters, PhD, and Course Conditions.
    • student brings forms signed by Ian G, confirming they have met the requirements
    • fields to record dates and names of people who have agreed to read thesis, etc
    • Course Conditions are manually copied from OGSAS
  • "Grad Office Comments": top-right: freeform
• Search: from the Main page, frequently use command-F to find all matching records and then arrow through them.
• "Acceptance" page: (top-left): used to record financial information about grants etc.
  • Funding info: Barb Daly runs a script to duplicate previous term's data and they manually update
    • Photo: "RA Funding Entry" page for entering Grantees, Value of RA, Account Number, Work Order, Start Date, End Date, Payment Option, etc.
  • Authorizations: Turns funding data into a form for printing
    • Pain Point: They used to do this in batches (all grantees for a prof), but that broke. Though it works sometimes. Otherwise, they have to page through students to produce it.

Lots of Reports:

• Top level: Admissions, Applications, Acceptance, Student Information, Student Info Related, Term Registration, TA/RA Funding Info, TAs, RA File Funding, Supervisors and Admin, GSI Reports, Scholarships, Acceptance Course Condition Details, Extensions,...
  • Second level under Student Information: Registration Information, Registration Acceptance Info, *Fee Payment Arrangement Letter, *Privacy Info, *TA Information, *RA Information, *Scholarship Information, *Accounting Setup, *Mailbox Tags, *Registration Term Count, *Student Directory, *List by Supervisor, *List for WICS, *Convocation, *Remedial Requirements
    • Report for Registration Term Count: "List of Term Count for Students in the Current Term"
      • UW ID; Surname; Given Name; Program; Attendance; Current Term; Term Count
      • Noticing: data includes one Program of "PhD QI" - suggesting it's freeform text. Also: UW ID sometimes includes a decimal point- they're overloading the field?... Also: some data appears in different sizes- copy/paste is rich-text?...
    • List for WICS: they noticed that some on the list are male. Unknown why.

What happens when Lawrence asks who are incoming for next term?

• Precursor: data is typed from OGSAS. (Perhaps a few minutes per applicant; split amongst three staff; they are excited to be getting a co-op for typing).
• Search for the starting termid; then producing a report.

Who supplies the room? It should be that Greg supplies it, through unknown process. He might have access to the UI? But they don't think so.

What data do they leave blank? At most, room and extension. Extension info comes from Quest.

• They have not been tracking awards within the app. This would be useful.
• They used to get photos from the watcard office but not any more; Isaac offered to get them watcard photos via OAT, though that's not implemented yet.

Other pain points? Meeting room reservations. Denise "owns" two meeting-rooms: 2585 and 2568. (However, Helen has to confirm reservations anyway. Lawrence suggests Denise ask Stephanie to delegate that to Denise.)

• Denise tried to reserve MC 2009. Who is the owner? It doesn't show up in Ad Astra; owner isn't obvious from Connect Calendar. She needed five phone-calls to determine it's owned by IST.
• However, Connect would let us see the room, in order to try and provisionally book it...
  • In some Connect UIs, it requires knowing how the room label starts: "IST_MC 2009"
  • Web Connect app: "Choose New Room List" lets you search by MC to find it.
• Lawrence would like to be able to book DC1302/1304, but they are handled on paper by Vera.

Overall:

• Lawrence sees CSCF offering more OGSAS/OAT data in a web-app, so they don't have to fill it into their app. And there are other pieces that they are authoritative for, and it would make sense to make it possible to get data out of this system.

2018-01-30- Meeting with Science Computing: Mirko Vucicevich

• Ad-hoc meeting with Mirko and Dimitri after discussion about course-evaluations. Mirko brought up "upgrad", a grad-student tracking project started by him and Chirag Gada (who has worked for both of us).
• He is happy to demo upgrad for us; the project handles the workflows around student milestones.
  • Each Science department has very different workflows.
  • Flexibly setting different milestones; producing templated reports (mail-merge?)
  • Written in django / react. back-end with APIs; could have any front-end.

2018-02-06- Meeting with Arts Computing

What are their biggest pain points?

• On-boarding: especially appointments of new faculty. Same with us- pre-OAT input; how early can ACO get a feed of incoming people?
  • Executive Officer (EO) knows when the offer is signed; before it's given to HR.
  • Imagining workflows that are kicked off as soon as they exist in the system- work might not be due for another 5-8 months, but important to know the number of people we need to find space for.
    • Some things happen early-ish, like "create WatIAM account so they can log into OGSAS and accept grad students"
  • Currently Arts has a checklist page, used by each admin-person in the 17 departments... Keith will send to Lawrence.
    • each staffer's workflows may be different right now
  • We should book a meeting with Jack Rehder, to get EO perspectives
  • We need to identify the workflows that apply to each involved roles: eg., Admin privileges for Stephanie may be different from those at Faculty level; privileges may be delegated; possibly we display a checklist of tasks- eg. including "create RT ticket to request the workstation..."
  • We will discuss with Engineering- we've been in contact with Erick Engelke, but Bill says Steph Simpson currently handles their onboarding, in Sharepoint 2016, using project started by Beth Jewkes (see Daniel's Ofis Notes 14 Oct 2010 and Ofis Notes 20 Oct 2010)
• Audit reported need to be sure that leaving staff will lose access ("offboarding?")
  • how about continuing access to resources when they're moving on campus? Potential efficiencies of wide use of the system.

Seating

• Assigning was done departmentally; then the Dean's office centralized; then staff member (Debbie) retired, so now it's possibly done by department
  • It's fairly ad-hoc; Dean's office has final say.
• Feature: "oversubscribing" eg., 6 people and only 4 seats in the room, nobody has a fixed desk. The same way we do the course masters room- 40 people, 10 seats with workstations.
• Arts doesn't supply grad-students with laptops- students have their own. Easier for ACO.
• Rooms are under the departments' control; they might shift from holding a faculty-member (going on sabbatical) to grad students. Needs to be manually allocated.

Staff equipment allocation

• Refreshing / rollovers / evergreening
• ACO has regulated process using their new inventory system.
• When faculty member comes in, send them an email offering a standard workstation and they can augment using grant money (eg., extra monitor, disk, memory)
• ACO admin staff process these emails, make RTs for them, order equipment.

Room lookups (classrooms)

• Arts has two computer classrooms ACO reserves/maintains. They use an internal system to book them, not Ad Astra.
• Might be in/out of scope for this system- sounds quite simple and useful.

2018-03-27- Meeting with Barb Daly

Met with Barb. Prod update from fm12 to fm16 will happen as soon as she has time to do it and test. She will then do database cleanup. She will let us know if/how the schema changes.

She will give Daniel a copy of the database and Daniel will install fm16 to poke at. There is one floating license currently assigned to Greg McTavish that we will use for this.

We told her that we don't want to put work into a filemaker web UI, because the app is wider than just grads. She believes FM16 should support all of:

1. API queries to treat FM as a data-source (which probably requires writing code)
2. ODBC connections so our web app can query FM via sql
3. ODBC connections so FM uses our postgres as a back-end

However, she doesn't have direct experience with any of these. She'll see if any of her resources would be useful for us doing this; but this will be mostly for Daniel to investigate.

2018-03-28 - Meeting with Greg McTavish

Impromptu meetup with Greg.

His office-assignment work is mostly in conjunction with Diana (his supervisor) and with Grad Office. He's responsible for placing students, sessionals, visitors.

• He uses a simple excel spreadsheet for Seating Plan - a major benefit is how simple it is; only meant to be viewed or updated by him.
  • one tab for DC2, one for DC3, tab for labs, tab for incoming visitors.
  • Columns: OFFICE, DESK, LAST NAME, FIRST NAME, UW ID (not updated), PROGRAM (used for end-date if temporary), SUPERVISOR, CO-SUPERVISOR, end-date
  • for labs: insert first column: GROUP
  • colour coding just so he's alerted about upcoming changes
  • comments- just for him, eg., reusing UW ID and Program fields to store start/end for temporary.

Faculty and staff placement is handled by Diana with Justin Wan (Associate Director, or could be Director, whomever is responsible for Space Committee).

• They ask Greg about free space and tell him where they're putting people.
• Diana sends him a per-term spreadsheet, on which he mostly cares about the tabs for Visitors and PDFs - rows coloured yellow for new changes
  • Visitors: Columns: Full Name, Appointment Title, Start, End, PI
  • PDFs: Columns: Same; plus "# Courses in Contract" - not relevant to Greg's work.

Sessionals will be grouped in offices in the same area

• (He would imagine it useful to have a facilities management app offering an overview of rooms, to be clear about what offices are nearby)
• How difficult to do this? Would be REALLY cool via javascript: http://api.mazemap.com/js/v1.0.5/docs/plugins.html#scanned-floor-maps
• Room properties include X/Y coordinates?
• Note: the campus map includes building interiors: https://uwaterloo.ca/map/EV2-1?room=EV2+1011
  • DC 2nd floor
  • Reference WatITis session on campus mapping project by James McCarthy (MAD), Zachary Seguin (IST), Michael Tjendra (MAD)

Grad Students:

• course-masters aren't given space, but are fobbed.
• Masters, PhDs, post-docs go into his seating plan.
• He has to deal with paper key forms for all people with offices; and to deal with key fobs.

Whiteboard from Fall:

• total updates: 85
• postdoc: 2
• Incoming grads: 75 (PhD, MMath)
  • if available: lab space.
  • if not: grad office.

Some labs have a contact person.

• who needs to be kept in the loop before changes.
• the lab contact is responsible for updating him on free space and verifying accuracy

Once he's allocated grads into labs/offices, he'll send the sheet to their supervisor to choose hardware; and based on those results, sends it to Lawrence.

• once it's in CSCF's hands, he's done with their setup.

Pain points?

1. counting free spaces, guaranteeing accuracy. However he thinks regardless of whether it's in a spreadsheet or a web app, he'll still have to iterate and verify manually.
2. He doesn't want to deal with other people incorrectly making updates. = one editor? (+his manager?)
3. Electrical Engineering last Fall: 16 students to place for a prof who was away for weeks just when he was doing the placements.
   • Resolved by fitting who he could, and talking with the prof after he got back. Didn't know what space was available outside CS.
   • Yes, this would be useful if his analogue from other faculties was using this, but this problem was mostly lack of contact with PROF.

Other notes:

• he doesn't want to become responsible for data entry. of eg., grad office data, or Diana's sheet info. He feels data-entry is a very small portion of his work on this.
• His work is lots done before before/start of Fall term. Not overwhelming, but sometimes pressure to fit people in.
  • Sample scenario: he sees 6 free spots in a lab; asks lab contact prof; who says "no, that's reserved for Instructional Support Assistants or whatever"; Greg still doesn't have enough space; asks Justin to intercede; Justin talks to prof who gives permission to put people into the slots.
• He is happy to provide feedback on whatever iterations of web app we have to show him.

2018-04-04 - Meeting with IQC: Mary Lyn Payerl

Ryan Goggin put us in touch with IQC who are having similar issues with desk-assignments.

• Their needs are generally similar to ours; Mary Lyn described tasks similar to Greg's.
• She's using an excel spreadsheet but wants something more sophisticated that will allow her to share data.
• They have grad students (and PDFs, etc) from three campus faculties: Science, Math, Engineering. 14 departments.
• Wants to set up "hoteling" - drop-in offices for casual users. So, no restriction on one person per desk (same as our course-master students, who are only going to be assigned to a room, not to a desk).
• she is concerned with Reporting- producing output based on filter queries.
  • customizable CSV export would be useful.
• Related, I would like to be sure that our search results are printable.
• She doesn't currently track this, but her reports will need to filter based on the department of the supervisor.
• Currently she writes sticky-notes to trigger "when this person leaves, their desk should go to that person."
  • Workflow: if we have an end-date and a following start-date for a desk, if the end-date gets pushed, so should the start date.
  • currently she adds an empty buffer for the room between them.
• What is the action to remove somebody from a room? Press a button?
• She might be interested in recording "where are they now?" - could be saved in Advancement's CRM database?
• Their grad people use OGSAS; Quest came and tried to convince them to use GAP and they declined... They are using a filemaker database, which might be Barb Daly's other project?
  • involvement with John Watrous in grad director role
• sharing people with TQT and space in RAC 2. Difficulty coordinating offices.
  • TQT working with Igloo, downtown Kitchener, who supplies their HR/people onboarding app. I haven't looked at that yet. In a quick look, it appears to be mostly about getting the right info to the new hires, rather than collating data about employees.
• IQC uses a custom people directory built by a consultant, edits by Ryan Goggin, nobody currently sitting in that role.
• Mary Lyn asked us to keep her in the loop about progress.

2018-04-19 Demo for Greg McTavish

I gave Greg a paper wire-frame demo of the room-assignment part of the app.

• Overall, he thinks his basic spreadsheet might be simpler for regular office allocations- which is pretty static.
• Labs appear to be somewhat fluid.
• But he sounds fairly positive about the app; and sees its usefulness for Lawrence and others.
• A clarification: the list of incoming grad students comes from the Math Dean's Office. It isn't Diana recording who is going into which group.
  • So if we automatically receive grad students from Quest, we need a source for their groups (or a person to input it).
• He appreciates the idea of prospective end-dates- possibly supplied automatically for grad students? Or input by Grad office?
  • However, he cautions again about other people entering data that might be incorrect. What would he have to confirm? He would want a workflow for this.
  • Also, he never sees an end-date for visitors, sometimes not until they visit to drop off their key. This is a pain-point.
  • He can use the approaching end-date as a trigger to check up on someone's status/desk availability.
• Visitors aren't currently going into "visitor spaces" - we're limited for space so that he's having to put them where ever there is room. Managing expectations of private office or window...
• His decision making: will give PhDs and post-docs nicer spaces than Master's.
  • So in the dropdown for choosing who to put into a space, we should include: _Name - Role - Advisor(s)_
  • Sometimes he has to put Undergrad Research Assistants or co-ops into a space (meaning the app needs to add them to the right group).
• His process for validating the correctness of a lab space: he'll email the room's occupants to the lab manager or faculty member involved, and ask them to confirm that it is correct. So he wants to be able to print (or copy) out of the app.
• Allocating space for grad students: gets the data 1 month before Fall term.
• He was interested in the idea of the app emailing the prof to ask what kind of equipment to reserve- and send the results directly to Lawrence.
  • While Lawrence could then get the list of equipment to reserve, earlier, we won't know the room allocations yet.
  • A question for later: whose responsibility to check up on those faculty who don't reply? How?
• He is open to another visit in a few days with revisions to review.

2018-05-04 Email from Mary Lyn Payerl, IQC

We received further details about IQC's needs. She includes some new details that could be useful to include in our data model for rooms:

• Record of Square Feet
• Door keycode (eg., 37SBX1)
• Is door fobbed?
  • If so, fob reader number.
• "Floor" - Lawrence notes this is similar to "Wing" and would be useful to record. (DC25xx doesn't tell us which section of the building).
  • Could include both geographical and non-geographical groupings for rooms; not limited to one; not necessarily hierarchical.

Here is a sample of the spreadsheet that I use to keep track of our 250+ people. I roughly keep two other tabs in that spreadsheet - one that keeps tabs on who has left (for stats) and a second tab tracking those who are arriving soon. Once I have assigned them a desk I put them in my permanent main data file.

The fields I have set up are:

• Building (QNC, RAC1 or RAC2)
• Floor
• Room Number
• Type of office (office, lab, other) all based on floor plan of building - each room number is accounted for - even electrical rooms, etc (because key codes might be needed)
• SQ ft of room (for stats)
• Key Code for door
• Fob Access (Y/N)
• Fob reader number
• Room capacity (# of desks)
• Last name (by desk)
• First Name
• Group (for student or postdoc it is supervisor member name, if staff – team name)
• Type (Student, postdoc, faculty, staff, coop, undergrad, master, phd, affiliate, associate, RAP, visitor)
• Department – which home department are they affiliated with
• Extension
• Lease begin date for desk
• Lease end date for desk
• Notes

If a room has three desks then there are three lines in spreadsheet – one for each person. So this data tracks all IQC members and their specifics but also links to all key codes for building and all offices and labs and space. So it keeps track of the specifics about the building and the people.

2018-06-01 Considerations of defining and viewing Groups

This is to simplify visual display of groups, as related to rooms and people.

• the default display of groups depends on the person using the app. Given the following groups:
  1. "HCI" with parent "CS" with parent "Math"
  2. "Applied Math" with parent "Math"
  3. "Software Engineering" with parent "ECE" with parent "Engineering" (which for the purpose of people and rooms, exists separately from: )
  4. "Software Engineering" with parent "Math"
  5. "Geomatics" with parent "Environment"
  6. "CS" with parent "Math"
• Greg, who has a default group of "CS" with parent "Math", would want to see everything for CS by default. So a room containing each of the above groups would display for him:
  1. "HCI"
  2. "Math:Applied Math"
  3. "Engineering: ECE: Software Engineering"
  4. "Software Engineering"
  5. "Environment: Geomatics"
  6. "CS" (rather than displaying nothing)
• Greg's colleague in the Math Dean's Office, with a default group of "Math", would see:
  1. "CS: HCI"
  2. "Applied Math"
  3. "Engineering: ECE: Software Engineering"
  4. "CS:Software Engineering"
  5. "Environment: Geomatics"
  6. "CS"

Group defaults should also be used by the default "View People" page. A user in CS would see a list of all CS people by default; a user in the Math Dean's Office would see all Math people (which would include CS people).

Where do a person's defaults come from?

A person's defaults are determined by their Appointment (their Job)- which still needs to be mapped out in the schema. Each appointment can have a default group associated with it.

In the real world, a person might have multiple Appointments- however, for the app, I think we want to say they only have one active appointment.

• If they switch jobs, the first Appointment will have an end-date that doesn't overlap the second one.
• If they are seconded to another position, either the first position has an end-date that doesn't overlap, or we extend the database and add an "active" BOOLEAN.

Grad students will have an appointment. An undergrad student won't have an appointment unless they are also an employee.

-- DanielAllen - 2018-01-17