We know re-using schemes saves time, but there's a trap I occasionally fall into. It happens so infrequently but when it does, the amount of effort to revert it can be huge. Here's an article in case in helps someone in the future:
Suppose you have a Field Configuration Scheme shared amongst hundreds of projects. You want to change the Field Configuration Scheme to one that requires a Due Date. You somehow accidentally alter the Field Configuration instead making Due Date required on the Shared Configuration.
Now, any users that visit any portal that uses this configuration will suddenly contain the field Due Date added automatically by Service Desk! And if you are unlucky, it can get added to every request type within a project.
The problem is even more nefarious if you add a field such as Security Level, and there is no associated Security Level Scheme; users would be blocked from creating portal tickets.
So if you don't catch this problem soon enough, you can potentially have fields added to all your requests types.
Since there's no audit log of what request types are added where, you could be in for a long session of trouble-shooting.
A strategy you can use is comparing database outputs from production and compare it.
Use this SQL query to find all forms that utilizes the field "security" for example. You'll want to run it on both production, and a recent backup copy. The first two columns are the key pieces:
select "FORM_ID","AO_54307E_VIEWPORTFIELD"."ID", "AO_54307E_VIEWPORT"."KEY" ,"AO_54307E_VIEWPORT"."NAME"
from "AO_54307E_VIEWPORTFIELD"
left join "AO_54307E_VIEWPORTFORM" on "AO_54307E_VIEWPORTFORM"."ID" = "AO_54307E_VIEWPORTFIELD"."FORM_ID"
left join "AO_54307E_VIEWPORT" on "AO_54307E_VIEWPORT"."ID" = "AO_54307E_VIEWPORTFORM"."VIEWPORT_ID"
left join "AO_54307E_VIEWPORTFIELDVALUE" on "AO_54307E_VIEWPORTFIELD"."ID" = "AO_54307E_VIEWPORTFIELDVALUE"."FIELD_ID"
left join project on project.pkey = UPPER("AO_54307E_VIEWPORT"."KEY")
where "AO_54307E_VIEWPORTFIELD"."FIELD_ID" = 'security'
order by "FORM_ID"
You can use your favorite diff/comparison utility at this point to compare the output. I like to use comm: (it expects two sorted files so sort first!) comm -2 -3 prod.sorted.txt dev.sorted.txt which then gives me all the unique entries in file prod.sorted.txt.
Now that you have all the affected forms, eyeball it, and check a few entries manually by going into the portal form!
You must first unrequire the field on the form, then, remove it. These two curl calls perform this respectively. You'll need to pass in the FORM_ID and "AO_54307E_VIEWPORTFIELD"."ID":
curl -u "admin:x" -H 'content-type: application/json' -X PUT "https://jira/rest/servicedesk/1/servicedesk/$FORMID/request-type-fields/visible/$FIELDID" --data-raw "{\"id\":$FIELDID,\"required\":\"0\"}"
Once unhidden, you can delete and remove the field from the portal form:
curl -u "admin:x" -X DELETE "https://jira/rest/servicedesk/1/servicedesk/$FORMID/request-type-fields/visible/$FIELDID?undefined"
Please test carefully and make backups! Hopefully this is helpful to someone in the future, and serves as a reference for myself in case I ever do this again. :-D
