Tempo Account field values with Script Runner?

Would anyone know how I can get the actual value of Tempo plugin's "Account" custom field and not just the index with script runner?

issue.getCustomFieldValue(Account) returns the index and not the value.

Meaning, if I have 3 entries(Bilka, Føtex, Meny) and the value is set to Føtex the above call returns 2.

4 answers

There is some info on tempo here: https://scriptrunner.adaptavist.com/latest/jira/working-with-tempo.html - but I don't think it's what you want. I think you will need to get the possible values for that field and associate it. I think you can reorder the values though, so it's probably not an index (and indexes are normally zero-based). Hopefully someone from Tempo can point to the right manager/service/class.

Unfortunately this method only returns the selected Account id.  We are working on improvements that include  returning the Account object for this method, which will allow you to get to the information you are looking for.  We are hoping to release this improvement in Q1/Q2.

In the meantime, if you are able to use our REST API's in your context, you can retrieve the Account name, or other attributes of the Account, using the Tempo Account API.  Please find information about how to use the Account API here.


Hlynur Johnsen

Product Owner - Tempo Books

Hi @Hlynur Johnsen,

Thanks for the reply smile 

I guess I will need to get all accounts and find the on with the matching ID I get back from the getCustomFieldValue() call. Not super efficient but doable I guess. Would be really great if the API had a get Account by Issue ID which would return the selected account. But maybe that comes?

Hi @Timothy Harris,

Like I mentioned in my comment, we will be changing the return type of the getCustomFieldValue() method to Account, which means that you will have all the information for that account at hand, including the name.  Is that something that will help with your use case?

Regarding your suggestion for getting Account by Issue ID, are you referring to the JIRA Issue API, or the Tempo Account API?  We have no control over the JIRA API, other than what I have described above regarding the return type.  

If you are able to use the Tempo Account (REST) API, you have the option to get the Account by Account ID (which getCustomFieldValue() currently returns).  Technically, we can add a new call to the Account (REST) API, which returns the Account being used by an Issue (Account by Issue ID).  If you are interested in this I suggest that you create an Improvement request in our JIRA instance  Just create a new issue, select Accounts(JTMAC) in the Project field and Improvement in the Issue Type field.  You then need to supply a summary and a description - the more info the better wink - and we will evaluate the request when planning our roadmap.

Hope this helps,



Hlynur... what is the internal tempo class that would allow us to get the string or object value from the ID? We don't need to use solely the REST API.

The REST API uses the AccountService and the getAccountById function to get the Account object.

@Hlynur Johnsen: You mentioned this:

We are working on improvements that include  returning the Account object for this method, which will allow you to get to the information you are looking for.  We are hoping to release this improvement in Q1/Q2.

Do you know what version this will be released in and when it will be released? My customer would wait for this if it is not too far in the future?


@Jamie Echlin (Adaptavist): Hi Jamie, I was going to start on a task which was the initial driver for this question. Would you mind perusing the use case below and letting me know what your thoughts are?

Hi @Timothy Harris, 

Sorry about the late response.  We will be releasing this in our next Tempo Timesheets version, which is scheduled for release in May or early June, so it should be right around the corner.



is there any new information to this?

How am i able to set an Value to the Account Field by using scriptrunner?

Is there a way to "SET" the value starting from the ACCOUNT KEY and not ID

@Jamie Echlin (Adaptavist): I have a use case where I would like to ask if this is feasible and maintainable to do with Behaviours. 

Two single select list custom fields. 

Field one: Chain
Field two: Account

The values are dependent upon the selection of the other field. So depending on the selection of "Chain" I need to filter what is visible in "Account" select list. And vice versa, depending on the selection of "Account" I need to set the value of "Chain". There is a one to many relationship from "Chain" to "Account" but a one to one from "Account" to "Chain".

The values of the two fields need to be initialized from other fields. My thought was the following. 

Create a behaviour and add these two fields. 

* initializer Function: Server side groovy script which will read the needed data from two other fields and set the initial values of the two select lists "Chain" and "Account" from the values of two other fields.
* Chain Field: Server side groovy script, which will set the available values(plural) of "Account" select list when "Chain" value is selected.
* Account Field: Server side groovy script, which will set the value of "Chain" select list.

Is this feasible? 
Do you foresee any issues with this approach?

It should be feasible, but after you've chosen the Account field the Chain will effectively be locked as there will only be one option in it. 

I am not sure this is related to the original question, so would be better to post a new one rather than answering a question with a question.

I'll delete your post on disqus if you don't mind. Cross-posting hugely increases our workload.

Sure, go ahead. Didn't mean to increase your work load cheeky

When you say effectively locked, what exactly do you mean? All I really want to do here is to manage the values of the select lists dynamically based on the selection of the other one.

So user goes in and finds some value from "Account" and sets the value. The value of Chain will then be set. He should be able to re open the issue and edit either the "Chain" or the "Account" fields.  Will this not be possible?

Or do you mean that once "Account" is set then we will set chain and he will not be able to change it until he re-opens the issue...

You said one is 1-many and one is 1-1. So if you update both ways, you will be in a situation when one field only has a single option. I think you will be better off if you just update the options for Account field. If the account field changes you can set the Chain, but I would not set the available options.

I get what you mean smile

I think you are right also. No options update on Chain just set the selected option. The options on Account will always be all available or just a subset based on chain. My biggest worry with this is the timing/performance of it. I have to get the Account values through tempo's REST interface.

Thanks for the feedback!

Hi All,


Did anyone updated the Tempo Account field through Behaviour or Post Function Workflow.

Kindly suggest the solution. I tried my best but so far I didnt get any solution.




Like 1 person likes this

Any update on the account field / account object?  

Like 1 person likes this

Something new guys? 

Need this option too

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Oct 09, 2018 in Jira Core

How to manage many similar workflows?

I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...

388 views 6 0
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you