This is a subsequent feature following on to Kanban#4650, where we have the configuration-sets stored in the database. Even with #4650, we still have to the export cron jobs on the server via chef.
A workflow improvement would be to add an admin UI that allows the registrar team to define these export jobs and whether or not they are currently active (exporting nightly). The cron job would then export all active jobs each night
Here is a mock-up of such a screen:
Configuration components for each job:
Is active? -- if true, the job will be run each night. Otherwise it will be skipped. Rather than trying to configure start/end dates, it is probably more straight-forward to just manually change this value. The big reason to turn off a job after the semester is over is to do so before changing configs or other data, which can all be done together.
Export path -- A directory to export into. This should allow subdirectories of the archive base to be defined, but prevent .. or directory traversal.
Configuration Set -- which of our defined configuration sets to use for this job. Should supply a drop-down list. Because the configuration set defines which catalog to use, changing this would potentially invalidate the terms available.
Configuration Version -- Defaults to "Latest". By allowing a particular configuration version to be chosen, exports for a current year can still be run while new configuration is changed and edited for an upcoming year (e.g. new program added or removed for the upcoming year).
Terms -- Which terms to use for this export job. These will be terms associated with the catalog defined in the configuration set. One or more are possible, so the UI will need to allow some mechanism for multi-select. If the Catalog associated with the configuration set (or the config set) changes, then the terms should show an error (at least on activation) until they are updated.
Additionally, it would be useful to provide a button to manually trigger a particular export from the UI. This would allow testing of configuration during its setup. As the export may take many minutes, a progress bar should be shown by dividing the number of sections by 100 to get a percentage. Partial content (the status ticker) will need to be flushed periodically to prevent time-outs on the long operation. This could be displayed in a JS overlay or it could be a full-screen ticker that just shows the response as it comes in. The export should also clear the varnish-cache for the particular archive-path only subsequent to the regeneration.
This is a subsequent feature following on to Kanban#4650, where we have the configuration-sets stored in the database. Even with #4650, we still have to the export cron jobs on the server via chef.
A workflow improvement would be to add an admin UI that allows the registrar team to define these export jobs and whether or not they are currently active (exporting nightly). The cron job would then export all active jobs each night
Here is a mock-up of such a screen:
Configuration components for each job:
..
or directory traversal.Additionally, it would be useful to provide a button to manually trigger a particular export from the UI. This would allow testing of configuration during its setup. As the export may take many minutes, a progress bar should be shown by dividing the number of sections by 100 to get a percentage. Partial content (the status ticker) will need to be flushed periodically to prevent time-outs on the long operation. This could be displayed in a JS overlay or it could be a full-screen ticker that just shows the response as it comes in. The export should also clear the varnish-cache for the particular archive-path only subsequent to the regeneration.