Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


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

David Yu
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Dec 28, 2021

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
AUG Leaders

Atlassian Community Events