| Table of Contents |
|---|
Overview
Phase 1 Map Status Calculation will feature a cron job that calculate plan statuses for all active plans as detailed in the Phase 1 requirements doc (/wiki/spaces/SSP/pages/103986907). 2 will introduced some enhance calculation features. The scope of which is defined as subtasks of
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
MAP Plan Status Calculation Implementation Details
...
Map Plan Status Calculation Flow Chart
...
...
Map Plan Status Schema
| Gliffy | ||
|---|---|---|
|
Map Status Data Dictionary
MAP_STATUS_REPORT (Process will produce one row per active plan assigned to an active student.)
| Column | Type | Notes |
|---|---|---|
| id | uuid | primary (technical) key, unique identifier |
| plan_status | varchar(enum) | originally proposed as a boolean, I think an enum here will give us more flexability |
| note | varchar | high level detail about the status calculation |
| plan_ratio | decimal(2,2) | the percentage of plan courses satisfied as 'on plan' |
| plan_id | uuid | foreign key to MAP_PLAN(id) |
| person_id | uuid | foreign key to PERSON(id) - student |
| modified_by | uuid | id of person modifying reference |
| created_by | uuid | id of person creating reference |
| modified_date | date | date modified |
| created_date | date | date created |
| object_status | enum | standard object status |
...
| title | Comments |
|---|
...
| status |
...
MAP_STATUS_REPORT_COURSE_DETAILS (Process will produce one row per anomaly per active plan. An errorless plan will produce zero rows.)
...
| Column | Type | Notes |
|---|---|---|
| id | uuid | primary (technical) key, unique identifier |
| report_id | uuid | foreign key to MAP_STATUS_REPORT(id) |
| term_code | varchar | soft reference to EXTERNAL_TERM(code) Plan course term code being substituted |
| formatted_course | varchar | soft reference to EXTERNAL_COURSE(formatted_course) Plan course formatted_course being substituted |
| course_code | uuid | soft reference to EXTERNAL_COURSE(code) Plan course course_code being substituted |
| substitution_code | varchar | code that identifies the specific course level violation |
| substitution_note | varchar | detailed information about specific course level violation |
| substituted_term_code | varchar | soft reference to EXTERNAL_TERM(code) the substituted term code |
| substituted_formatted_course | varchar | soft reference to EXTERNAL_COURSE(formatted_course) the substituted formatted_course |
| substituted_course_code | uuid | soft reference to EXTERNAL_COURSE(code) the substituted course_code |
| modified_by | uuid | id of person modifying reference |
| created_by | uuid | id of person creating reference |
| modified_date | date | date modified |
| created_date | date | date created |
| object_status | enum | standard object status |
| Info | ||
|---|---|---|
| ||
|
Integration
EXTERNAL_SUBSTITUTABLE_COURSE (Used to define course substitutions for plan calculation)
| Column | Type | Notes |
|---|---|---|
| term_code | varchar | term code for the substitution. if null applies to all term. |
| program_code | uuid | program code for the substitution. if null applies to all programs |
| source_formatted_course | varchar | formatted course, matched to the plan course |
| source_course_code | varchar | course course, matched to the plan course |
| source_course_title | varchar | course title, matched to the plan course |
| target_formatted_course | varchar | formatted course, matched to the transcript course |
| target_course_code | varchar | course code, matched to the transcript course |
| target_course_title | varchar | course title, matched to the transcript course |
| Excerpt | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
New Configurations
|
| Info | ||
|---|---|---|
| ||
| passing_grades: Dan also questioned the need for more complexity. Maybe I'm missing something that you both are seeing. The basic functionality is to check to see if the grade the student was awarded on their transcript is a passing grade. |
Matching criteria
Different schools may have their course/transcript data organized differently. This means they may want different criteria to drive the matching logic between plan and transcript. We will assume that three criteria are non-negotiable and static; term_code and formatted_course. In addition to the static matching criteria, implementors have the option to add additional criteria. COURSE_TITLE will match PLAN_COURSE.COURSE_TITLE to EXTERNAL_STUDENT_TRANSCRIPT_COURSE.TITLE and CREDIT_HOURS will match PLAN_COURSE.CREDIT_HOURS with EXTERNAL_STUDENT_TRANSCRIPT_COURSE.CREDIT_EARNED.
Implementation Concerns
- System load and memory footprint will be big concerns for the calculation process. We don't want to load all active plans into memory at once. Implementors may not want to have cron job run during business hours as it could put load on the web server and database.
- Configuration map_plan_status_cutoff_term_code is a maintenance concern. Will most likely have to be updated every term. This must be clear to implementors.
- map_plan_status_passing_grades may not be very flexible enough for a lot of schools. We may want to explore a hierarchical configuration approach.
Open Questions
...
In addition for phase to, course code is being added to external_student_transcript_course so COURSE_CODE will be added as an additional criteria. Which will match EXTERNAL_STUDENT_TRANSCRIPT_COURSE.COURSE_CODE with PLAN_COURSE.COURSE_CODE.