Schedule Tracking Admin/UI Interactions
Rob LaRubbio
I was wondering if maybe we don't have the same vision for the larger
context of the module. So I'm going to try and describe that here to
see if that might be contributing to some of the difference of opinion.
It's important to keep in mind the ultimate end goal of the platform
which is that eventually implementers will have little or no code to
write to deploy a solution on top of it, and that end users can easily
operate the system when it is in production.
For the schedule tracking module the hope is that in the (not too
distant) future there is an admin panel. The admin UI would allow end
users to see installed schedules, modify them and add new one. The end
user would select a schedule and be presented with a text box (hopefully
a better UI in the longer term). In that text box they can edit the
JSON config. Once they submit the config the system will validate the
JSON, store it in the DB and generate the associated rules. This would
either overwrite the previous set of rules and definitions or optionally
we can version the schedule and rules and leave previous enrollments in
the previous version.
At runtime when a new fact (event) is entered, a timer fires or a new
enrollment is entered the system would load the rules and relevant facts
and present the information to the rules engine. The output would then
be used to update timers, modify any state related to the enrollment and
fire alerts related to the windows.
Hopefully this information helps provide some more context. If you have
any questions or comments about the above information please share them.
-Rob