I need a way to "block" editing and deleting worklogs on a worklog id basis

[Richard Vencu]

I send my work logs to a third-party system. While they can be edited until a specific event takes place on the backend system, I need a way to block further editing or deleting from Jira after the blocking event.

One way I deduce from the REST API interface is that I can use visibility to let only the admins see the work logs after the event. But it is a bit too harsh for the users, I am curious for other less intrusive ideas.

[Richard Vencu]

If blocking is impossible, then I need a way to undo the edit or delete action via automation if possible.

[Daniel Ebers]

Hi @Richard Vencu

I found information on how to implement this, but I would like you to check if it works, documentation is a bit unclear in this regards.

The whole idea is based on:

• How to restrict Log Work on a specific status
  https://confluence.atlassian.com/jirakb/how-to-restrict-log-work-on-a-specific-status-834225982.html

Don't worry it reads "Server" as I found a bug relating to "Cloud" - but this is meanwhile closed and by changing your workflow I see good chances that it will work for you:

https://jira.atlassian.com/browse/JRACLOUD-67154

The important part is (citing Dave from the linked bug):

We are able to consistently confirm that the property is working.
The syntax we have used is:

jira.permission.work = denied

where jira.permission.work is the property key and denied is the value. You may need to republish your workflow to verify that this is working.

In case you want to test please do let us know what you found out.

Regards,
Daniel

[Richard Vencu]

Thanks. I knew about that, however on the same issue, I might have a mix of work logs, some of them I need to block while others are still open.

I cannot use properties at the issue level (such as ones for the status), nor at user level. I need properties at work log level, individually.

So the visibility property appears to be the sole solution while it will also inadvertently hide the logs from the users... something that I would like to avoid.