W20 Initial Thoughts

We’re working on redesigning/upgrading the Forms, primarily to accommodate co-op sequence change forms. (Unfortunately, this work did not get completed before the coop student moved on. As a result, the forms subsystem is in a poor state of repair.)

Forms are already being used in other settings, primarily for faculty transfer processes. Whatever we do here needs to preserve functionality for those other processes. We’d like the functionality to be general enough to support lots of processes.

Overview

  • A form may have multiple “Decision Fields”, one for each of the people that are part of the decision-making (e.g. academic advisor + coop advisor).
  • All of the decision fields need to agree on the same value before further actions are taken.
  • If any values are changed in the form, all decisions are cleared.

Valid Decisions

Add a block to the form definition json to specify valid decisions for the form. Each decision needs the following fields:

  • ID such as “admitted” or “denied”. This is also what will be inserted into the database as the value of the decision.
  • UI Text: What should be displayed in the user interface to select that decision
  • Student Letter: Which letter to send the student for this decision.
    • I think this should reference a template in the bulk mail system. Use that infrastructure to create/edit it.
    • Can also use Bulk Mail to send in bulk, when that’s the right thing to do.
    • Long term, we need to think about what the triggers are that send the letter. We might have a field in the letter block that specifies:
      • Send as soon as all deciders have signed off.
      • Send as a batch using a button on the new Admin page.
      • Others?
    • JSON is a really unfortunate format for long strings. Should this just be a pointer to something else – e.g. a database table with associated editor like bulk mail?
    • Is there a way to tie into bulk mail and/or reused significant parts of bulk mail? That makes sense for decisions that are made in batches, but what about decisions that are made in 1’s and 2’s?
  • Who else needs to be informed and how? RegOffice may need to be informed for some decisions but not others. Probably a spreadsheet rather than an email letter.

Decision Widget

Create a decision widget. It would be very much like the RadioButton form widget except that it would get valid values to display from the Valid Decisions block of the json. The widget will also need a way to clear the decision (if a RadioButton).

The decision widget might be used multiple times in the same form. Eg once for a math academic advisor and once for a coop advisor. Each decision will need to be stored in the database.

Like other widgets, will implement a particular feType in the list of form entries in the json.

The form entry json block should include userids of who are able to decide. The widget should be disabled for anyone not in that list (but should be able to see what others have decided). [I wonder if that should actually be a pointer to a list of userids. I can imagine, for example, lots of coop forms for different groups but each with the same coop advisor to approve. A pointer would make it much easier to update. But perhaps this is such a rare event that we’d never recoup the programming cost.]

The widget should also work with the bulk change mechanism.

Adjust Existing Widgets

If a value submitted by a student changes, then decisions (of folks not making the change) should be set back to null or undecided. For example, sometimes an advisor will adjust a coop sequence from what the student input or a list of courses to take in the next term.

A user should be able to cancel out of the change. Put another way, only make the change on “update form”.

Make a widget for Coop stream changes

It would be nice to prepopulate the existing sequence from Coop data. Means we need to get the coop data.

Open Questions

  1. How do we trigger the “inform interested parties” process? I think sometimes a batch process (eg from the maintenance page) would be the best solution; sometimes a 1-by-1 as the decisions are made would be best.
  2. Assuming the RO gets informed via a spreadsheet, what info should be in it?
  3. Who, besides the RO, might need to be informed?