Official REST api to manage rules


We should offer an API to manage rules:

  • CRUD

  • Disable/Enable

  • Trigger

  • Maybe also bulk.




John McKiernan
June 10, 2020, 3:52 AM

Excellent improvements to this process shared by a customer who has migrated from server to cloud:

  1. After uploading a JSON file, one is required to manually select all rules one wish to import; There is no “Select all” option. While this is a minor inconvenience when importing 66 rules, it would be nice to see an option to simply select all.

  2. When clicking “Let’s do this” on the next screen, the only visual cue that one gets, is that the button is disabled. At this point I did not know what was happening; Was the system processing the rule insertions or was it already done? After waiting for 20-25 seconds the browser navigated to the overview page and the rule insertion had been processed. It would be nice to have a visual cue of what was happening; an overlay and a modal saying that it’s processing along with a spinner here would make for better UX in my opinion.

  3. After the rule insertion has been processed and you are redirected to the overview page, every single rule that was just imported is disabled by default; while I’m sure there’s good reasoning behind this, it leads to another tedious process of manually clicking (see my first point). It would be nice to see an option like “Enable all rules after import” or “Enable selected rules” checkbox/multiselect on the last page where you click the “Let’s do this” button.


The process of manually creating the import JSON file could also be improved upon in my opinion; while I know that this is not something that users will have to do on a regular basis, there is something that I would like to share:

  1. ID’s are required to be filled out. You can not leave these as “null” values in the JSON. This means that the process got a bit more complicated:

    1. Identify the biggest number of rule ID; this is tedious as you can not sort the rule list by date of creation. If you have a lot of rules, the manual task of doing this would be immense. A workaround is to create a new rule before you begin, as a dummy rule to get the ID from. Also the ID is only (to my knowledge) available when you export the existing rules. It could be added as a read-only parameter when checking rule details.

    2. Identify the biggest number in the triggers OR components section of the data; these seem to share ID sequences for some reason, not sure if this is intended or not. This is much the same process as above, with the same hurdles to overcome.

    3. For each new rule, add 1 to the current rule ID (starting out being what you found in point (a)) and store it globally for the next rule if any.

    4. For the trigger of each new rule, add 1 to the current trigger/component ID (starting out being what you found in point (b)) and store it globally for the next trigger/component if any.

    5. For each component of the new rule, add 1 to the current trigger/component ID (starting out being the globally stored trigger/component ID) and update the global ID.


The system should already be aware of these counters; hence allowing “null” values should be permitted and they should be automatically filled out if not explicitly set.


While it did not take me a long time to create a Node script that generated a suitable JSON file, I believe it stands to reason that not everyone using Jira is a developer, or have developers on hand, at least when migrating from on-prem to cloud. The above should be fixed or another way of importing rules should be added that handles this.


Implementing the above would also open up for way more API possibilities in the future.

Your pinned fields
Click on the next to a field label to start pinning.




Nick Menere (CB)