SOLUTIONS REQUEST PORTAL OVERVIEW AND WORKFLOW¶
This document gives a basic high-level overview of the workflow involved in the Request Portal program and process.
These notes are written by Alyssa Siegel, Solutions creator & developer.
Contact: siegel@math.rutgers.edu
PHASE 1: STUDENT REQUEST SUBMISSION VIA WEBSITE¶
Online request forms have been created using the Chronoforms Joomla extension. These forms are linked to in various places from the Math Department’s website, and are also included in the printed instructions our office hands out to students who, for example, ask how they can submit a transfer credit request.
Links to all forms exist on the “Undergraduate Forms” page of our website, which is here: https://math.rutgers.edu/academics/undergraduate/additional-resources/undergraduate-forms
To view the design of these forms:
log into Joomla as math department administrator
go to “Components” then “Chronoform5”
forms being used are the following, which should appear in the list of forms:
SPHONORS(special permission into honors class requests)TransferCreditPreapproval(transfer credit preapproval requests)TransferCourseDepartmentalEvaluation(transfer credit postapproval requests)PREREQ(prerequisite override requests)SP_NonMatriculated(special permission for non-matriculated students requests)SMPF(special permission when a student has failed a course multiple times)
In the form listings, there is a column titled “Form ID”. This column gives a number assigned to each form (for example, the SPHONORS form has Form ID 10). This will become relevant later.
When each of these forms receives a student’s submission, the following happens:
data is saved to the table connected to the form in question (see column titled “connected tables” in the form listing to view the data)
an email is sent to requests@math.rutgers.edu with student’s response in a standardized format
Some history: when Request Portal was first implemented, the only way to get the requests into the Solutions database was by saving the emails received via (ii) as an eml file, and then having office staff import the saved file into Request Portal via its interface. This process has since become obsolete since we now use the choronform tables and python program process for submissions (this is explained further on in this document). However, we never decommissioned the requests email inbox and having the form submissions send these emails because we still look at them on occasion to troubleshoot if needed and ensure that all request emails have correctly been saved to the Request Portal MySQL data.
PHASE 2: REQUEST DATA-FLOW¶
Here is how data moves from student request submission into our MySQL database:
When student submits request, data is saved to the form’s associated chronoform table
A python program, getforms2.py downloads data from these tables and saves to one of our internal MySQL tables. The table data gets saved to is called cfdata_<formid>. For example,
SPHONORShas chronoform form id = 10, so submissions from this form will be saved in a table called cfdata_10. This program is set up to run (on Linux machine) every 15 minutes via crontab configuration (see solutions_python repository for more information about this).The Solutions Control Center program, when running, will scan the cfdata tables every 15 minutes to look for new submissions. When new submissions are found, the program will do some screening (i.e. check for duplicate requests etc) and translate the data into new requests viewable by the RequestPortalDashboard program (tables used are tbl1_requests, tbl1_students and the request-type specific tables, for example tbl1_SPHonorsRequests) Log messages will be appended to the control center log viewers for newly imported requests
Here is more detail of what happens in this phase:
NEW STUDENT CHECK via RUID value¶
Student-entered RUID is compared against students already in the tbl1_students table. If there is a match, the program will assume this is a student not already in our database and add them as a new student record before adding the new request data.
WARNING: once and only once, we hit a crazy situation where a student mistyped their RUID, and their typo happened to match a different student’s RUID, who was already in the database! This led to my needing to manually go into database and sort everything out and cleanup data. To try to prevent this scenario in the future, I added some logic to skip the request if we have an RUID match but the student names appears different based on inconsistent first and/or last names with existing student, looking at first letters of names. This also got tricky because sometimes – especially with Asian students – they may get the first and last name fields mixed up. If the program is uncertain that it is same student, the request is skipped and a log message left on event log indicating that this happened. I don’t think we have had any issues here since the original incident. By the way, since requests like this might be “skipped”, this is one of the reasons I have left the code in the program to still manually import emails. This way staff could still theoretically manually import a skipped request if they feel it should not have been skipped. This happens very rarely.
SCREEN FOR DUPLICATE REQUESTS¶
request is screened to see if it looks like a duplicate of a previously submitted request. Here are the criteria that determine a possible duplicate request:
Transfer Credit Preapproval Requests: An existing preapproval request with same: student, course start date, course end date, semester, year, course name, course school and status not withdrawn (note: it is very rare that this type of request would be flagged as a duplicate because of the free-form nature of the data accepted in these fields).
Transfer Credit Postapproval Requests: An existing postapproval request with same: student, semester, year, course name, course school and status not withdrawn (note: it is very rare that this type of request would be flagged as a duplicate because of the free-form nature of the data accepted in these fields).
Special Permission Honors, Special Permission Multiple Fails and Prerequisite Override Requests: An existing request with same student, semester, year & course and status not withdrawn.
Special Permission for Non Matric Students Requests: These will never be screened for duplicates, since unlikely and hard to catch.
IF a request is flagged as a possible duplicate, there are three possible ways this is handled:
Add a new request and mark it as ‘duplicate’
This method is used for prerequisite override, special permission honors & transfer credit requests. With this method, a new request will be added to the database, but the ‘duplicate_request’ checkbox will be checked and an indication that the request is a duplicate will appear in the status-of-request column when viewing request lists
Merge with existing request, keeping decision of original
This method is used for multiple fail requests. New request is merged with existing request, decision is left unchanged, a note is added to evaluator notes field that student re-submitted, and a note added that duplicate request was merged with current
Request is skipped
Special Permission for non-matric (SPNM) requests are skipped if duplicate is detected (which will never happen per the above rules, but the code for this is there in case we want to move to using this technique in future)
NOTE: when we used to manually import emails from saved email files, we were able to give an message summarizing new request and existing request and let user decide whether the requests should be merged, skipped, etc. But when we automated all of this, we needed to change the algorithm to what made the most sense given that the user could not respond to a prompt in the moment.
DETERMINATION OF EVALUATOR¶
When adding new requests, the default value for the EvaluatorID field is -1 which corresponds to evaluator to be determined (EVALUATOR_TBD).
But then, the program algorithm will see if it can determine who to automatically assign the request to based on rules in the tbl1_evaluators table.
The user can configure this table through RequestPortalDashboard, “Evaluators” button on main window, which drives updates of the tbl1_evaluators table.
For each evaluator, there are fields to indicate:
which type of requests each evaluator handles
for each request type, the starting and ending 3-digit course number range that indicate which courses range should be assigned automatically to this evaluator (we use this, for example, to indicate that all courses pre-calc and lower go to Lew Hirsch).
an “Exceptions” field can be used to indicate “outlier” courses. So, for example, if an evaluator is to be assigned all course 000-135 IN ADDITION TO courses 255 and 471, they would put 000 and 135 in the from/to field and 255*471 in the “exceptions” field.
Also, a “Default Evaluator” can be indicated who might automatically be assigned if none of the other rules can uniquely determine another evaluator.
PHASE 3: EVALUATIONS OF REQUESTS¶
Once requests are in the Solutions request tables, evaluators can start their dashboard programs (RequestPortalDashboard) and filter lists to show open requests assigned to them.
For the most part, evaluators who are expecting requests know to open up their dashboards, and view requests assigned them that still have “open” (or “revisit”) status. However, in cases where evaluators may not know (or when they fall behind in working on their request evaluators), office staff might go into the request portal, look up one of their pending requests, and click the “email evaluator” button to send an email-notification to tell evaluators that their requests are waiting for them.
[If we want to get fancy in the future, this is an area where there is space for growth. For example, evaluators could automatically be emailed a summary of their new requests when they are assigned. Or, we could automatically scan for requests that have not been resolved within N number of days and send a report of this to supervisors and/or that evaluator. With our current office procedures, we have been telling students that they should receive their decision within a week, so N would be 7 days.]
When they make decisions, they can change status of requests via the interface and then notify the appropriate offices of decisions (based on type of request and university procedures). Each request-type window within Request Portal has buttons to kick off an email for the appropriate notification types required by each request type.
Also note that there is a very large, configurable list of email templates (configurable via request portal “Email Templates” button) that contain the default email wording for each combination of request type / request decision / email recipient.
Specifically, per request type:
Special Permission Honors requests: email student (xx)
Prerequisite Override requests: email student, email registrar, print override form (which student will pick up from office)
Transfer Credit: email student, email student’s school advising office, email other advising office
Special Permission Non-Matriculated: email student (xx)
Special Permission Multiple Fails: email student (xx)
xx:
These request types also require assignment of a special permission number. These numbers are in the tbl1_SPNumbers table and there is another workflow within Solutions where office staff pre-populates the list with available, usable numbers per course and section. Office staff (Patty, Phoebe, and formerly Sally can give more detail on this process)
Also, each request type has an “Email Student” button if evaluator has questions for students along the way.
TABLES UTILIZED IN REQUEST PORTAL WORKFLOW¶
cfdata_x
chronoform request submission “placeholder” tables
contact person for each school’s advising office, used when emailing transfer credit decisions
this may be obsolete, had been used for contact name of person in our office but not sure it is still used for anything
email templates used in request portal.
evaluators who might be assigned requests
contact info for registrar’s office to email decisions. This changes per semester (summer has different contact)
request detail for prerequisite overrider requests (1 to 1 correspondence with tbl1_requests)
tbl1_request_importer_EventLog
log messages about requests that have been imported
tbl1_request_importer_last_scans
timestamp of last request imported for each request type
main request table, one row for each request
introduced so I could disallow scenario of more than one user working on same request. the “Reset Locks” button empties this table in case of problems.
request detail for special permission honors requests (1 to 1 correspondence with tbl1_requests).
request detail for special permission multiple fail requests (1 to 1 correspondence with tbl1_requests).
request detail for special permission non matric student requests (1 to 1 correspondence with tbl1_requests).
list of special permission numbers assignable to approved requests.
students who have submitted requests in the past.
request detail for transfer requests, both preapproval and postapprovals (1 to 1 correspondence with tbl1_requests).