Approving field on sysapproval_approver showing sys_id

Cupcake
Mega Guru

We just upgraded to Jakarta a few weeks ago and we just discovered the Approving field from the systapproval_approver table is showing the sys_id instead of the value.

I've read the current articles out here regarding the same issue and the workaround is to uncheck the Read Only field on the dictonary.

So in my situation, I've gone to the table to see if the dictionary entry was Read-only and it is not. So why is is still showing the sys_id.

find_real_file.png

I found a UI Policy that is scripted and I am wondering if this is what is blocking it. Can someone review the code below?

I have not found anything else that would force the sys_id.

function onCondition() {

          var docField = g_form.getControl('document_id');

          var sysField = g_form.getControl('sysapproval');    

          var docValue = g_form.getValue('document_id');

          if (!docField && !sysField) {

                  alert('There must be a reference field on the form to associate approval with and item. Use Personalize Form Layout and select the Approving field');

                  return;  

          }

          // the legacy field is the sysapproval field, going forward using document_id

          // for legacy users, if the document_id field does not exist, still allow

          // the sysapproval field to prevail

          if (!docField && sysField) {

                  g_form.setVisible('sysapproval', true);

                  return;  

          }

          // if there is a docField with a value then assume that

          // this is a current record and hide the sysapproval field

          if (docField &&   g_form.getValue('document_id').length > 0) {

                  g_form.setVisible('sysapproval', false);

                  return;  

          }

***** I am thinking this may be causing the issues ******

        // knowing from test above that there is no doc field with a value

          // check to see if there is a sysapproval with a value. If so, assume this

          // is potentially a legacy record and allow sysapproval to prevail

          if (sysField && g_form.getValue('sysapproval').length > 0) {

                  g_form.setVisible('sysapproval', true);

                  g_form.setVisible('document_id', false);

                  return;  

          }

          // if not a sysapproval with value and not a document_id with data, then assume that this

          // is a new record, with an empty doc field and empty sysapproval field, and force

          // the docField

            g_form.setVisible('sysapproval', false);

            g_form.setVisible('document_id', true);

}

14 REPLIES 14

Cameron Wilson
Tera Expert

Karen,


We just upgraded from Helsinki to Istanbul and have the same issue across all records that use the document_id dictionary value. I came across this community post (below) about it as well and this appears to be a bug that SN is aware of as they also have a KB article on it too.



https://community.servicenow.com/message/1246263#1246263



ServiceNow KB: Document ID field types are showing sys_id instead of display field when marked read-...



I have tried to create a UI policy as suggested by SN to make that field read-only but that did not work. I also tried to set the dictionary value to read-only, also did not work. In the other community post it was noted that making the sysapproval_approver.document_id record (ACL) inactive corrected it. I have yet to try that and am a little reluctant to that being a viable fix.


Good day Cameron,


        I just deactivated the ACL and it is working perfectly for me. I have my team confirming that everything looks good and then I will have the customer that reported the issue test as well.



You should be safe with deactivating the ACL. Not sure if this is the best method, but it works.



Regards,


Karen


I am about to do this as well.



I did raise a ticket with HI yesterday and they have an active pending Problem (PRB1155488) and this was their workaround as well until they come up with a fix.



Thanks,


Cameron


Yes I opened a ticket as well just so they could track how many customers are having the issue.



Good luck to you.



Karen


LaurentChicoine
Tera Guru

The solution proposed by HI made no sense to me, deactivating security to replace that with a UI policy? Really, so that advanced user could change the record they are approving or remove approvals by changing the record it is approving for, not only putting a mess in the approvals but also in the workflows surrounding them.



So I had two solutions to this:


  1. Put a data policy in place instead (that way security is still enforced), however doing it this way removed the reference icon that allows to preview the record or open the record by clicking it.
  2. Create a client script / Display business rule that sets the display value right, however this solution makes the sys_id appear at first before it being replaced.


Business rule:


Name: Set approving display in scratchpad


Table: Approval [sysapproval_approver]


Advanced: True


When: display


Filter condition: Approving is not [leave blank]


Script:


(function executeRule(current, previous /* null when async */) {


       


        g_scratchpad.approvingDisplayValue = current.document_id.getDisplayValue();


       


})(current, previous);



Client script:


Name: Set approving display value


Table: sysapproval_approver


UI Type: Desktop (I did not test mobile or both, and we only use desktop for now, I don't know if this is an issue in the mobile UI)


Type: onLoad


Script:


function onLoad() {


        if(typeof g_scratchpad.approvingDisplayValue != 'undefined'){


                  g_form.setValue('document_id', g_form.getValue('document_id'), g_scratchpad.approvingDisplayValue);


        }


}