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.
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.
Product Owner - Tempo Books
Hi @Hlynur Johnsen,
Thanks for the reply
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 - and we will evaluate the request when planning our roadmap.
Hope this helps,
@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): 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
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?
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
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!
If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot