Update issue without throwing events

Forge Forge Modules and Product Triggers
, , ,
1

Hi there,

I am editing an issue via API, but looking for a way to NOT trigger Jira events (e.g. in Forge).

There are some flag (like notifyUsers), but they don’t seem to help here. In Java there was something like EventDispatchOption#DO_NOT_DISPATCH (ref) which I was looking for in Cloud.

I assume this isn’t implemented or maybe not even planned. But in case is anyone able to find an Atlassian issue to watch? If not, where should I put it?

Cheers,
paul

1 Like
2

Hello @ppasler

looking for a way to NOT trigger Jira events

I personally would be appalled if Atlassian provided a mechanism for Forge, the REST APIs or any other environment that facilitated the ability to silently (read as ‘secretly’ or ‘subversively’ or even ‘maliciously’) change an issue without there being an event.

Such an ability would be a security auditor’s worst nightmare!

is anyone able to find an Atlassian issue to watch? If not, where should I put it?

Feel free to browse and search JAC or Ecosystem yourself, and create the feature request yourself if you find no match.

1 Like
3

I completely understand your concerns and would just like to request a way to prevent update events. The changes should still be logged and reflected in the history as usual.

4

Sometimes as developers we wish for a ‘special way’ to exist that solves a particular problem we have, but we forget about the subsequent consequences; it’s the proverbial “Don’t wish too hard for what you want, or you just might get it”.

Imagine the following scenario:

  1. An important Government department, which uses Jira to plan and track sensitive internal projects, has concerns about the actions of a user, so they enable Audit Logging feature to collect the events related to their actions, as they happen
  2. The user is aware they may be monitored, so they use the ‘magic’ REST API method that allows their actions to not throw events, only be logged
  3. The person responsible for monitoring the user’s actions via the Audit Logging feature sees nothing unusual happening and reports this to management
  4. The user in question is allowed to stay in their role and continue their work activities without further suspicion
  5. Two weeks later, the user leaves the department, then leaves the country
  6. Seven months later, it is discovered that during the user’s employment, they committed a wide breach of security and information destruction, so an audit is conducted
  7. Reviewing the Jira Audit Logs from the period is useless, as they are only retained for 180 days. A review of a copy of the Audit Logs made during the period is also useless, as it only shows nothing unusual
  8. An attempt to review the history of the Issues is useless, as the user deleted them to cover their tracks
  9. Pulling down the ‘lower level’ logs is useless, as they too are only retained for 180 days (this is Cloud remember, not Data Center)
  10. It’s too late to prevent the user’s actions now and they can take no legal action against the user, as they’ve left the country
  11. They conduct a post mortem of the whole incident to determine what must be done to prevent this happening again…

In this scenario, as a Security Advisor, what is your recommendation to this Government department about the change they can make to prevent it happening again? What recommendation would your give about Atlassian’s Cloud product?

Anyhow, food for thought :thinking:

5

https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-issue-custom-field-values--apps-/#api-group-issue-custom-field-values--apps-
here there’s a generateChangeLog flag that helped me with an app customfield migration… maybe it might help you as well

6

Hello @PaoloMariottiACE

But doesn’t the generateChangeLog parameter only apply when changing the value of a custom field? How would that meet the OP’s requirement of changing an Issue?

And what would not writing to the change log have to do with the OP’s requirement of not triggering events? You seem to be inferring that writing to the change log is the same thing as triggering an event.

7

Well, when migrating app customfields, you need to write the data to the issue and you don’t want the original user to receive an email.
Actually there’s no real changing values in the issue, just copying the value that was on the source instance.
we don’t really know why @ppasler wants to change an issue… and he’s a marketplace partner… so it might be a migration need… the api linked has an example exactly to change a customfield value…
with that API and generateChangeLog true the user doesn’t receive emails.
it is simple as that

8

But what does a user not receiving emails have to do with the OP’s requirements?? The OP doesn’t want an event to be triggered.

sending an email != sending an event

You seem to be providing a solution to a problem the OP doesn’t have.

9

@PaoloMariottiACE sunnyape is right, it’s not about sending mails. Not sending mails is already possible with the API via flag (notifyUsers: false).

1 Like
10

@ppasler generateChangeLog != send email. emails are just a side effect. changelog is a collection of events… so it might have been useful. if it’s not, i just tried to help.
I didn’t like to be bitten by sunnyape while just trying to share maybe useful knowledge.

1 Like