-
Bug
-
Resolution: Fixed
-
High
-
9.0.1
-
None
-
Severity 2 - Major
Issue Summary
This is reproducible on Data Center: (yes)
Webhook URLS for Chat Integrations like slack are converted to the new Automation Secrets. The generated secrets have generic Key names and the key values are hidden from the Jira UI, making future administration of these webhooks unusable. It also makes creating new webhooks very difficult for customers.
Steps to Reproduce
- Create any Jira with A4J on a version prior to 9.0.1. I used the Jira 9.4 DC Latest LTS templated from Instant Environments to test.
- Navigate to Jira automation and create a new rule
- Select Manual trigger
- Select Send Slack Message for the action.
- Input a webhook URL e.g http://127.0.0.1/test
- repeat the above until you have enough rules for your testing
- Perform the upgrade to A4J 9.0.1 via the manage apps screen.
- Now when you create a new webhook in version 9.0.1, the webhook URL is replaced with a dropdown that will look similar to the customer's screenshot above.
Expected Results
Webhooks remain identifiable and usable for future admin tasks.
Actual Results
Webhooks are converted to a secret and the drop down list becomes unusable for future admin tasks.
Secrets are also read only in the UI which makes it impossible to change them, they must be recreated and added to the rules again.
Workaround
Currently there is no known workaround for this behavior. A workaround will be added here when available.
- is related to
-
JIRAAUTOSERVER-844 Automation rules cannot be enabled, disabled or published after an upgrade of Automation for Jira to 9.0.1 or a higher version
-
- Closed
-
- relates to
-
JIRAAUTOSERVER-335 Add support for secret storage
- Closed
- mentioned in
-
Page Failed to load
-
Page Failed to load
-
Page Failed to load
-
Page Loading...
-
Page Loading...
This really wasn't a solution, now I have every single secret key set to global, when in reality, none of ours are global, furthermore, because every secret key name is the webhook url, it's almost impossible to identify which key belongs to which project without joining several tables in the database and manually editing every secret key from the front end, so that keys that should be at project level, such as o365 connector webhooks used in MS teams, aren't used by the wrong team in the wrong project, to send to the entirely wrong Teams channel.
Because of this implementation we are going to have to carry out quite a lot of manual work over several hours to try and match up webhook url values, to entries in the DB, limit the key to the right project and just live with the fact we can't rename the webhook name from the front end as its greyed out.