We created an automation script to execute 14 days after a ticket closes to prevent users from adding time spent to a ticket. I found the property key and value that I needed. I know it worked because I applied it to the workflow to execute at the time the ticket closed but now we wanted to apply the property key 14 days after close.
Can you use property key and value in automation? If so, is there some format that I should be using?
Property key = jira.permission.work.denied Value = Denied
Property key = issue.fields.worklog Value = false
I have gotten the project, user, and issue level entity properties to work from automation rules, but I have not tried a Jira instance level one before. For example:
Without the context of an entity like project or issue, you may need to call the REST API from the rule if you need to update such a property.
Also note: I do not believe property names which contain a period can be accessed from a smart value. They can only be accessed via an add-on tool or the REST API.
Thanks for that information, Lauren. You can use the entity properties from a project-scope rule, as I noted above.
Have you tried it this way yet? And if it does not work, would you please post an image of your rule and the audit log? That may help provide some context for the community to offer suggestions. Thanks!
@Bill Sheboy Hi I work with Lauren (above).
Our business need is to prevent time from being logged (work from being logged) on issues which have been closed for at least 14 days.
We set up the following automation to filter issues in a specific project which have been resolved for at least 49 days, then apply the following issue property, which we believe should prevent work from being logged on the tickets. The API even returns the proper property key/value (at least what looks proper) on the issues after the rule is run against them. We are currently applying the following keys and values in the automation rule (because we're trying everything we can)
jira.permission.work.denied = denied
issue.fields.worklog = false
The problem is that despite the key/value being applied on the issue level for the desired issues, it is still possible to log work on them.
AUDIT LOG for last run:
Result when viewing the issue directly from the API
Drill down example of proper key value:
I'm at a loss (if these keys are supposed to prevent work from being logged) as to why work can still be logged to the issues the automation runs for.
based on previous knowledge the property "jira.permission.work.denied" can only be set in the environment of workflows - not directly on an issue, but please correct me if you have seen this feature somewhere.
In case it is only for use within a workflow it won't help you - this is more an on/off switch. Either the issue is editable or the opposite. I have not seen an option to declare it should be not editable after 14 days.
Happy for any update you can share.
@Daniel Ebers we are applying properties to individual issues using an automation as explained on this thread: https://community.atlassian.com/t5/Jira-questions/Re-Re-Can-you-use-property-keys-and-values-with-Automat/qaq-p/1711400/comment-id/485728#M485728
Greetings! To avoid multiple conversations on the same thread, I am picking up from where Daniel started...
Apologies as I should have researched further on that setting before answering. Following this guidance linked below and what Daniel stated:
That property to prevent logging is added to workflow to prevent logging for a transition. It does not appear to be intended to work when attached to a specific issue.
A work-around could be... Add another status and put the restriction on the transition into that status. Then create an automation rule which after <X> days, moves issues from one "done" status to another one: the restricted time logging one.
Hi @Bill Sheboy - I believe I understand now. Since the problem we are trying to solve involves team members finding closed tickets and logging work against them, a key which only prevents logging during a transition doesn't seem like it will fulfill our requirement.
I guess there is no way to prevent work from being logged to a ticket, outside of preventing work logging during a workflow transition.
Actually you can prevent work being logged when an issue is in a specific workflow step.
What I initially meant to say is that
Adding to that, I believe, there is some general confusion - which is very relatable because these powerful option are sometimes hard to understand.
The relevant documentation is in:
And from there, confusingly you have two "paths"
Please check if this would be suited to your requirement and let us know what you have found out.
Do you think this is viable to "lock and issue after 14 days of closing" (prevent time from being logged)
Add a status called "Locked" and apply the jira.permission.work.denied status to it in the workflow.
Create an automation that will move a ticket from Closed -> Locked 14 days after it was closed?
If I understand you right you will move the issue after a time period (let's say after 14 days) to a state called 'locked'. The trick is that this workflow step will get the jira.permission.work.denied setting by you so nobody can log time again it.
Yes, this should work - this is basically that what Bill suggested above (Jun 01, 2021).
In case using Automation is fine and probably needing to have a "new" status of Locked in the configuration it is absolutely fine - you could test, it should work.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event