Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Can you use property keys and values with Automation?

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

2 answers

Hi @Lauren Pennisi 

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: 

{{project.properties."measure-AgeOfWip"}}

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.

Best regards,

Bill

@Bill Sheboy  I want to use my automation rule in one Jira project not my Jira instance. My apologies for not making that clear.

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!

Like Lauren Pennisi likes this

@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. 


2021-06-01 15_20_33-Project automation - JIRA.png

AUDIT LOG for last run: 2021-06-01 15_24_00-Project automation - JIRA.png

Result when viewing the issue directly from the API

2021-06-01 15_28_18-https___icg360.atlassian.net_rest_api_3_issue_INIT-846_properties.png
Drill down example of proper key value:

2021-06-01 15_31_13-DEV-INT EKS Subnet Migration - Message (HTML).png

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.

0 votes
Daniel Ebers Community Leader May 16, 2021

Hi @Lauren Pennisi

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.

Regards,
Daniel

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:

https://support.atlassian.com/jira-cloud-administration/docs/use-workflow-properties/

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.

Best regards,

Bill

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. 

Daniel Ebers Community Leader Jun 06, 2021

Actually you can prevent work being logged when an issue is in a specific workflow step.
What I initially meant to say is that

  • there is no option to make it non-editable after 14 days
  • the implementation is not done via issue property keys (I am still not aware of any way to do so)

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"

  • restrictions that apply to transitions (workflow transition properties) - not what you want, but...
  • restrictions that apply whenever an issue is in a specific state (workflow step properties) - this is what you are looking for:
    jira.permission.work.denied

Please check if this would be suited to your requirement and let us know what you have found out.

@Daniel Ebers 

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?

Daniel Ebers Community Leader Jun 11, 2021

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.

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

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

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you