Greetings,
I have a web fragment that creates a constrained issue. I have a behaviour that uses the id of the fragment to add the source issue as a linked issue. I began this using https://scriptrunner.adaptavist.com/latest/jira/fragments/CreateConstrainedIssue.html as an example.
Here is the current code of the behaviour (basically just modifying a custom field right now so I can see what is happening):
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.ComponentManager
import com.atlassian.jira.issue.fields.CustomField
import static com.atlassian.jira.issue.IssueFieldConstants.*
import com.onresolve.jira.groovy.user.FieldBehaviours
import groovy.transform.BaseScript
@BaseScript FieldBehaviours fieldBehaviours
ComponentManager componentManager = ComponentManager.getInstance()
def issueManager = ComponentAccessor.getIssueManager()
//Check to make sure this is the correct context for the behaviour.
def myValue = getBehaviourContextId()
def myIssue = getContextIssueId()
getFieldByName("Customer Cross-Reference Number").setFormValue("Another Value: " + myValue + "|" + myIssue)
If the button created by the web fragment is at the "top" of the menu (always visible without pressing the "more" button), the behaviour is able to use the ID and execute its logic (in the case of the above code, this displays the ID of the web fragment after the words "Another Value" in a custom field). If the button is under the "more" drop-down, then the ID becomes null and is unusable (two nulls appear in the custom field after the words "Another Value").
After further experimentation, it looks like when the button appears at the top of the menu, the create screen appears as a "floating" form. However, when the button is lower in the "more" menu, the create screen becomes a separate page. The logic for the button is identical in either case, so I'm kind of tearing my hair out here...
Would anyone be able to assist? I'm open to alternative options for issue linking or some "workaround" that allows my buttons to work as expected.
@Taylor Chase you can find more info on the issue here: https://productsupport.adaptavist.com/browse/SRJIRA-2926
Annoying, looks like the base issue is a bug in JIRA...
I'm going to try the workaround and see how it goes.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Laurens Coppens, @Taylor Chase
This issue is caused by a bug within Jira itself (annoying indeed ... ), but since it affects lots of people we thought to reopen it and try to fix it ourselves.
Please do try the workaround and ping me if there are any further questions.
Regards, Thanos
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Thanos Batagiannis [Adaptavist],
The workaround works for the initialization portion of Behaviours (so the create window automatically sets a linked issue :) )
However, a standard field behaviour does not "know" about the context id or the field id. (If I do a simple setFormValue() using getBehaviourContextId(), I get a null value). It looks like the javascript workaround is setting the values properly, so I don't know why they are making it to the initializer and not the individual behaviour entries. This is annoying to me because I would like to have a single constrained issue form that is able to support multiple issue types. I can live with it if not, but if there is a fix for that I would be quite pleased :)
(To replicate the issue, use the workaround to create a "create constrained issue" button that opens the create form according to the examples provided by Adaptivist. After doing this, comment out the line that disables the issue type button and change the issue type. This leaves the text box values untouched but empties the "linked issue" field. Setting up a "server-side" script that similarly works off the getBehaviourContextId() will never do anything because getBehaviourContextId() will evaluate to null by that point.)
Having re-read my description of my issue... is the problem that while the client-side knows about the id through the Javascript modifications, the "server" does not?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
Are there any news regarding the empty fields after changing the issue type (or the project)?
I would develop another workaround but it is really hard to find an approach...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
According to the bug report linked above, this has been fixed in 7.13.1.
I have that version installed in our production and test environments, but I have not yet tested it. I will respond here once I have. (this is lower priority for my users, so other things have taken my time instead)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi
There is also a problem if user right click on the menu item and choos "Open in new tab" or new window.
The getContextIssueId() and getBehaviourContextId() functions returns null value.
Jira 8.14.1
ScriptRunner 6.28.0
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @Jesper Stein ,
I am facing the same problem right now. Did you find any solution/ workaround for this?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Taylor Chase I have the exact same problem, I logged a bug in the scriptrunner SD, will keep you updated.
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.