[SRJIRA3328] Script Field Partially Duplicated After Adding A New

[srjira-3328] script field partially duplicated after adding a new configuration context created: 15/feb/19 updated: 15/aug/19 resolved: 15/a

[SRJIRA-3328] Script Field partially duplicated after adding a new
configuration context Created: 15/Feb/19 Updated: 15/Aug/19 Resolved:
15/Aug/19
Status:
Done
Project:
SR for Jira - Development
Component/s:
Scripted Fields
Affects Version/s:
5.4.49
Fix Version/s:
5.6.1
Type:
Bug
Priority:
High
Reporter:
Aidan Derossett
Assignee:
Jamie Echlin
Resolution:
Done
Votes:
3
Labels:
None
Remaining Estimate:
Not Specified
Time Spent:
Not Specified
Original Estimate:
Not Specified
Issue Links:
Blocks
Cause
Duplicate
duplicates
SRJIRA-3101
Creating a new script field overwrite...
Done
Problem/Incident
Reference
relates to
SRJIRA-3068
The Script Fields page doesn't reflec...
Done
relates to
SRJIRA-2564
Script fields break when the field ha...
Done
is related to
SRJIRA-3229
EditableScriptFieldTrait tries to fet...
Done
Sprint:
Sprint 49, Sprint 50, Sprint 51, Sprint 52, Sprint 53, Sprint 54,
Sprint 55, Sprint 56
Critical Points:
4.2
Description
In short, when you add a new configuration context to a Script Field,
a new partially duplicate Script Field entry is created and visible in
the admin page.
Steps to Reproduce (tested in Jira 7.13.0):
*
In a clean instance, set up a new project and immediately navigate
to the Script Fields admin page and create a new Custom Script
Field, complete with a description, note and basic inline script.
*
Next, go to the Custom fields administration page and locate the
field you just created. Click the cog to the right of the field
and select Configure.
*
On the configuration page, click the link to "add new context" and
created a new context that is different from the default.
*
Immediately after adding the need config context, go back to the
Script Fields admin page and lo-and-behold, there is a new
configured field with the same name as the one you had originally
created. Only the new field doesn't contain any of the changes
made to the original (such as a description, note, or script).
Other important quirks:
1.
When you attempt to reproduce this with Script Fields like the
"Issue(s) picker" field, it can potentially break the fields
completely. To illustrate, create a new Issue picker field, but
only give it a name. After creating the Script Field, immediately
update it without making any changes. Then follow the steps to
reproduce the bug above. After doing that, you'll notice that this
time the duplicated Script Field takes the same config context as
the original; this means that the two Script Fields are exact
copies of one another, which make editing them or accessing them
via the "Modify field parameters here" link (from the CF's config
context page) impossible; presumably due to SRPLAT-217.
2.
If you delete one of the duplicate script fields, the context for
that particular duplicate will also be deleted, but the custom
field itself and the Script Field associated to the remaining
config context will not be deleted.
3.
If you edit the custom field's name via the Custom field admin
page and then add a new config context to the field, the original
Script Field won't be renamed, but occasionally the duplicate
Script Field's name will.
1.
To build on this, if the duplicate Script Field's name doesn't
reflect the name change, go back to the configuration context
for the field and delete the default configuration. Then, go
back to the Script Field admin page and you'll notice that the
remaining script field (the duplicate made from adding a new
config context) will automatically have its name switched to
whatever it was updated to via editing the custom field.
Comments
Comment by Jan Scherks [ 01/Mar/19 ]
The same happened in Jira 7.11.2 and SR 5.4.48 with the connection to
SRJIRA-3229
Comment by Jamie Echlin [ 26/Jun/19 ]
Hello...
I'd like to talk through some of the points above, and get some
opinions.
> If you delete one of the duplicate script fields, the context for
that particular duplicate will also be deleted, but the custom field
itself and the Script Field associated to the remaining config context
will not be deleted
This is by design, it will only remove the custom field if it's the
last context for that field.
> Immediately after adding the need config context, go back to the
Script Fields admin page and lo-and-behold, there is a new configured
field with the same name as the one you had originally created. Only
the new field doesn't contain any of the changes made to the original
(such as a description, note, or script).
This is by design. Our thinking was that if your intention is to
create a new context, then you would also want a different script, or
template, or some other configuration of your script field to be
different between the contexts.
After creating a new context, it should be a complete copy of your
script field, but this is just a starting point (that it doesn't is a
bug, but I'm not sure how important it is given the following). We
would not attempt to keep them in sync after the creation, because it
would overwrite changes you had made for the script in a different
context.
This seems similar to the behaviour for say a select list... when
creating a new context, the options are not copied nor do they stay in
sync.
On the other hand, possibly people are creating new contexts because
there is no other way to apply a field to issue type "Bug" in Project
A, and also issue type "Task" in Project B. Is that the case with you?
The thing is, creating different contexts for the same field causes
other problems too. Take for example an issue picker field. You can
define a JQL query to limit which issue the user can select. If you
use different JQL queries in different contexts, when using the basic
search, we don't know which context is in play (could also be both or
neither). Therefore in the dropdown in the searcher, we can't know
which JQL query to allow the user to pick the issues from.
So for us multiple contexts for the same script field is a bit of an
anti-pattern... but unfortunately there is this Jira quirk whereby you
can't have multiple associations of project-issuetype pairs without
creating multiple contexts.
If this is the predominant reason people are creating new contexts,
then we can look at only having a single script field configuration
per custom field, not context. To be honest that would make things a
lot simpler from our perspective.
cheers, jamie
Comment by Taylor Chase [ 26/Jun/19 ]
My particular issue is with Quirk #1 of this bug. The duplicated
context will sometimes overwrite the content of another scripted
field, causing it to have the same result as the original scripted
field, and I am unable to change it!
If moving to a single field configuration per custom field would
prevent this behavior, it would save me a lot of work. And speaking
for myself, the reason I would add an additional context to a scripted
field would be your example (limiting the field to issue type A in
project 1 and Issue type B in project 2), I can't think of a scenario
where I would add another context in order to get the field to do
something different. I would be much more likely to just create an
additional field.
Comment by Lara López García [ 26/Jun/19 ]
Same as Taylor, Atlassian always recomends contexts for better
performance, I do not want different scripts for different context (
that would be sooo confusing) I just need different issuetypes in
different projects.
Comment by Tarun Sapra [ 27/Jun/19 ]
Hello Jamie,
I was given the link of this issue from the Adapatvist support team.
We do use lot of scripted fields in our instance for variety of
reasons. Sometimes in script itself I have to create 2 different
functions to deal with two different projects. In most of the cases
having single context of the scripted field is sufficient. But in some
complex automation scenarios there is a need to have separate contexts
for the scripted field so that I don't have to write multiple large
functions to have different functionality for different
projects/issueTypes supported by the same scripted field.
For example - A scripted field can be "Story points aggregation" , now
this field can show the sum of story poitns of all child stories on an
Epic. Also, in some cases this field is used to aggregate story points
from the linkedIssues of the Epic instead of child story points, hence
instead of creating separate scripted field for handling these 2
scenarios it will be great to have a single field be able to support
different context with different scripts .
Comment by Jamie Echlin [ 01/Jul/19 ]
Hi Tarun and others...
Thanks for your input. It makes sense.
> Atlassian always recomends contexts for better performance
Yes... but my recommendation is if you have an issue type called say
"Defect", it should have the same workflow, same listeners, behaviours
etc, across all projects. Also it should have the same fields, which
means that you would only need a single context for the custom field,
as you would apply it only to "Defect" and whatever else. Having a
"Defect" behave one way in one project and a different way in another
causes confusion and maintenance headaches. If you are actually
modelling a different business entity, I would create a new issue
type. Anyway, I recognise the real world is not perfect.
Tarun - in your script for the script field, you have access to the
project and issue type, so you can do different things depending on
that. So I'm not really sure whether you are arguing to have a
different script/parameters for different contexts of the same custom
field or not...
In light of all this, I think we got the original design wrong, but we
have to be backwards compatible for people who are relying on this. My
plan is:
*
when creating a new context we will no longer duplicate the script
field configuration
*
but you will have an option to duplicate the configuration if you
want to
*
and an option to delete script field configurations if you want to
have just a single one for multiple contexts
So going forward I expect most people to have a single configuration
per script field, not per field context.
Plus we will fix the bug that this ticket was originally created for,
and possibly an upgrade task if our configuration data requires
cleaning.
This is rather a large task, so I will be creating separate stories to
represent this all, I'll link it here.
Thanks for your patience...
cheers, jamie
Comment by Jamie Echlin [ 04/Jul/19 ]
When this is fixed the fix will just be for the partial duplication of
the field, and that it can't be edited. I will create another ticket
for the task of being able to use the same configuration for multiple
contexts, when we've worked out the design.
If you are stuck not being able to edit script fields because the drop
downs don't show anything, the workaround is to delete the additional
contexts from Custom Fields -> choose your field -> Manage Contexts.
Generated at Fri Mar 11 01:31:06 UTC 2022 using Jira
8.13.15#813015-sha1:24256f8a55853293c87d0465fdf0407f4975035a.