Setting Constraint for document ID field

half_baked1
Kilo Contributor

In following the SNC documentation for configuring a field of type 'document ID', I've configured two fields:

u_reference_table : choice field with choices values of table names (cmn_location, sys_user, etc).
u_reference : document ID field with constraint=u_reference_table

If I set u_reference_table (and save record) the document ID field u_reference will pull up a dialog box with Table name choice and document reference field, with the table name being the one I specified in u_reference_table field. HOWEVER, the table name in the dialog can be changed. Is there a way to NOT show the Table Name choice field to enforce the constraint? It seems like it's not really a constraint if the dialog box allows the user to change the table name.

4 REPLIES 4

CapaJC
ServiceNow Employee
ServiceNow Employee

Maybe you could create a Write ACL to make the table field read-only if it has a value. Or you could create a UI Policy that hides it if it has a value.


It's not so much the table field (in the form that is the constraining field for document_id field type, it's the fact that doing a lookup on a document_id field brings up separate dialog box (ui page document_selector is what it looks like) and that has a table choice field in it. While I could modify that UI page, I don't feel comfortable 'owning' that ui page thereforward.

This behavior can be seen in other plugins which use document id, such as table=grc_task and table=cert_element. For the former:

1. view lists of cert_elements: grc_risk.list (in nav)
2. Add field 'table' to the list view
3. for any record where table isn't empty, open that record in form view
4. select lookup decoration/icon next to 'applies to' field.
5. Here, note that you get the dialog box (ui_page=document_selector) and that the table then can be changed irrespective of the dependent table set in field 'table'.

Same thing with cert_element, though that's not a compelling case since constraint isn't set.

I'm not sure if this is a bug or by design at this point. Basically, it seems that for the documentation on SNC wiki here:

https://wiki.servicenow.com/index.php?title=Creating_a_Document_ID_Field

.. that while it prescribes a separate field to capture and constrain the reference to the tablename specified, that at best, all it does is pre-select that table from the dialog box but doesn't prevent the user from selecting any listed table when setting the reference.


CapaJC
ServiceNow Employee
ServiceNow Employee

Ah, I see what you mean now.

Well, I just had a look at the code, and it *appears* that if a user can't write to the table field on which the document_id field depends, then the table picker will be read-only in that little dialog.

So I'm back to thinking my ACL idea would be the right approach. If you try it, and a correct ACL doesn't work, then I'd call that a bug.


Thanks, that did the trick. In my case i want to constrain the table to a predefined list of tables, so I created a separate read-only field which is calculated from a separate choice list (since that can't be restricted via ACL to read-only). Some security nuttiness I have to sort out as well as client script, but that does get the job done.

I've added feedback on the SNC wiki page for using document ID field type to include this info about adding ACL on the constraint field to make it (and table selector) read-only.