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.
- 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).
- 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
- 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.
- 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.
- 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.