No, you can't have a calculated and editable field, it's a nonsense - either you want to calculate it, or you want the user to enter it, one option will always destroy the other.
I can see a use for two separate fields tied together. A calculated one that displays something, and then an editable one that, at some point in your workflow, is pre-populated from the same calculation the calculated field uses, and then allows the user to edit it. A bit of scripting should do that.
Hi Nic, I agree with you on that is seems not to have sense but, I need to calculate the initial value of a customfield. I've thought in the solution proposed by you in the second parragraf but the problem is.....How can I do in the creation issue to propose an initial value to the users? I have no idea about copying the calculated value into the other editable customfield.....
Yes Nic, I need to create issues with at least 2 customfields: a) A customfield named "Software Element". b) A customfield named "Internal Code" that must meet the following format: Software_Element_value.XXX where XXX are digits c) For the first issue related with an specific "Software Element", I need to propose for "Internal Code" customfield the initial value Software_Element_value.001 Example: PISCIS.001 d) The user must be able to modify this internal code but meeting the right input format. For example: PISCIS.025 is ok e) For the second, thirdh and more issues created and related with the same specific "Software Element", I need to propose for the "Internal Code" customfield the next initial value: Software_Element_value.max(XXX) For example: PISCIS.026 f) Again the user can act the same as in point d) I know this can sound crazy, but I need to reproduce exactly this management of internal codes using JIRA (or at least I need to try it).
Right, that's pretty complex, and it's going to be very hard to kludge into Jira using scripts. This is the sort of thing where I'd be reaching for proper plugin development, unless you're willing to change the approach a bit. To avoid coding, I would - Create "software element" as a single select list - Create a number field for "element" - Create a scripted field for "suggested element" which will display above the "element" field on the create screen - the script will need to execute some search for the highest value of "element" Now, when the user clicks "create", I would - Have a validator check the number they have entered - In a post-function, if they have left the element field empty, do the same calculation the "suggested element" field has done and put that in element automatically. Finally, - do not put the "element" field on the view screen - have a second scripted field that concatenates "software element" with "element" and displays that where required
Ok, I like this solution but, one more doubt: I've tried to use SIL Customfield for showing the propose value but this kind of customfield isn't shown in the Creation and Edition screens. Which type of customfield need I to use? Is Scripted customfield type suitable for doing that? I mean, it's shown in the creation screen? Thanks a lot Begoña
Ack, rats. I've made a mistake - I thought the scripted fields could come out on "enter data" type screens, but they don't, they only work on "show data" type screens. I can't think of a way to do any of this without some coding. It is possible to put display-only fields on to a show-data screen. I know I've done it - you need to define a template for show and another for update in the plugin and I've used a template that simply doesn't have any input on it, just a data display. But you'll notice I said "plugin" there - because I had to do it in code.
My last test..... without success..... I've created a Scripted Customfield with the next groovy code: import com.atlassian.jira.component.ComponentAccessor; import com.atlassian.jira.issue.CustomFieldManager; import com.atlassian.jira.issue.fields.CustomField import com.atlassian.jira.issue.Issue; import com.atlassian.jira.issue.IssueManager // MANAGERS CustomFieldManager customFieldManager = ComponentAccessor.getCustomFieldManager(); IssueManager issueManager = componentManager.getIssueManager() Issue mIssue = issue INTERNAL_CODE = "Internal Code" CustomField customField_internal_code = customFieldManager.getCustomFieldObjectByName(INTERNAL_CODE) def text="PISCIS.CFG.001.000" mIssue.setCustomFieldValue(customField_internal_code, text); return text
Because Scripted Fields and SIL fields aren't shown in Create/Edit screens, finally I've used: Database Information customfield to propose the new Internal Code + Behaviour to make this field readonly + An editable customfield that allows the users to input the final Internal Code Thanks a lot!! Begoña
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Every time you release software, there's a bit of risk – that there's a bug, that something breaks, or that the feature doesn't resonate with customers. Feature flagging helps make high stakes s...
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
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs