Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

When shared configurations go wrong: Service Desk, field configurations, and required fields


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:

left join "AO_54307E_VIEWPORT" on "AO_54307E_VIEWPORT"."ID" = "AO_54307E_VIEWPORTFORM"."VIEWPORT_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




Log in or Sign up to comment
Community showcase
Published in Jira Service Management

JSM Jira Automation: How to Send SLA Breached Notifications

Hi Everyone, In   this tutorial,  we will show you how you can monitor an SLA, and send notifications before or after the SLA has been breached.   SLA Threshold Trigger The SLA t...

599 views 5 12
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you