Limit action customization to step functions and remove notion of "custom actions" (#591)

Ref #544 

* Add model for ActionParams

* Pass `ActionParams` directly to default action and step functions

* Create model for ActionSteps

Use step model to provide defaults

* Remove notion of custom actions

Now, we only allow customization through action steps

* Update documentation

* Remove required_jira_permissions property

Since all projects use the default action now, required Jira permissions
aren't unique per project

* Use `responses` for all Jira service tests

* Add ADR 2

* Remove `BugzillaWebhookAttachment` model

Author: grahamalama

config/config.prod.yaml

@@ -3,7 +3,6 @@
 - whiteboard_tag: addons
   bugzilla_user_id: tbd
   description: Addons whiteboard tag for AMO Team
-  # module: jbi.actions.default
   parameters:
     jira_project_key: WEBEXT
     labels_brackets: both

docs/actions.md

@@ -1,14 +1,13 @@
 # Action
-The system reads the actions configuration from a YAML file, one per environment. Each entry controls the synchronization between Bugzilla tickets and the Jira issues.
+The system reads the action configurations from a YAML file, one per environment. Each entry controls the synchronization between Bugzilla tickets and Jira issues.
 
 ## Configuration
 
-Below is a full example of an action configuration:
+Below is an example of an action configuration:
 ```yaml
 - whiteboard_tag: example
   bugzilla_user_id: 514230
   description: example configuration
-  module: jbi.actions.default
   parameters:
     jira_project_key: EXMPL
 ```
@@ -28,33 +27,19 @@ A bit more about the different fields...
     - bool [true, false]
     - default: true
     - If false, matching events will not be synchronized
-- `module` (optional)
-    - string
-    - default: [jbi.actions.default](jbi/actions/default.py)
-    - The specified Python module must be available in the `PYTHONPATH`
 - `parameters` (optional)
-    - dict
-    - default: {}
-    - The parameters will be validated to ensure the selected action accepts the specified values
+    - `ActionParams`
+    - The parameters passed to step functions when the action is run (see below)
 
 
 [View 'nonprod'  configurations here.](../config/config.nonprod.yaml)
 
 [View 'prod' configurations here.](../config/config.prod.yaml)
 
 
-## Available Actions
-
-### Default
-The `jbi.actions.default` action will take the list of steps to be executed when
-the Webhook is received from configuration.
-When none is specified, it will create or update the Jira issue, publish comments when
-assignee, status, or resolution are changed, or when a comment is posted on the Bugzilla ticket.
+### Parameters
 
-It will also set the Jira issue URL in the Bugzilla bug `see_also` field, and add a link
-to the Bugzilla ticket on the Jira issue.
-
-**Parameters**
+Parameters are used by `step` functions to control what Bugzilla data is synced with Jira issues. Possible parameters are:
 
 - `jira_project_key` (**mandatory**)
     - string
@@ -88,13 +73,12 @@ Minimal configuration:
       jira_project_key: EXMPL
 ```
 
-Full configuration, that will set assignee, change the Jira issue status and resolution.
+A configuration that will set an assignee and change the Jira issue status and resolution.
 
 ```yaml
 - whiteboard_tag: fidefe
   bugzilla_user_id: 514230
   description: full configuration
-  module: jbi.actions.default
   parameters:
     jira_project_key: FIDEFE
     steps:
@@ -159,6 +143,3 @@ linked Jira issue status to "Closed". If the bug changes to a status not listed
 - `sync_whiteboard_labels`
 - `maybe_update_components`: looks at the component that's set on the bug (if any) and any components added to the project configuration with the `jira_components` parameter (see above). If those components are available on the Jira side as well, they're added to the Jira issue
 
-### Custom Actions
-
-If you're looking for a unique capability for your team's data flow, you can add your own Python methods and functionality[...read more here.](../jbi/actions/README.md)

docs/adrs/002-action-customizaiton.md

@@ -0,0 +1,53 @@
+# Restrict Workflow Customization and Validate Default Action Parameters
+
+- Status: Accepted
+- Date: 2023-06-23
+
+Tracking issue: [#544](https://github.com/mozilla/jira-bugzilla-integration/issues/544)
+
+## Context and Problem Statement
+
+When JBI was first designed, we envisioned a scenario where a user might want to contribute a Python module to create an entirely custom sync workflow. As we've continued to make workflow customization easier, we've questioned whether this freedom of customization is worth the added complexity of supporting custom modules and action parameters.
+
+## Decision Drivers
+
+- Reduce complexity in handling custom modules
+- Prevent bugs due to misconfigured workflows
+- Align with the evolved designs that emphasize customization through combining steps
+
+## Considered Options
+
+- Option 1: Maintain the ability to customize workflows through custom modules and parameters
+- Option 2: Restrict customization to the default action and validate action parameters with a schema
+
+## Decision Outcome
+
+Considering the positive consequences of Option 2 and the fact that workflow customization is still possible through action steps, it is reasonable to choose Option 2 to simplify workflow customization and focus on improving the reliability and robustness of a single action.
+
+## Pros and Cons of the Options
+
+### Option 1: Maintain the ability to customize workflows through custom modules and parameters
+
+- Good, because it provides flexibility for users to create entirely custom action workflows
+- Bad, because it increases complexity in handling different parameter structures and custom module configurations
+
+### Option 2: Restrict customization to the default action and enforce parameters with a schema
+
+- Good, because it validates that configured parameters are useable by step functions
+- Good, because we can safely assume that action parameters are of a certain type
+- Good, because it aligns with the evolved designs that emphasize customization through action steps
+
+Option 2 also still provides plenty of freedom to customize an action workflow. One can
+simply supply one large function that contains all of the logic of that action, e.g.
+
+```yaml
+parameters:
+  jira_project_key: FIDEFE
+  steps:
+    new:
+      - my_giant_big_step
+    existing:
+      - my_giant_big_step
+```
+
+While this is perhaps less "elegant" than the module-based approached, it still provides an equivalent amount of customization.

docs/deployment.md

@@ -52,7 +52,6 @@ GET /whiteboard_tags/
         "bugzilla_user_id": 514230,
         "description": "Addons whiteboard tag for AMO Team",
         "enabled": true,
-        "module": "jbi.actions.default",
         "parameters": {
             "jira_project_key": "WEBEXT"
         }

jbi/actions/README.md

@@ -39,7 +39,7 @@ def traces_sampler(sampling_context: dict[str, Any]) -> float:
 
 app = FastAPI(
     title="Jira Bugzilla Integration (JBI)",
-    description="Platform providing default and customized synchronization for bugzilla bugs.",
+    description="Platform providing synchronization of Bugzilla bugs to Jira issues.",
     version=version_info["version"],
     debug=settings.app_debug,
 )