@ -65,7 +65,7 @@ We would like a system to address the following:
## Queries
These queries can be performed by any user.
Unless stated otherwise, these queries can be performed by any user.
- **Q1** - List visits. *Parameters: startDate, endDate, assignedFaculty, currentStatus* (any or all of these can be omitted, and assignedFaculty may be "none" to search for unassigned visits). *Result:* For each visit matching all of the parameters given: list student name(s), day, possibleTimes, decidedTime, decidedGuide, and status. Sorted by visit day.
- **Q2** - View visit. *Parameters: visitID*. View all attributes for the given visit, and also the associated committment level for each faculty member in the system.
@ -74,7 +74,7 @@ These queries can be performed by any user.
## Events
There are only a few problem domain events of interest. For each of these a source is listed, which is how this event is made known to the system.
There are a few problem domain events of interest. For each of these a source is listed, which is how this event is made known to the system.
- *VisitRequest* - the Campus Visit office contacts the department secretary with information pertaining to a new campus visit. *Parameters*: date, possible times, student name, other visitor names, and majors/minors of interest. *Source:* department secretary keys in the data (coordinator role).
- *ClaimVisit* - a faculty member decides to do a visit. *Parameters*: visit, decidedGuide, decidedTime. *Source:* faculty member or coordinator. NOTE: If the coordinator claims a visit for a faculty member, then the faculty member must receive a notification (unlike the case where a faculty member claims a visit for himself).
- *ConfirmVisit* - the department secretary contacts the Campus Visit office that someone has taken the visit. Parameters: visit's *decidedGuide* and *decided time*. *Source:* department secretary (coordinator role).
@ -86,7 +86,8 @@ There are only a few problem domain events of interest. For each of these a sou
- *EditAvailableTimes* - *Parameters:* faculty, subset of daytime hours for each weekday. Sets the available times for that faculty member.
- *SetEmailLinkTimeout* - *Parameters:* numberOfDays. Indicates the number of days which email links remain active, after which the link gives an error message.
@ -95,7 +96,7 @@ There are only a few problem domain events of interest. For each of these a sou
**R1** - The system notifies faculty via email under any of the following circumstances:
- A new *visitRequest* is made
- The faculty member is the *decidedGuide* for a visit which is scheduled for tomorrow
- Periodic reminders for faculty members who have an unknown committment level for one or more proposted visits.
- Periodic reminders for faculty members who have an unknown committment level for one or more proposed visits.
**R2** - The system notifies coordinators via email under any of the following circumstances:
- Periodic reminders for visits that are in the *proposed* state.
@ -111,27 +112,31 @@ There are only a few problem domain events of interest. For each of these a sou
## User permissions
Users act in different roles with regard to editing the system's internal model of campus visits.
Users with the coordinator role can:
- adjust notification frequency for **R1** and **R2** on a per-visit basis.
- establish a new visit request.
- claim a visit, acting on behalf of a faculty member (Note: in this case, the faculty member must still get the visit claim notification).
- set an *assigned* visit to *confirmed*, and can set a visit to *canceled* at any time.
Users with the faculty role can:
- set a level of committment and/or claim visits that are in the *proposed* state. Note that a "*can do*" level of committment is implied when a faculty member is the guide for a given visit.
- abandon visits for which they are the *decidedGuide*.
- edit *availableTimes*
Users with the admin role can:
- create a new user.
- change any user's name, email, password, or roles.
✔* = The action can be performed by the coordinator, acting on behalf of a faculty member.
✔+ = The admin can change any user's password (other users can only change their own).
## Security
- **R6** - The web app portal is password-protected and served over HTTPS, exclusively.
- **R7** - Embedded email links pertaining to user actions are long, unguessable strings which expire after a certain number of days (which can be set by an admin). Following an expired link shows an error message.
**R6** - The web app portal is password-protected and served over HTTPS, exclusively.
**R7** - Embedded email links pertaining to user actions are long, unguessable strings which expire after a certain number of days (which can be set by an admin). Following an expired link shows an error message.
## Preferences
Unnecessary email should be minimized. Within notification frequency, it would be preferable to have a single email containing notifications for all relevant visits rather than receiving a separate email for each notification.
Some User
1 year ago