FY25.2.x: Technical Design (Slate+Advising)

Executive Summary

The purpose of this document is to provide the full details of the technical solution to be used for the build of the Slate+Advising solution. Everything that is needed by the developer(s) to produce the required data model, forms and workflows will be included in this specification.

Technical Components

The following sections will detail the technical components within each functional area that are required to successfully implement this project.

Data Requirements

Purpose

Define any integrations or data that must be provided to deliver the solution.

• HBCU/CUNY Fellows
  • Create a prompt key called "Fellowships" with a prompt called "HBCU" and a prompt called "CUNY."
  • Create a select multiple field called "Fellowships" that utilizes the fellowships prompt.
  • Create a source format called Fellowships, with the following settings:
    • Type: Cumulative/Replaceable
    • Update Only: Update Only
• Programs of Study Prompts
  • For each program of study, set the category to MS (Masters of Science), MPS (Masters of Professional Studies), or NDG (non-degree).
  • Change the prompt key so that the export value is labeled as "Program Code."
• Registration Monitoring
  
  • Create a new entity called Registration Monitoring, consisting of the following fields:
    • Term - select with the school year terms prompt list.
    • Status - select with the following prompts:
      • Intends to Register - Near Future (No Holds)
      • Intends to Register - Resolving Hold
      • Intends to Register - Waitlisted
      • Intends to Register - Waiting on Cross-Reg
      • May Not Register - Considering Decline/Deferral
      • May Not Register - Resolving Hold
      • May Not Register - Other (Please List)
      • Non-Responsive to Outreach
      • Will Not Register - Deferral/Decline
      • Will Not Register - Hold
      • Will Not Register - Other (Please List)
      • Other (Please List)
      • NOW REGISTERED!
      • Graduate - October
      • Graduate - February
      • Graduate - May
    • Notes - textbox
  • Create a new prompt for the advising reason key called "Registration Status."

Technical Design

Purpose

Define in detail the technical work that will need to be completed to deliver the final solution.

• HBCU/CUNY Fellows
  • Upload a spreadsheet consisting of a column for PID and a column for Fellowship. PID should match to CUID and Fellowship should match to Fellowships. Each student should have a row for each fellowship (in the unlikely case that one student has both fellowships, s/he should have one row for each on the spreadsheet).
  • Add a field on the dashboard pages of students, former students, and alumni that shows "Fellowships" and lists any fellowships that the student has.
  • Create a population for HBCU Fellows and one for CUNY Fellows.
  • Create a rule called "Assign HBCU Fellows" and one called "Assign CUNY Fellows." Assign students who have either value to the appropriate population.
• Advisor Scheduling
  
  • Make a copy of the "Meet our Advising Team Portal" called "Schedule an Advising Session."
    • Create a view for each advisor called "Advisor - [advisor's name]."
      • This view will consist of the advisor's scheduling widget(s) as a well as a blank div below them.
    • Create a method for each advisor called "Advisor - [advisor's name]
      • The action that trigger's that method should be: show_schedules_[advisor's UNI]
      • The method should have an output type of "AJAX Popup/No Branding."
      • The method should have a view of the respective advisor's view page.
    • Create a view page called "my_advisor" comprised of:
      • Advisor information - which comes from the displayed information about each advisor in the "Meet our Advising Team" protal.
      • A heading for the section containing the scheduling widget.
      • A section that makes LazyFetch api call to retrieve and display the advisor's seheduling widgets.
      • A javascript section at the bottom, have code that repeats every millisecond to see if the blank div exists. Because this div is below the advisor's schedule widgets, it will be rendered after them. Therefore, once the blank div has been rendered, we can check to see whether the advisor has any scheduling widgets. If either the blank div does not exist OR the advisor does not have widgets, display an error that the adivsor does not have online scheduling.
      • Each of the above sections is wrapped in an if/then statement based on whether the advisor has a first name. If not, the query to obtain advisor information yielded no results. Therefore display an error that the user has reached an invalid page.
    • Create a default method called "advisor_scheduling."
      • The method will use the advisor_uni parameter in the URL to call the advisor_info query to obtain information about the selected advisor. The query should filter for people with a role as an advisor. So that if the uni is a match to user, but that user is not an advisor, no information will be returned.
      • The method will display the "my_advisor" view page.
    • Change the URL of the "Meet our Advising Team" portal to a dummy one.
    • Make the "Meet our Advising Team" portal inactive.
    • Change the URL of the new portal to: https://advising.sps.columbia.edu/portal/advising_team for a seamless user experience.
