mirror of
https://github.com/cpvalente/ontime.git
synced 2026-09-07 07:19:16 +00:00
a905bf912f
Making an automation took two visits to two lists. You wrote the automation in one, then remembered that an automation alone never runs, went to the trigger list, made a trigger, and pointed it back at what you had just made. A first time user who stopped after the first step got a thing that looked finished and did nothing. Lifecycles are now picked on the automation form, as chips. Saving reconciles the triggers behind it, diffed against a snapshot taken when the form opened so a save never removes a trigger the user could not see. Every lifecycle is in one place, including the two that fire continuously, which say so before you pick them rather than after your log fills up. That leaves the trigger list as what it actually is: a place to rename a generated trigger, or to point several differently named ones at the same automation. It says so, and it names the triggers whose automation is gone. New opens one list of starting points: an empty automation, then a handful of recipes for the software people actually pair Ontime with. A recipe is nothing but a pre-filled form, so choosing one opens the ordinary automation form with its values in place. The user reads what it will do, points it at their own gear and saves. Nothing is written until they do, and there is no second creation path to keep working: one request, the same as any other automation. Every recipe targets loopback, so one saved without thinking cannot put traffic on a venue network. The list now answers what an automation does without opening it: when it runs, whether it filters, and what it sends. An automation with no trigger or no output is the common half-finished state and is called out rather than shown as a blank cell. Outputs are cards with their type, a summary and a Test button in the header, which is also where the test says whether it worked: the panel used to send and tell the user nothing either way. Deleting confirms first and names the triggers that go with it, instead of dumping the server's refusal into a stray row under the table. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AfDKsy6PE3Rbyt32Fg4YKf