Issue Summary

When adding a custom field to a Request Type, it is possible to hide the field and set a preset value. This value is not being referenced properly when the form is loaded for a new request, and though setting or editing it in the interface causes an update to the value read by the Request Type page, such that it looks like it was properly set/reset, when the request is loaded in the 'Create Request' screen, only old values or no values will be pulled in.  

4.20.11 is not affected by this bug.

5.0.0 & 5.4.3 & 5.5.1  are affected by this bug

Intermediate versions/first introduction of the bug have not yet been confirmed, but it seems 5.0+ is affected, and 4.20.x is not.

Steps to Reproduce

It may be necessary to use Assets Custom Fields to reproduce this; preset values can be set and read, but not by secondary fields, as they read from a different table during issue creation than during Request Type Editing.

It's not necessary to upgrade from an old instance to show that the functionality is broken in 5.5.1, but it is necessary to see that pre-established values are still read and  cannot be altered. 

1. Set up JSM 8.20.11, with an Object Type hierarchy like:
   • Two types of Objects: Org and Sub-Org
   • Create a few objects.  Strictly speaking, 1:1 parent child is all that's necessary, but to test many scenarios I did:
     • Org1 >  Sub1
     • Org2 > Sub2 OR Sub3
2. Create custom fields for each object type, and edit the details (like in https://confluence.atlassian.com/servicemanagementserver0501/default-insight-custom-field-1163766656.html)
   • OrgCF
     • Filter Scope IQL: ObjectType =  Org
   • SubCF
     • Filter Scope IQL: ObjectType = "Sub-Org"
     • Filter Issue Scope IQL: object having outR(Key IN (${Org${0}}))
3. Edit the Request Type 'Get IT Help'
   • Add the fields 'Org' and 'Sub-Org' to the request type
   • Hide the field 'Org' and add a preset value
4. Use the 'Raise a request' button on the left, and submit a new request; the Sub-Org dropdown will be populated with relevant objects.

Install JSM 5.5.1 to demonstrate the bug

1. Test the addition of a hidden field with preset value:
   1. Edit the Request Type Request a Desk Phone. (Or any unaltered/default Request Type.)
   2. Add the fields Org & Sub-Org
   3. Hide Org and add a preset value.
   4. 'Raise a request' of this type, and you will not be able to select any Sub-Orgs.
2. Observe that pre-upgrade types' selections are locked:
   1. edit the 1st request Type: Get IT Help
   2. Check the 'edit fields' and confirm that Org is hidden, and has a preset value. 
   3. Test this request Type by submitting a new Get IT Help Issue, (use the 'raise a request' button on the left-hand navbar)
   4. This Request Type will allow a Sub-Org selection because the preset value was set pre-upgrade.
   5. Return to the edit screen and Edit the preselected value (switch the selection to something else.)
   6. Attempt to raise another request.  This time, the originally selected preset value will have persisted; your selection from step 5 is ignored.

Expected Results

Preset Values for Hidden Fields on Request Types can be altered, and the edits will be reflected in the Raise a Request Screen, and in the fields upon creation. 

Actual Results

Only preset values set before a certain version (5.0) will load in the 'Raise a Request' Screen.

Edits can be made to preset values through the UI, but they will not be read/used upon loading the 'Raise a Request' Screen or in the Issue once created.

Workaround

It is possible to insert the desired preset value directly into the table from which it is missing, in the database. Because Jira can write to these tables while running and the IDs must be equal, Jira should be OFFLINE while database edits are made. Also note, this process is for string type variables with single selections.  Other variables likely work similarly, but with different tables and values.

These are the general steps:

First collect the necessary data.

1. Identify the Request Type's ID by its 'edit fields' link.   
   1. Req Type ID = 17 in this example: 

      http://localhost:8080/servicedesk/admin/TRD/request-types/request-type/17 
      

1. Hide the field and set a preset value in the interface.
2. Get the customfield_id and the desired value, to insert later. If you already have them, you can skip this step, but it's good to ensure the database value you intend to us can be stored as 'text' according to the below query results. 
   1. 1. customfield_ID = 'customfield_10115' in this example
      2. value = 'FRF-8' in this example
      3. To find your customfield and value, if you don't already know them, plug in your Req Type ID in place of the FORM_ID 17 below: 

      4. SELECT VPF."FIELD_ID", VPF."FIELD_TYPE", VPV."VALUE" FROM "AO_54307E_VIEWPORTFIELD" VPF, "AO_54307E_VIEWPORTFIELDVALUE" VPV WHERE "DISPLAYED" = 'f' AND VPV."FIELD_ID" = VPF."ID" AND "FORM_ID" = 17;

1. 1. 1. Example Data:

     FIELD_ID      | FIELD_TYPE | VALUE
-------------------+------------+-------
 customfield_10115 | text       | FRF-8
(1 row) 

If your field type is not 'text' in this table, this workaround is untested for your scenario. Consider engaging Atlassian Support before continuing. 

1. Shut down Jira.
   1. Jira should be stopped, or the max values retrieved below may not be valid when you insert them. 
2. Find the max IDs for the relevant property tables:

1. 1. select MAX(ID) from propertyentry;

1. 1. select MAX(ID) from propertystring;

Now compose and send the 2 Insert queries.

1. Create two insert statements using the values collected so far:
   1. The req type id, in this case 17
   2. The value you want to set (in this case FRF-8)
   3. The new Max ID you will insert: 1+MAX(MAX(pe.ID), MAX(ps.ID))
      1. If your max ids for propertyentry and propertystring are 11020 and 11017, then your new IDs should be 11021, in both tables, because it is higher than both.
   4. The customfield name from viewportfieldvalue
2. WITH Jira STOPPED, insert the new rows into each table, propertyentry & propertystring:

   1. PSEUDO:
      INSERT INTO propertyentry values (newIDHere, 'INSIGHT-GENERAL', 1, 'insight_jsd_reqtype_cf_yourFieldHere_reqTypeIDHere', 5);
      
      EXAMPLE: 
      INSERT INTO propertyentry values (11021, 'INSIGHT-GENERAL', 1, 'insight_jsd_reqtype_cf_customfield_10115_17', 5); 

1. 1. PSEUDO: 
      INSERT INTO propertystring values (newIDHere, yourValueHere);
      
      EXAMPLE:
      INSERT INTO propertystring values (11021, 'FRF-8'); 

1. Start Jira and confirm the new request type screen has the proper value.

This workaround is delicate and requires Jira to be stopped and then restarted. This workaround is only tested so far in Postgres databases but should be adaptable for others by changing syntax.

If you would like more information about implementing a workaround, please contact Jira Support. 

Warning

Make sure the values set in both VIEWPORTFIELDVALUE and propertystring (if field type is 'text') table are the same, otherwise, it will raise error.