- Posted on
Wed Nov 30, 2022 6:57 am
-
ab39870
offline
-
- Posts: 40
- Joined: Dec 09, 2015
Thank you DaveL17 and whmoorejr.
I (re)reviewed the Trigger API and also realized I need to clarify what I was intending to do. I also think I know the best path forward for my scenario which your posts helped me think about.
I am depreciating a particular Plugin Event. Another Plugin Event has been updated that can perform the same function and some additional functions too. From the API documentation and my own testing, when a Plugin Trigger is created, the Plugin Event associated with the trigger is stored in the property "pluginTypeId". That property does not appear to be editable - it is read-only. And while I can look for all triggers that have pluginTypeId = "theEventToBeDeprecated" and then create a new Plugin Trigger with the pluginTypeId of "theEventThatReplacesIt"; it does not appear the Indigo API allows me to access any of the conditions or actions associated with the Trigger to create. Thus, I don't see any automated way to change all Plugin Triggers of pluginTypeId = "theEventToBeDeprecated" to pluginTypeId of "theEventThatReplacesIt" such that no changes are required by the user. Not ideal, but its a corner case and I don't expect the API to handle every case.
So my current planned path forward is:
1. I believe I can modify the pluginProps in Events.xml and convert these as needed for each applicable Plugin Trigger on startup() such that converting from one Event to the other is seamless - all values will "carry over".
2. Release the next version with both Events (both Events exist in the current version too) and disable the ability to change the to-be-deprecated Event settings by making all fields readonly in the Events.xml for the to-be-deprecated Event.
3. Use my Release Notes and the startup() and the triggerStartProcessing methods to WARN the user that these type of Events will be deprecated in a future release, can not longer be modified, and the Trigger needs to be changed from the current to-be-deprecated Event to the other type of Event by simply editing the Trigger, changing the Event type, and re-saving the Trigger. From testing, this appears to work fine and retains all the Conditions and Actions of the Trigger with the new Event type.