Dynamic Trigger Filtering

Forge Forge Modules and Product Triggers
, , ,
1

I started with a product-trigger app and easily build out the functionality that I need.
Here is the portion of my manifest file that is working to ensure this only runs for new created issues in 2 specific projects.

modules:
  trigger:
    - key: IssueCreationBot
      function: main
      events:
        - avi:jira:created:issue
      filter:
        ignoreSelf: false
        expression: ['ITTEAM','TSR'].includes(event.issue.fields?.project.key)

What I’m trying to do next is add a config page with a multiselect that allows the jira admin to assign projects to this trigger functionality.

I have the config page set up, pulling projects, filling out the default options of the multiselect as well. I’ve been able to store/pull these “assigned projects” in forge storage key-pair values.

Problem 1: I can’t find a way to reasonably pull forge storage values to be used in the manifest file.

I shifted gears to try to use environment variable to store and even for the multiselect default options saved as json strings in environment variable with working json parsing in the manifest file

modules:
  trigger:
    - key: IssueCreationBot
      function: main
      events:
        - avi:jira:created:issue
      filter:
        ignoreSelf: false
        expression: |
            try {
                return JSON.parse('[{"label":"TSR: Technology Support Requests","value":"TSR"},{"label":"ITTEAM: IT Support Requests","value":"ITTEAM"}]' || '[]').some(project => project.value == event.issue.fields?.project.key)
           } catch (e) {
               throw `Unexpected error: "${e.location}" - ${e.message}.`;
           }

The problem with this is that I can’t seem to persistently change the environment variable values with the config page logic. process.env.allowedprojects = will set the variable temporarily but it is not persistent. I think this is intentional.

I understand that I can use the storage and put a high level check in the app code to return early if the issue was not created in the correct project.

We have a lot of issues being generated in our jira cloud instance. I don’t quite understand the impact/efficiency of doing things this way and I’m still fairly amateur at JS/react, but filtering in the manifest feels “cleaner”.

Any help or insight would be appreciated.