Difference between revisions of "BBB Seneca Integration Use Cases"

From CDOT Wiki
Jump to: navigation, search
(Calendar)
Line 1: Line 1:
=Authentication=
+
=User Specific Use Cases=
 
+
==Super Admin==
==Login==
 
* User logs in to the system through a the login page with a userid and password in two steps:
 
*:# Directory Service Authentication
 
*:#: User is checked against the directory service, if found the user is authenticated and the department of the user is updated in the database.
 
*:# Local Authentication
 
*:#: If the user is not found in the directory service, the user will be checked against the local users table, authenticated and logged in.
 
 
 
=Super Admin=
 
 
*All Administrator rights applies
 
*All Administrator rights applies
==Add Administrator==
+
===Add Administrator===
  
=Administrator=
+
==Administrator==
  
==User Management==
+
===User Management===
 
* Add user
 
* Add user
 
*: add usecase
 
*: add usecase
Line 22: Line 14:
 
*: add usecase
 
*: add usecase
  
==Professor Management==
+
===Professor Management===
  
==Subject Management==
+
===Subject Management===
  
==Department Management==
+
===Department Management===
 
* Admin can manually add/remove a user to/from her department.
 
* Admin can manually add/remove a user to/from her department.
 
*: add usecase
 
*: add usecase
  
=Professor=
+
==Professor==
==Section Management==
+
===Section Management===
 
* Add students to section
 
* Add students to section
 
* Create Lecture Schedule
 
* Create Lecture Schedule
Line 37: Line 29:
 
*: Including check to propagate changes to whole schedule
 
*: Including check to propagate changes to whole schedule
  
==Calendar Management==
+
===Calendar Management===
 
* Display Calendar
 
* Display Calendar
 
* Filter Calendar
 
* Filter Calendar
  
==Meeting Management==
+
===Meeting Management===
 
* See General User Meeting Use Cases
 
* See General User Meeting Use Cases
  
=Student=
+
==Student==
 
Logs and have the following available:
 
Logs and have the following available:
== Settings ==
+
=== Settings ===
=== User Settings ===
+
==== User Settings ====
 
User can modify Nickname and set up an alternate email address (only if they are authenticated through Directory Service)
 
User can modify Nickname and set up an alternate email address (only if they are authenticated through Directory Service)
=== Meeting settings ===
+
==== Meeting settings ====
 
Activate silent mode, (if activated user will not receive notifications when the user is added to a meeting)   
 
Activate silent mode, (if activated user will not receive notifications when the user is added to a meeting)   
== Log out==
+
=== Log out===
 
Logs out the user
 
Logs out the user
==Calendar==
+
===Calendar===
 
* Meetings can get created by clicking on the empty space on a day which bring the use to the Create meeting use case.
 
* Meetings can get created by clicking on the empty space on a day which bring the use to the Create meeting use case.
  
Line 59: Line 51:
 
* Filter Calendar
 
* Filter Calendar
  
=General User=
+
==General User==
==Meeting Management==
+
===Meeting Management===
 
* Create Meeting
 
* Create Meeting
 
* Edit Meeting
 
* Edit Meeting
 
* Start Meeting/Lecture
 
* Start Meeting/Lecture
  
==Calendar Management==
+
===Calendar Management===
 
* Display Calendar
 
* Display Calendar
 
* Filter Calendar
 
* Filter Calendar
  
=Non-LDAP User=
+
==Non-LDAP User==
 
* Change Password
 
* Change Password
 
* Reset Password
 
* Reset Password
 
* Change Email
 
* Change Email
  
=Meeting Attendance Page=
+
==Meeting Attendance Page==
 
== Search Organization Directory Service Users (LDAP) ==  
 
== Search Organization Directory Service Users (LDAP) ==  
 
== Search Non-Organization users ==
 
== Search Non-Organization users ==
 +
 +
=Common Use Cases=
 +
 +
==Authentication==
 +
 +
===Login===
 +
* User logs in to the system through a the login page with a userid and password in two steps:
 +
*:# Directory Service Authentication
 +
*:#: User is checked against the directory service, if found the user is authenticated and the department of the user is updated in the database.
 +
*:# Local Authentication
 +
*:#: If the user is not found in the directory service, the user will be checked against the local users table, authenticated and logged in.

Revision as of 14:23, 6 June 2013

User Specific Use Cases

Super Admin

  • All Administrator rights applies

Add Administrator

Administrator

User Management

  • Add user
    add usecase
  • Ban User
    add usecase
  • User Activation
    add usecase

Professor Management

Subject Management

Department Management

  • Admin can manually add/remove a user to/from her department.
    add usecase

Professor

Section Management

  • Add students to section
  • Create Lecture Schedule
  • Edit Lecture
    Including check to propagate changes to whole schedule

Calendar Management

  • Display Calendar
  • Filter Calendar

Meeting Management

  • See General User Meeting Use Cases

Student

Logs and have the following available:

Settings

User Settings

User can modify Nickname and set up an alternate email address (only if they are authenticated through Directory Service)

Meeting settings

Activate silent mode, (if activated user will not receive notifications when the user is added to a meeting)

Log out

Logs out the user

Calendar

  • Meetings can get created by clicking on the empty space on a day which bring the use to the Create meeting use case.
  • Display Calendar
  • Filter Calendar

General User

Meeting Management

  • Create Meeting
  • Edit Meeting
  • Start Meeting/Lecture

Calendar Management

  • Display Calendar
  • Filter Calendar

Non-LDAP User

  • Change Password
  • Reset Password
  • Change Email

Meeting Attendance Page

Search Organization Directory Service Users (LDAP)

Search Non-Organization users

Common Use Cases

Authentication

Login

  • User logs in to the system through a the login page with a userid and password in two steps:
    1. Directory Service Authentication
      User is checked against the directory service, if found the user is authenticated and the department of the user is updated in the database.
    2. Local Authentication
      If the user is not found in the directory service, the user will be checked against the local users table, authenticated and logged in.