• CDL Coach Scheduling Portal
  • Rather than putting the list of eligible programs into the code using their full names, create a query of eligible programs exporting their 5 character program codes.
  • Remove code that became obsolete with the update above (removing spaces and punctuation from the list of codes, removing the conversion of a list of programs in text to an array, etc.)
  • Replace the two separate exports in the query that gets students' pending virtual and in-person coach meeting. Replace that with an existence export of whether or not the student has pending appointments. Fix the code in the portal to prevent the student from scheduling a session based on the revised export.
• Registration Monitoring Tab
  • Create a tab on the main student page for Registration Monitoring, consisting of the following:
    • An entity widget for the registration monitoring entity, consisting of the following fields:
      • Status Created Date
      • Term
      • Status
      • Notes
    • A list of advising notes of the type "Registration Status."
• Registration Monitoring Portal
  • Create a user portal that allows advisors to look at students in the programs that they represent who are expected to register in the upcoming term but have not. The portal will also allow for a future inclusion of statistical analysis of registration monitoring status of students against budget projections. The portal will consist of:
    • Queries
      • available_programs - a list of all the programs for which registration monitoring is used. This will be used to populate the program filter. They are:
        • Actuarial Science
        • Actuarial Science -- Online
        • Actuarial Science -- Online (CPF)
        • Applied Analytics
        • Applied Analytics -- Online
        • Bioethics
        • Bioethics -- Online
        • Bioethics -- Online (Cert)
        • Bioethics (Cert)
        • Bioethics and Public Health -- Dual
        • Biotechnology
        • Classics
        • Construction Administration
        • Critical Issues in International Relations
        • Ecology, Evolution & Environmental Biology
        • Enterprise Risk Management
        • Enterprise Risk Management -- Online
        • Enterprise Risk Management -- Online (Cert)
        • Enterprise Risk Management (Cert)
        • Human Capital Management
        • Human Capital Management -- Online
        • Human Rights
        • Information and Knowledge Strategy
        • Information and Knowledge Strategy -- Online
        • Insurance Management -- Online
        • Narrative Medicine
        • Narrative Medicine -- Online
        • Negotiation and Conflict Resolution
        • Negotiation and Conflict Resolution -- Online
        • Nonprofit Management
        • Nonprofit Management -- Online
        • Political Analytics
        • Psychology
        • Quantitative Studies for Finance
        • Sports Management
        • Strategic Communication
        • Strategic Communication -- For Executives
        • Strategic Communication -- Online
        • Sustainability Analytics
        • Sustainability Management
        • Sustainability Science
        • Sustainable Finance
        • Sustainable Finance -- Online
        • Sustainable Water Management
        • Technology Management
        • Technology Management -- For Executives
        • United Nations Studies
        • Visiting -- Arts in the Summer
        • Visiting -- College Edge
        • Visiting - College Edge -- Gap Commuters
        • Visiting -- Columbia Secondary School
        • Visiting -- Foreign Language
        • Visiting -- Graduate
        • Visiting -- Postbaccalaureate
        • Visiting -- Undergraduate
        • Wealth Management -- Online
      • student_list - A list of all of the students eligible for registration monitoring, with the following features:
        • Exports:
          • First name
          • Last name
          • UNI
          • Program of study
          • Admit term
          • Admit term code
          • Most recent registration monitoring status (toward the relevant term) created date
          • Most recent registration monitoring status (toward the relevant term)
          • Most recent registration monitoring notes (toward the relevant term)
          • Whether or not the student has had a registration monitoring status entered in the last 7 days.
        • Filters:
          • Status (new, continuing student)
          • Program of study (in the list of relevant programs above)
          • Either does not have a most recent registration monitoring status (toward the relevant term) OR has a status, but it is not one of the graduating statuses.
          • Does not have any classes with a registration status of "Add" for the relevant term.
    • Views
      • Homepage - consisting of:
        • A  message welcoming the user to the registration monitoring system.
        • Which term registration monitoring is in effect.
        • A drop-down menu for the user to select whether they want to manage registration monitoring for their students or analyze statistics.
          • Upon making a selection and pressing the button:
            • The drop-down menu and button will become disabled.
            • A message will appear that the data is loading.
            • The user will be redirected to the appropriate page.
      • Show Students - consisting of:
        • filters - a section where the user can select which population s/he would like to view: 
          • Program of study (select multiple)
          • Admit term (select multiple)
          • Starting letter of the alphabet (textbox)
          • Ending letter of the alphabet (textbox)
        • student_list - a hidden table listing the students with the following columns:
      • • • Name and UNI
          • A link to send an email through Slate.
            • Upon clicking thls link, a separate window will pop-up with the student's profile page. The Slate send email pop-up window will appear.
            • Users can keep this window open, ideally in a second monitor. If they do, any future email links they click will open in this same window.
          • Most recent registration monitoring status (toward the relevant term) date
          • Most recent registration monitoring (toward the relevant term) status.
          • Most recent registration monitoring (toward the relevant term) notes.
          • A link to the student's registration monitoring tab. (opening in a separate window)
            • The link will be connected to an onchange event that performs the following actions:
              • It will check every 0.1 second to see if the window has opened and if the link to add a registration monitoring status is present.
              • Once it is, it will add an event listener to that link. This will be a function that checks every 0.1 second to see if the form to add a new status has loaded and if its button is present.
              • If the button is present, it adds an event listener to it, so that when it is clicked:
                • It will collect the data entered on the form.
                • It will wait until the window closes.
                • It will enter the details of the status on to the row.
          • A link to the student's advising notes related to registration monitoring (opening in the same window as the registration monitoring link above, but without any of the JavaScript functions)
          • A button to mark the row as updated.
            • When the user clicks it, all of the cells except for name/UNI and email are merged together and replaced with the word "updated." (No change is made to the student's record.
        • Javascript functions:
          • Upon loading the page, cycle through the list of students to see if there are students with an admit term of "(not set)." Otherwise, identify the earliest available admit term and the latest available admit term year.
          • For the admit term filter, begin if there are students with a "(not set)" designation, put that on the list. Starting with the latest year, cycle through the years one by one, adding "Fall," "Summer," "spring," to populate the admit term filter (e.g. "Fall 2024," "summer 2024," "Spring 2024.") 
        • Filtering functionality:
          • When the student selects filters and clicks the submit button:
            • The selected program and admit term filters are captured and converted to an array.
            • The starting and ending last initials are converted to numerical values.
            • The student list is cycled through. Each row is checked to see if it is currently displayed.
              • If it is currently displayed, check to see if there are any filters for which it should not be included. If so, hide the row.
              • If it is not displayed, check to see if it should be included in all filters. If so, display the row.
            • The number of displayed rows is counted and listed at the top.
            • If there are no students that match the filters:
              • Display a row that says there are no matching students.
              • There are three columns on the table that do not have headings. Instead, there is a blank cell that is three cells wide and two cells high. If the "no matching students" row is displayed, it does not look good if that cell is included. Therefore, the "no matching students" row is three cells narrower and the blank cell on top has to be removed. If we go from displaying no students to displaying a list of students, we need to re-create that cell. 
    • Statistical analysis page (to be developed later).