You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
I recently tried to detect changes to the Linked Issues field, even if the listener is added:
Chrome's console log entry:
[SR Behaviours] field: issuelinks
The problem is that apparently the fields have different IDs to that one issuelinks-linktype and issuelinks-issues. Because of this, none of the changes trigger the Behaviour script.
Behaviour setup:
- Field enabled:
Linked Issues
- Conditions:
None
- Script:
// log a change in the field
log.error getFieldById(getFieldChanged())
As a result, no matter how many times I change the field, I get no entries in my log.
Is this a bug or am I using the field in the wrong way?
Buenas Pablo.
Could you kindly provide your code for your behaviour and or a screenshot of the configuration?
Cheers!
DYelamos
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This could also be related to https://productsupport.adaptavist.com/browse/SRJIRA-1316 if they are on an older version of SR.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Good evening Joshua,
I am running the latest version of SR and the bug still exists.
Can you please check?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Pablo,
I am not able to reproduce the bug. I just added a behaviour to the "Linked Issues" field, added a server-side script that has a logging statement, and started changing the Linked Issues field on the create screen. As expected, I get this in the logs:
2017-12-04 15:14:58,950 http-bio-8080-exec-11 DEBUG admin [jira.groovy.user.FieldBehaviours] Field changed
2017-12-04 15:15:06,745 http-bio-8080-exec-11 DEBUG admin [jira.groovy.user.FieldBehaviours] Field changed
2017-12-04 15:15:08,408 http-bio-8080-exec-11 DEBUG admin [jira.groovy.user.FieldBehaviours] Field changed
I am running ScriptRunner for Jira Server, version 5.2.3. Jira version 7.6.0.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I am running the same version (correction: Script Runner is using the latest version available in the marketplace 5.2.2) as well.
The only difference is that I added a new link type named includes/is included in.
Can you check with such a config please?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
In which way are you testing the behaviour? Unless you are linking an issue on the Create, Edit, or transition screen, the behaviour won't work because behaviours don't work on the View screen. If you are just looking at an issue and clicking the + button in the Linked Issues section to add an issue, the behaviour won't work.
It looks like in your screenshot you are doing it on the right screen, but I just want to check.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
From the create screen.
I am running Jira from in a Docker container from this image.
This is what I detected by playing with the browser console:
- It seems that posting runvalid method does not trigger for the field Linked Issues, whereas it does for any other (not binded correctly on startup?).
If I manually edit and send the POST request to the runvalidator.json endpoint, the change is captured by the serverside script and it generates a log entry.
P.S.: I am not using any Ad-blocker add-ons.
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.
Hi Pablo - We're experiencing the same thing. Were you able to get any further on this?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Guy,
Sadly I didn't hear back from Adaptavist anymore and there was nothing I could do, so I stopped looking in this direction.
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.
Hi Pablo, Guy,
Apologies that it's taken a while for us to get back to you.
I've had a go at reproducing the issue on our latest internal build and the problem does not seem to occur: the log entries are produced as expected. On the other hand, I was able to achieve a reproduction on the latest public release (5.2.2). I believe therefore that this issue should be fixed in the next release. I'm afraid I can't give a concrete date for when this release will occur but hopefully it will be soon.
Hope the above info is helpful, and sorry again for the long silence!
J
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.