I have a Behavior in scriptrunner where if a custom field was unchecked, then another custom field gets cleared.
But when I uncheck the custom field on the Structure, it still shows the other custom field as filled out and not cleared. Only when I go on the issue view and make the edits, it works properly, but it still doesn't reflect in structure unless I hit refresh.
How can I get Structure to sync properly so that I can update manually any issue and it runs the behaviors I had set?
Hello @Diana Gorv ,
David from ALM Works here.
The scenario you describe sound similar to the one discussed in this thread. It contains some steps that may help in addition to the recap below.
Structure relies on Jira's EventManager updates to refresh data.
Please check if the updates you expect to see in Structure are being displayed in the Issue's History Tab.
You should be able to see a "made changes" entry if you open the Issue and look at the History tab under the Activity section of the page.
If there's no update on the Issue History, our suggestion is to change the script to use either one of these options:
If you do see the events in the issue history, it may be best to work directly with our support team. You can initiate a ticket by emailing support@almworks.com or through our portal support.almworks.com.
Best,
David
Hi @David Niro thank you for the quick response back.
I checked the issue's History Tab and I was able to see my activity captured the changes perfectly. The script works fine on the issue view level, and when I edit on the issue, it reflects on the Structure after a few seconds.
But only when I try manually editing on the Structure, the script doesn't seem to run. And when I check the issue's history tab after a manual edit on Structure, I saw that the custom field I unchecked was captured, but it didn't clear the other custom field and the history tab showed no activity.
I did research about a Structure Dark Feature ability that can force a structure to reindex whenever there's a change, but I rather not go that route if it means a possibility of messing up our entire instance. For now, it's not so much a major hinderance on our process, but rather a minor annoyance. We've been doing a workaround by either bulk editing or opening a new window tab and edit on the issue view.
But it would be nice if there was a possible fix. I'll send an email ticket.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @Diana Gorv
You are very welcome! Thank you for the additional details!!!
To recap:
When updating your field on the Jira issue details view:
When updating your field from Structure:
I just want to be 100% sure I have the scenario correct. If so, you are on the right path with the dark feature for indexing. The second of the two options is less heavy though I still understand the hesitancy.
Best,
David
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, everything was correct except when updating my field from Structure:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for clarifying that for me! If the event is being recorded in the issue history when changing the field in Structure, I would expect the corresponding action to take place.
In other words, I think something else is going on here.
Would you mind creating a support ticket via email support@almworks.com or through our customer portal support.almworks.com?
We will want to review the logs and discuss the script being used.
Best,
David
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @David Niro
I emailed the support team a ticket. I reference back to this question for them to review. But I'll share the code I used here for future reference:
Code below used in Behaviors for field Custom A server-side script. No conditions added. Switches set to Optional, Writable, and Shown:
import com.onresolve.jira.groovy.user.FormField
def customA = getFieldByName(“Custom Field A”)
def customB = getFieldbyName(“Custom Field B”)
def customAValue = customA.getValue()
if (customA.getValue() == “Yes”){
customB.setHidden(false)
customB.setRequired(false)
}else {
customB.setHidden(true)
customB.setRequired(false)
customB.setFormValue(null)
}
Thanks!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @Diana Gorv ,
Thank you for creating the support ticket and for the details on the script you are using.
I was looking into next steps and researching Behaviours a bit more and found the following information on the Adaptavist knowledge base:
Screens
Behaviours function on the Create Issue, Update/Edit Issue, Assign Issue, and Workflow Transition screens.
On the View Issue screen, trying to edit a field with a behaviour will launch the edit issue screen, instead of the normal inline editor.
Behaviours will not work on the Move Issue screen. They also do not work for any bulk issue operations or any issue edits that bypass the UI such as the REST API and other ScriptRunner scripts.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Hi @David Niro
This makes a lot of sense! I was wondering if Listeners was the solution and not Behaviors. I will give this a try. I truly appreciate your help!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Diana Gorv you are very welcome!!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi, @Diana Gorv. Welcome to the community! That sounds strange, indeed.
I'll share your post with some people I know who are much smarter than me about such things. Stay tuned.
-dave
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.