To see the diagram in full-size, right-click on the image and select the option to open in a new window.
Monday, December 31, 2007
BSAR Database Tables and Fields
TODO: how do I handle the default set of permissions?
USER:
General user information, name, uh_username, etc.
Initial size: TODO
Anticipated growth: TODO
References: N/A
Referenced by: bsar_user_role, approver_domain, request, request_comments, requestor, request_object_action, banner_permission
Fields:
id: PK auto-generated
first_name: varchar(50), not null
last_name: varchar(50), not null
uh_username: varchar(8), not null
BSAR_USER_TYPE:
Tells what type of users exist in the bsar system, excluding requestors. Is essentially a three record table with the values of the description fields being Coordinator, Approver, and BACU.
Initial size: 3
Anticipated growth: none
References: N/A
Referenced by: bsar_user_role, request_comments
Fields:
id: PK auto-generated
description: varchar(11), not-null
BSAR_USER_ROLE:
Associates users with roles in the BSAR system, this tells if the user is a Coordinator, Approver, and/or BACU. Handles the case where a user has multiple roles. Requestors are not in this table.
Initial size: TODO
Anticipated growth: TODO
References: user, bsar_user_type
Referenced by: N/A
Fields:
user_id FK user.id, not null
bsar_user_type_id FK bsar_user_type.id, not null
CAMPUS:
Place to store campus short and long names so they aren’t replicated all over the db.
Initial size: 10
Anticipated growth: none
References: N/A
Referenced by: request
Fields:
id: PK auto-generated
code: char(3), not null, the three letter code for a campus, like WCC, MAN, etc
description: char(20), not null, the full name of the campus
REQUEST:
The general information of a request: who wants access, who filed the request, if the request is marked completed, etc.
Initial size: TODO
Anticipated growth: TODO
References: user, campus
Referenced by: request_object, request_comments
Fields:
id: PK auto-generated
coordinator_id: FK user.id, not null
requestor_id FK user.id, not null
campus_id: FK campus.id, not null
completed: boolean, not null, TODO: can a request be marked re-opened? If so, a boolean for this field isn’t adequate.
REQUEST_COMMENTS:
May be overkill, but this allows multiple user types to make comments. Since approvers may want to make a comment about the entire part of the request they have control over, the comment section in the request_object_action table isn’t enough.
Initial size: 0
Anticipated growth: TODO
References: request, user, bsar_user_type
Referenced by: N/A
Fields:
id: PK auto-generated
request_id: FK request.id, not null
date: date, not null
comment: varchar(2000), not null
commenter_id: FK user.id, not null
commenter_role: FK bsar_user_type, not null, needed because if a user has 2+ roles, which role did the make the comment as, it makes a difference in terms of how it’s displayed.
REQUESTOR:
Tells if a user has filled out a ferpa notice or not.
Initial size: TODO
Anticipated growth: TODO
References: user
Referenced by: N/A
Fields:
user_id: FK user.id, not null
ferpa_sent_date: date, holds last sent date if repeated, null if not sent
ferpa_action_date: date, null if user hasn’t responded
ferpa_approved: boolean, null until user responds
ferpa_resend_count: int, null until sent. number of resends, one week apart
EMAIL:
Holds the different emails that are sent out (ferpa, approver notice, bacu notice, etc) along with resend info (like resend ferpa once a week, for three weeks if not answered). This table will likely disappear in favor of files for the emails, and a properties file for the limit and delay settings, still, I figured I’d put it here so it doesn’t get forgotten.
Initial size: 1
Anticipated growth: none
References: N/A
Referenced by: N/A
Fields:
ferpa_resend_limit: int, not null, number of times to re-nag user
ferpa_resend_delay: int, not null, number of days between resend attempts
ferpa_notice: varchar(?), not null, Text of the first and interim emails to send
ferpa_notice_final: varchar(?), not null, Text of the final email to send
coordinator_ferpa_notice: varchar(?), not null, Email text sent to coordinator when no ferpa obtained.
approver_notice: varchar(?), not null, text of email sent to approvers when action is required.
bacu_notice: varchar(?), not null, Text of email sent to BACU staff when action is required.
REQUEST_OBJECT:
Shows what objects were asked for w/ a given request. Groups together all the classes/forms that were asked for in a given request.
Initial size: 0
Anticipated growth: TODO
References: request, banner_object
Referenced by: request_object_action
Fields:
request_id FK request.id, not null
banner_object_id: FK banner_object.id, not null
access_type: FK banner_form_access_type, only filled in if banner_object is type form, null if is type class
REQUEST_OBJECT_ACTION:
A history of events for each object in a request. Like if permission for an object was initially denied, then approved, then modified, and finally revoked. It’s all here along with who and when for accountability purposes.
Initial size: 0
Anticipated growth: TODO
References: request_object, action_type, user
Referenced by: N/A
Fields:
request_object_id: FK request_object.id, not null
action: FK action_type.id, not null
action_user_id: FK user.id, not null
action_date: date, not null
action_comment: varchar(2000)
ACTION_TYPE:
The different actions that can happen to a request, or objects in a request, like cancel, approve, deny, create, delete, change to modify/query status, etc.
Initial size: < 10
Anticipated growth: 0
References: N/A
Referenced by: request_object_action
Fields:
id: PK auto-generated
description:varchar(10?), not null
BANNER_PERMISSION:
Tells which banner objects to which a user already has access.
Initial size: TODO
Anticipated growth: TODO
References: user, banner_object
Referenced By: N/A
Fields:
user_id FK user.id, not null
object_id FK banner_object.id, not null
banner_form_access_type_id FK banner_form_access_type.id, can be null if object is type class, gets set if object is type form.
BANNER_OBJECT_TYPE:
The types of banner_objects, basically a two-entry table: classes and forms
Initial size: 2
Anticipated growth: 0
References: N/A
Referenced by: banner_object
Fields:
id: PK auto-generated
description: varchar(5), not null (values will be class or form)
BANNER_OBJECT:
A listing of all banner classes and forms.
Initial size: TODO
Anticipated growth: TODO
References: banner_object_type
Referenced by: banner_permission, request_object
Fields:
id: PK auto-generated
description: varchar(20?), not null (name of class or form)
type_id FK banner_object_type.id, not null
APPROVER_DOMAIN:
For users with approver roles only, tells which classes and forms they have approval power over.
Initial size: TODO
Anticipated growth: TODO
References: user, banner_object
Referenced by: N/A
Fields:
user_id FK user.id, not null
banner_object_id FK banner_object.id, not null
BANNER_FORM_ACCESS_TYPE:
Tells the possible access types for a banner form, basically a two-entry table: query and modify.
Initial size: 2
Anticipated growth: 0
References: N/A
Referenced by: request_object
Fields:
id PK auto-generated
code: char(1), not null, shorthand for description, values will be m or q.
description: varchar(6), not null, values will be query or modify.
Friday, December 28, 2007
BSAR Specifications V.2
Note: This post can be viewed as a separate document at: http://docs.google.com/Doc?id=dgchtdp5_15c7dn9hdc
Banner Security Access Request - Draft Specifications, Version 2
Desired Process:
An authorized Coordinator receives a BSAR.
The Coordinator logs into the site and fills in the following information
The Requestor’s UH username
permissions desired (which classes or forms)
if it is for form access, whether the requestor needs query or modify privileges.
When the coordinator submits the request, the site does the following:
Retrieves the information of the Requestor.
Sends an email to the requestor with the FERPA notice. Email contains a link to the site where the user sees the FERPA notice again and clicks “Accept” or “Decline.”
After sending the FERPA notice:
If the user responds in the affirmative, go to the next step.
If no response, ping the user two more times, each after a period of one week. If no response after all three messages/wait periods, send an email to the coordinator stating there is no FERPA acceptance. The process is put on hold indefinitely until the coordinator cancels the request, or FERPA is accepted.
If the user clicks “Decline,” they are prompted to verify this decision, if they continue, then the coordinator is notified that this is a dead request.
Once the FERPA is accepted:
Scan the classes/forms requested and send emails to the appropriate persons responsible for approving those requests. The email includes a link to the request.
The approvers approve or deny the request by clicking a button on the site.
If no response from any approver, that approver is emailed again after a period of one week. This goes on indefinitely until they do something.
Once all approvers have responded
If all have approved the request, an email is sent to the Banner ID MGT list telling them the request is approved. The email contains a link to the request where it shows all pertinant information to create the request.
If all are denied an email is sent to the appropriate coordinator.
If some are denied and some are approved, the approved ones are sent to the Banner list, and the appropriate coordinator is informed of the denials.
BSAR: Banner Security Access Request
The process starts with an authorized user logging into the site. The user may have one or more roles. The possible roles are Requestor, Coordinator, Functional Lead, and Banner Access Control Unit (BACU).
These roles are defined as follows (copied from Darrin’s doc):
Requestor: Employee seeking access to Banner.
Coordinator: The contact person(s) authorized to make Banner access requests for a particular campus.
Functional Lead (AKA Approvers): Individual(s) designated to review and authorize access to specific functions (i.e. Accounts Receivables, Fin.Aid, Student).
BACU: Individual(s) that provide the technical support of establishing Banner access.
When an individual logs in, they may be directed to one of five locations depending on their role, or lack thereof. If the user has no role, they get an error message, otherwise they go to the page appropriate for their role. If a user has multiple roles, they will be directed to a page with tabs, where each tab handles a different role.
Here’s a high-level overview of the process as far as the site is concerned, details will be discussed in the appropriate section.
A Coordinator receives a request (via email, etc) for a new account.
The Coordinator logs in and fills out a form with the Requestor’s information, and submits the request.
The Requestor receives an email asking them to log in and approve a FERPA notice.
Once the FERPA notice is approved, Approvers are notified, as appropriate, that they have pending requests.
The Approver(s) log in and approve/deny the request.
Once all approvers have responded, the BACU staff receive an email telling them an account request is pending.
Once the BACU staff mark the request as completed, an email is sent to both the Requestor and the Coordinator.
For now, that is the extent of the system, although hopefully we can add in the ability to create/edit the requested account from inside the site as well.
The following sections will go through the actions of each role in depth.
Coordinator:
After logging in, the Coordinator comes to a page with several options: create/modify account, view/edit a pending request, or see all past requests.
All pending requests (those which have not yet been marked as completed by BACU staff), are in the pending requests table. While all requests with completed status are found by clicking on the “View past requests” link. Note that usernames in the pending request table are links to detail pages about the user and their request.
Coordinator, Request New Account (c2):
To request a new account, the Coordinator enters the UH username of the Requestor and clicks the “Create/Modify Account” button. The system checks to make sure this is a valid UH username and if the user has an existing account or not.
The Coordinator is shown the Requestor’s information (first and last name), fields for entering the classes/forms the Requestor wants to access, and a field for entering comments.
If on reviewing the Requestor’s information, the Coordinator discovers they have entered the wrong username, they click the “back” button to correct the mistake, otherwise, the user selects the appropriate classes/forms and clicks “Submit”. If no classes or forms are provided, the default set will be assumed by the BACU staff.
Upon submission, the class/form fields are checked to ensure they are proper class/form names. If errors are found, the form is repopulated and displayed, along with an error message next to the offending entry. If all values are correct, the Coordinator goes to a confirmation page which displays a standard “Your request has been submitted” message, a summary of the request, and a button to edit the request should there have been any mistakes. At the same time the Coordinator is seeing the confirmation page, the Requestor is sent an email asking them to log into the system and approve the FERPA notice.
Coordinator, Modify existing account (c2):
Changing a previously existing account starts off just like creating a new account: the Coordinator enters the UH username of the Requestor and clicks the “Create/Modify Account” button. The username is verified and their account information is retrieved.
The Coordinator is directed to the same page as described in the “Create New Account” section above, but there are two differences: Along with the information and forms described for a new account, there is a new form and a new button. The button is used to allow the user to see any pending requests, while the new form shows existing permissions.
Existing permissions consists of all classes and forms the Requestor has access to, the form level access (query or modify), and means to request removal of any of the permissions. This form is used only to modify or remove existing permissions, while new ones are entered below. Note: this assumes that we can import existing account information into the database.
With this page, the Coordinator can create a new request, or edit existing permissions for the current Requestor. Since this is an existing account, the user has already approved the FERPA notice, so the request is checked to see if any approvals are required, and if so, the Approvers are notified. If no approvals are required, an email is sent directly to BACU staff. If the Coordinator made changes to existing permissions in addition to asking for new permissions, both parts are bundled into one request.
Coordinator, Change pending request (c2b):
If from the create/modify account page, the user selects the button to view/edit pending requests, they are taken to a page where all pending requests for this user are presented. From there, the Coordinator can choose to cancel any of the requests, or edit them to add, remove, or change the requested permissions. If a modified request has already receive approvals, this may restart the approval process depending on the changes made.
Note that the pending request page is the same location the Coordinator goes to upon clicking one of the username links in the pending requests table on the Welcome page.
Requester, FERPA notice (r1):
When the request is submitted, an email is generated and sent to the Requestor asking them to click on a link to login and approve the FERPA notice.
If there is no response, the email is sent two more times, at intervals of one week each. If there is no response one week after the last notice is sent, an email is sent to the Coordinator for them to decide on the next action.
When the user logs in, they are shown the FERPA notice, along with three buttons: Approve, Decline, and Cancel Request. If the Requestor declines the FERPA notice, they are prompted with a warning telling them their Request will be cancelled if they do not accept. Should they continue, the request is marked as cancelled, and the Coordinator is informed. This is the same scenario for Cancel Request. Finally, if and when the user accepts the FERPA notice, the system checks to see if any approvals are required, and if so, notifies the appropriate Approvers. If no approvals are required, the request is sent directly to the BACU staff.
Approver, View Request (a1):
An Approver is notified of a pending request via an email containing a link to the site. When they log in, they see a table of all pending requests, a table of the most recent past requests, and a link to all past requests.
In the pending request table, the columns are as follows: date request was made, date Approvers were notified (this is the column the table is sorted by), Requestor’s username, a summary of the requested classes/forms that are under this Approver’s authority, and two columns of option boxes (approve and deny) which the Approver can use to handle the pending requests immediately.
Note that in selecting either the Approve or Deny option boxes and clicking save, the Approver will be marking all pertinent classes/forms in that request as approved or denied. If they want to approve part of the request, and deny part, each username in the pending table is a link to a details page (discussed later).
The table of recent past requests contains those which have been approved or denied, but are not yet marked as ‘Completed’ by BACU Staff. The link to all past entries takes the user to a table of all requests which have been marked as completed or cancelled. This table looks exactly like the pending request table except it includes the date the request was marked as completed.
The username links in all tables are the same, they all take the user to the request details page. The details page shows the Requestor’s information, the Coordinator’s information, comments, FERPA status, all existing permissions (previously approved requests), links to details of past requests, and the status of approvals for all classes/forms for this request, even those outside of the Approver’s authority.
While this page shows all parts of the request, including those not relevant to this user, they are segmented up into the different Approver’s categories. Each category will show which Approver is responsible along with the current status: Pending, Approved, Denied, Cancelled. Each Approver will be able to approve or deny the request as it pertains to the forms/classes they have authority over. The details page is also used should the Approver want to approve part of a request, but not all. There is also a field into which the Approver can enter comments, particularly a reason for a denial.
Note that this page can be used to set permissions for the individual parts of the given request. It can also be used to change previously set permissions. For example, if an Approver has been convinced to change a denied request to approved, and the request had been marked as complete, the request status would be changed to reopened and an email would be sent to the BACU staff asking them to add the newly approved permission.
When the Approver either approves or denies a request, and clicks the Save button, the request is removed from the list of pending requests and added to the list of recent past requests.
Once all Approvers have responded, providing at least part of the request was approved, an email is sent to the BACU staff notifying them of a pending request. If any Approvers denied the request, an email is also sent to the Coordinator so they can look into it.
BACU:
When all necessary approvals have been obtained, the BACU staff receive an email providing a link to the site. When the BACU staff log in, they see a table with all approved and pending requests. The table contains the following columns: date request made, date of BACU notification (sort column), Requestor’s username, Coordinator’s information (including campus), and the classes/forms requested. Should the BACU staff require more information about the request, each username in the table is a link that will take the staff member to a details page containing all the same information seen on the Approver’s user details page.
Each request in the table also has two option buttons: one to deny the request (only exists when the forms/classes require approval from the BACU staff), and another to mark the request as completed. If everything is approved, the BACU staff give the user access to the desired forms/classes and marks the request as finished by selecting the “Completed” option and clicking the “Save” button. If instead, the denial option is selected, the Coordinator is notified.
Feature Set:
All users:
Login/Logout
Coordinators:
Submit new account request
Submit change account request
Cancel existing request
Get notification of completion
Get notification of denial
Get notification of requestor cancellation.
Submit change to existing request
Requestors:
Send email for FERPA
Accept/Decline FERPA
Cancel request
Approvers:
Get notification of pending request
Approve/Deny request
Change approval/denial of pending/completed requests
BACU:
Get notification of pending request
See status (approvals, etc)
Mark request as completed or denied
Future feature: Search. Will need to be able to page through the results as well. The search feature should be searchable by user name and by the involved class/form (eg: who requested access to form ‘x’).
Changes:
V.1-> V.2
1.) Changed the coordinator form to get rid of the checkboxes for selecting classes and replace them with fields. It’s more efficient for the users given their subject matter familiarity.
2.) Merged c2 (add to existing user) and c2a (edit existing permissions) because it seems odd to have the user add in new permissions while not being able to see what the existing ones are without going to another page. This has the side affect of allowing multiple changes (new permissions, and changes to old ones) to be submitted in one shot, which is more efficient for all involved.
3.) Deleted question regarding if one user can hold multiple roles, as the answer is "Yes."
4.) Changed handling of a Coordinator submission where no classes/forms are entered. Instead of triggering an error, a default set of permissions is assumed.
Monday, November 19, 2007
BSAR specifications draft - version 1
Banner Security Access Request Form
Desired Process:
1.) An authorized Coordinator receives a BSAR.
2.) The Coordinator logs into the site and fills in the following information
a. The Requestor’s UH username
b. permissions desired (which classes or forms)
c. if it is for form access, whether the requestor needs query or modify privileges.
3.) When the coordinator submits the request, the site does the following:
a. Retrieves the information of the Requestor.
b. Sends an email to the requestor with the FERPA notice. Email contains a link to the site where the user sees the FERPA notice again and clicks “Accept” or “Decline.”
4.) After sending the FERPA notice:
a. If the user responds in the affirmative, go to the next step.
b. If no response, ping the user two more times, each after a period of one week. If no response after all three messages/wait periods, send an email to the coordinator stating there is no FERPA acceptance. The process is put on hold indefinitely until the coordinator cancels the request, or FERPA is accepted.
c. If the user clicks “Decline,” they are prompted to verify this decision, if they continue, then the coordinator is notified that this is a dead request.
5.) Once the FERPA is accepted:
a. Scan the classes/forms requested and send emails to the appropriate persons responsible for approving those requests. The email includes a link to the request.
b. The approvers approve or deny the request by clicking a button on the site.
c. If no response from any approver, that approver is emailed again after a period of one week. This goes on indefinitely until they do something.
d. Once all approvers have responded
i. If all have approved the request, an email is sent to the Banner ID MGT list telling them the request is approved. The email contains a link to the request where it shows all pertinant information to create the request.
ii. If all are denied an email is sent to the appropriate coordinator.
iii. If some are denied and some are approved, the approved ones are sent to the Banner list, and the appropriate coordinator is informed of the denials.
BSAR: Banner Security Access Request
The process starts with an authorized user logging into the site. The user may have one or more roles. The possible roles are Requestor, Coordinator, Functional Lead, and Banner Access Control Unit (BACU).
These roles are defined as follows (copied from Darrin’s doc):
1.) Requestor: Employee seeking access to Banner.
2.) Coordinator: The contact person(s) authorized to make Banner access requests for a particular campus.
3.) Functional Lead (AKA Approvers): Individual(s) designated to review and authorize access to specific functions (i.e. Accounts Receivables, Fin.Aid, Student).
4.) BACU: Individual(s) that provide the technical support of establishing Banner access.
When an individual logs in, they may be directed to one of five locations depending on their role, or lack thereof. If the user has no role, they get an error message, otherwise they go to the page appropriate for their role. If a user has multiple roles, they will be directed to a page with tabs, where each tab handles a different role. TODO: can this scenario happen? Does anyone ever hold multiple roles?
Here’s a high-level overview of the process as far as the site is concerned, details will be discussed in the appropriate section.
1.) A Coordinator receives a request (via email, etc) for a new account.
2.) The Coordinator logs in and fills out a form with the Requestor’s information, and submits the request.
3.) The Requestor receives an email asking them to log in and approve a FERPA notice.
4.) Once the FERPA notice is approved, Approvers are notified, as appropriate, that they have pending requests.
5.) The Approver(s) log in and approve/deny the request.
6.) Once all approvers have responded, the BACU staff receive an email telling them an account request is pending.
7.) Once the BACU staff mark the request as completed, an email is sent to both the Requestor and the Coordinator.
For now, that is the extent of the system, although hopefully we can add in the ability to create/edit the requested account from inside the site as well.
The following sections will go through the actions of each role in depth.
Coordinator:
After logging in, the Coordinator comes to a page with several options: create/modify account, view/edit a pending request, or see all past requests.
All pending requests (those which have not yet been marked as completed by BACU staff), are in the pending requests table. While all requests with completed status are found by clicking on the “View past requests” link. Note that usernames in the pending request table are links to detail pages about the user and their request.
Coordinator, Request New Account (c2):
To request a new account, the Coordinator enters the UH username of the Requestor and clicks the “Create/Modify Account” button. The system checks to make sure this is a valid UH username and if the user has an existing account or not.
The Coordinator is shown the Requestor’s information (first and last name), a form for entering the classes/forms the Requestor wants to access, and a field for entering comments.
If on reviewing the Requestor’s information, the Coordinator discovers they have entered the wrong username, they click the “back” button to correct the mistake, otherwise, the user selects the appropriate classes/forms and clicks “Submit”. At least one class or form is required, and if not provided, the form will redisplay with an error message.
In addition to checking that values were provided, the form fields are checked to ensure they are proper form names. If errors are found, the form is repopulated and displayed, along with an error message. If all values are correct, the Coordinator goes to a confirmation page which displays a standard “Your request has been submitted” message, a summary of the request, and a button to edit the request should there have been any mistakes. At the same time the Coordinator is seeing the confirmation page, the Requestor is sent an email asking them to log into the system and approve the FERPA notice.
Coordinator, Modify existing account (c2):
Changing a previously existing account starts off just like creating a new account: the Coordinator enters the UH username of the Requestor and clicks the “Create/Modify Account” button. The username is verified and their account information is retrieved. The Coordinator is directed to the same page as described in the “Create New Account” section above, but there one difference: Along with the information and forms described for a new account, there will be two buttons, one to view and edit any pending requests (if applicable), and one to view and edit any existing permissions. Note: this assumes that we can import existing account information into the database.
Coordinator, Change existing permissions (c2a):
When the Coordinator selects the button to view/edit existing permissions, they are shown all classes and forms the Requestor has access to, the form level access (query or modify), and buttons to request removal of any of the permissions. This form is used only to modify or remove existing permissions, not to create new ones.
If the Coordinator removes a permission, they will be prompted to verify their decision, and if confirmed, the system will send a notification email to BACU staff.
If the Coordinator changes the status of a permission from Modify to Query or vice versa, they click the save button and are prompted to confirm the changes. If the modification is to change the access type from Query to Modify, then the approval process starts (described below, in the Approver’s section), otherwise an email goes to directly to BACU staff.
Coordinator, Change existing request (c2b):
If from the create/modify account page, the user selects the button to view/edit pending requests, they are taken to a page where all pending requests for this user are presented. From there, the Coordinator can choose to cancel any of the requests, or edit them to add, remove, or change the requested permissions. If a modified request has already receive approvals, this may restart the approval process depending on the changes made.
Note that the pending request page is the same location the Coordinator goes to upon clicking one of the username links in the pending requests table on the Welcome page.
Requester, FERPA notice (r1):
When the request is submitted, an email is generated and sent to the Requestor asking them to click on a link to login and approve the FERPA notice.
If there is no response, the email is sent two more times, at intervals of one week each. If there is no response one week after the last notice is sent, an email is sent to the Coordinator for them to decide on the next action.
When the user logs in, they are shown the FERPA notice, along with three buttons: Approve, Decline, and Cancel Request. If the Requestor declines the FERPA notice, they are prompted with a warning telling them their Request will be cancelled if they do not accept. Should they continue, the request is marked as cancelled, and the Coordinator is informed. This is the same scenario for Cancel Request. Finally, if and when the user accepts the FERPA notice, the system checks to see if any approvals are required, and if so, notifies the appropriate Approvers. If no approvals are required, the request is sent directly to the BACU staff.
Approver, View Request (a1):
An Approver is notified of a pending request via an email containing a link to the site. When they log in, they see a table of all pending requests, a table of the most recent past requests, and a link to all past requests.
In the pending request table, the columns are as follows: date request was made, date Approvers were notified (this is the column the table is sorted by), Requestor’s username, a summary of the requested classes/forms that are under this Approver’s authority, and two columns of option boxes (approve and deny) which the Approver can use to handle the pending requests immediately.
Note that in selecting either the Approve or Deny option boxes and clicking save, the Approver will be marking all pertinent classes/forms in that request as approved or denied. If they want to approve part of the request, and deny part, each username in the pending table is a link to a details page (discussed later).
The table of recent past requests contains those which have been approved or denied, but are not yet marked as ‘Completed’ by BACU Staff. The link to all past entries takes the user to a table of all requests which have been marked as completed or cancelled. This table looks exactly like the pending request table except it includes the date the request was marked as completed.
The username links in all tables are the same, they all take the user to the request details page. The details page shows the Requestor’s information, the Coordinator’s information, comments, FERPA status, all existing permissions (previously approved requests), links to details of past requests, and the status of approvals for all classes/forms for this request, even those outside of the Approver’s authority.
While this page shows all parts of the request, including those not relevant to this user, they are segmented up into the different Approver’s categories. Each category will show which Approver is responsible along with the current status: Pending, Approved, Denied, Cancelled. Each Approver will be able to approve or deny the request as it pertains to the forms/classes they have authority over. The details page is also used should the Approver want to approve part of a request, but not all. There is also a field into which the Approver can enter comments, particularly a reason for a denial.
Note that this page can be used to set permissions for the individual parts of the given request. It can also be used to change previously set permissions. For example, if an Approver has been convinced to change a denied request to approved, and the request had been marked as complete, the request status would be changed to reopened and an email would be sent to the BACU staff asking them to add the newly approved permission.
When the Approver either approves or denies a request, and clicks the Save button, the request is removed from the list of pending requests and added to the list of recent past requests.
Once all Approvers have responded, providing at least part of the request was approved, an email is sent to the BACU staff notifying them of a pending request. If any Approvers denied the request, an email is also sent to the Coordinator so they can look into it.
BACU:
When all necessary approvals have been obtained, the BACU staff receive an email providing a link to the site. When the BACU staff log in, they see a table with all approved and pending requests. The table contains the following columns: date request made, date of BACU notification (sort column), Requestor’s username, Coordinator’s information (including campus), and the classes/forms requested. Should the BACU staff require more information about the request, each username in the table is a link that will take the staff member to a details page containing all the same information seen on the Approver’s user details page.
Each request in the table also has two option buttons: one to deny the request (only exists when the forms/classes require approval from the BACU staff), and another to mark the request as completed. If everything is approved, the BACU staff give the user access to the desired forms/classes and marks the request as finished by selecting the “Completed” option and clicking the “Save” button. If instead, the denial option is selected, the Coordinator is notified.
Feature Set:
All users:
1.) Login/Logout
Coordinators:
1.) Submit new account request
2.) Submit change account request
3.) Cancel existing request
4.) Get notification of completion
5.) Get notification of denial
6.) Get notification of requestor cancellation.
7.) Submit change to existing request
Requestors:
1.) Send email for FERPA
2.) Accept/Decline FERPA
3.) Cancel request
Approvers:
1.) Get notification of pending request
2.) Approve/Deny request
3.) Change approval/denial of pending/completed requests
BACU:
1.) Get notification of pending request
2.) See status (approvals, etc)
3.) Mark request as completed or denied
Future feature: Search. Will need to be able to page through the results as well. The search feature should be searchable by user name and by the involved class/form (eg: who requested access to form ‘x’).
Subscribe to:
Posts (Atom)