Trying to update the project description within project automation doesn't seem to work

[Mohamed Zouaghi]

I set up a project automation to update the project description when certain conditions are met.

Choosing "Project" as entity type, "description" as property key with a static value: "You name it" doesn't seem to update project description as expected.

Note: I'm trying to update the project of the issue which triggered the automation and I'm triggering the automation manually from the issue. 

[Andy Heinzer · Accepted solution]

Hi Mohamed,

I can see that you're wanting to be able to change the project description using automation.  This is not possible to do in the current versions.

The use of the project entities here is not intended to be able to change this either.  I'd recommend checking out Entity properties (Jira Cloud) and/or Entity properties (Jira Server) for more details about what these are used for.  In short entities allow you to create your own data in the form of key/values and store this meta data within Jira.  This is particularly useful for add-ons or apps for Jira as a means for them to store data on different entities, but these are not intended to be displayed to end users.  As such, the project entities are not able to control the actual project description.

To the best of my knowledge automation in Jira has never been able to make changes to the project settings.  Instead the focus are has been primarily upon the issues themselves.  I also have not found any existing feature requests for this functionality just yet.  The closest I have come has been this one AUT-805 - Set project scope to a specific project type and or category.  This is not exactly the same as what you are seeking, but it does deal with the same level of project specific settings.    

Perhaps we could create a feature request for this.  I would be interested to make sure we have captured the desired functionality here.  Could you let me know more about why this would be useful to you?  Or what use case this feature would help to solve?

Thanks

Andy

[Mohamed Zouaghi]

Hi Andy,

Thx for your reply.

Let explain what I was trying to achieve:

- We are an IT service provider with 40+ customers. We are selling "Development Hours Pack" to our customer as part of their Support contract with us. This pack allows them to raise change requests (aka feature request) and to have them implemented through the consumption of hours from the "Dev Hours Pack". Here is how I see it (functionally speaking).

- I'm customer XY and I have a "Dev Hours Pack" of 50 hours. I raise a CR to develop something new. The ticket gets resolved and the needed work consumed 6 hours. There should be an automated comment added to the ticket saying. Your new hours balance is: 44 Hours.

And here is how I'm trying to solve it:

- I need a central field accessible by all tickets (of a specific project) to "host" the current hours balance.

- I create a new rule which checks for certain conditions then use the "Common field" and discount it by "TimeTracking.TimeSpent" then add a comment to inform about the new current balance.

The only solution for me was to use one of the project fields to host "Hours balance" so that all issues (of that project) access it (read/write).

Ideas about how to solve this?

[Andy Heinzer]

Hi Mohamed,

Thanks for the extra details here.  That makes much more sense now.  Jira Service Desk Cloud doesn't have a good way for automation to lookup project level settings or project level entity properties natively right now. 

While the automation Jira has now does have a lot of useful features, taking a look at the smart values that are available for automation to read from, this only extends itself to issue.properties, and unfortunately does not extend to project level property keys.  It does look like automation can set project properties, but it doesn't look like it can read them.  Nor does it appear there are any project level fields we can use here.

Instead, I have been looking into a different approach here.  I think I might be on to something here.  Granted it's not going to be an ideal solution for everyone, but I'll try to explain. 

If you also have Jira Software, you can adjust this project to also include issue types such as Epics.  From there you can add all the issues from a single customer to that particular epic.  With all those issues in the same Epic, automation can make references back to that epic issue and all of its custom fields from the children issues.  I think this is going to be a better approach because I know automation has comparisons/conditions such as Issue fields condition to compare the value of a field on your issue against the epic and vice versa.  You can also then use some Smart values - math expressions to do the adjustments to the Epic (parent issue).

To make this work, I had to first edit he project settings, Issue types.  And add the Epic issue type.  Then you have to add the Epic Name to the screen when creating a new Epic, otherwise you can't create them.  You also need to add the Epic Link field to all the other screens in use by the other issue types in that project.  This lets you see and set which epic an issue belongs to.

With the epic create, and all those issues added to it, you can then add a custom field (I choose of type number), to all those issues.  Set the Epic number custom field to 50.  From there you can create an automation rule to first add issue from that customer to this Epic.  Then another rule to check the {{issue.Epic.numbercustomfield}} value.  This rule could compare it against the {{issue.numbercustomerfield}} or you could just compare to make sure the value is greater than 0.  You could make an action rule to adjust the value of that field in the epic.  The math expressions will be helpful at that point to figure out just by how much to subtract from the value.  At that point you could then make an action rule to make a comment and reference the current {{issue.Epic.numbercustomfield}} value.

Anyways, I think this approach has merit, but the drawback is that it requires you to have Jira Software and be a Jira Software licensed user.  Which can incur additional costs on Cloud for license seats.  That said I think this approach can work. 

Let me know if you have any questions or concerns about this approach.

Andy

[Mohamed Zouaghi]

This is what I call a 5 stars answer!!!

Actually I thought about this a couple of days ago but wasn't sure whether an Epic can be added to an SD project or not.

Following your recommendations I was able to implement the Support Hours Pack balance concept... And it works like a charm.Additionally, I'm able to implement end of life support contract based on End date field at the epic level. This is a great feature, since it automatically declines tickets for customers with expired contract!

For people who don't have Jira sw, I would recommend the use of webhook action to a Jenkins (then trigger script to update the ticket). This should do the trick.

Thx Andy!