- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-18-2017 10:51 AM
After upgrading to Istanbul from Helsinki, the "Approving" field (type Doument ID) on the sysapproval_approver table form is showing the sys_id of the document being approved rather than the name, which is set to true for display in the dictionary (i.e. Change). Any idea why this might be?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-24-2017 09:47 AM
Hi Tatiana, yes I did. They confirmed the issue and have submitted it as a product bug. As a workaround, they suggested:
- Reactivate the ACL and modify its role requirement from 'maint' to 'itil'
- Create a UI policy to enforce the read only state on the sysapproval_approver.document_id field.
This did the trick for now until a permanent fix is released.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-26-2017 08:01 AM
There is a KB for this in the Hi portal:ServiceNow KB: Document ID field types are showing sys_id instead of display field when marked read-...
We are having the same issue with a few fields, sysapproval_approver begin one of them, after upgrading to Jakarta. It is related to the document ID field being marked as read only on the server side (Dictionary or ACL).
I did validate that removing the read-only flag in the dictionary of a different field having the issue fixed the problem(would have to change the ACL for sysapproval_approver), but making the field read-only with a UI Policy isn't a great solution because it breaks the server side security so if someone knows what they are doing they could change the value.
I don't know of any ETAs or other workarounds.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-26-2017 08:57 AM
Thanks for the link Dale. Arnab, no, I still have an open incident in HI that has had no response yet. Dale, in my case, it was the ACL entry for sysapproval_approver.document_id for the write operation which required the maint role. Once I inactivated this record it displayed properly again, but you're correct, that isn't a good security practice. I will update the Incident I have open with this information and the link to the KB article.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-08-2017 04:36 AM
Hi Jeff,
We had raised a HIT ticket for this issue. They suggested us to follow the same steps as adopted by you.
Regards,
Arnab
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-24-2017 09:32 AM
Hi Jeff,
Did you get an update from HI?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-24-2017 09:47 AM
Hi Tatiana, yes I did. They confirmed the issue and have submitted it as a product bug. As a workaround, they suggested:
- Reactivate the ACL and modify its role requirement from 'maint' to 'itil'
- Create a UI policy to enforce the read only state on the sysapproval_approver.document_id field.
This did the trick for now until a permanent fix is released.