Making reference field read only on a table without affecting underlying table

yundlu316 · ‎09-13-2016

I have a table that that stores basic employee information (1) and another table (2) that has a reference field referencing the basic employee info table. Through that reference field, I've also dot walked and picked up some additional fields from the basic employee info table. I want to make some of these fields in table 2 read-only, but not read-only in the base table 1 (basic employee info). Is there a way to do that?

I tried following the logic in this post: https://community.servicenow.com/thread/173149#734008, but couldn't find how to get to Dictionary Override as the instruction indicates.

Thanks!

Chuck Tomasi · ‎09-13-2016

I see what you are saying. You want to dot-walk to place them on the form. Correct. You would have to make them read-only on the original field.

In that case, the UI policy (or client) script is going to be your best solution unless you make new fields on table2 and copy the values from table1 instead of dot-walking. This is similar to how the OOB functionality works on the incident form when you see the caller's location. It takes a bit more scripting to copy over the values.

Thank you for your clarification.

FWIW, best practice suggests limiting the number of dot-walked fields from a reference table as it can be confusing to the user where the information actually resides. Using the hover-over icon is a better way to view information on a referenced record.

View solution in original post

yundlu316 · ‎09-13-2016

Hey Chuck, you're answering all of my burning questions today haha. When I check the Read-Only checkbox on table 2, that field also becomes Read-Only in table one. I fixed this issue right now by using an onLoad Client Script on table 2 for the fields I want to be Read-Only.

Thanks!

Chuck Tomasi · ‎09-13-2016

Is table 2 extended from table 1? Have you tried an ACL? Make the field writable by some unattainable condition (like a name field is blank.)

yundlu316 · ‎09-13-2016

No, in this instance Table 2 is not extended from Table 1. Is the Client Script solution ok or is that not considered to be best practice?

Chuck Tomasi · ‎09-13-2016

Client scripts are easily hackable. A server side solution like an ACL or read-only dictionary attribute is more secure. You can go with a client script or UI policy, but keep in mind that the security is never going to be 100% enforceable.

When you tried the read-only checkbox on the table 2 reference field, you said it also made table 1 read-only. That should not be the case unless you are dealing with extended tables. Can you show me what happened?

veena_kvkk88 · ‎09-13-2016

Hi Chuck,

Something's bugging me. How does making the dictionary attribute work here? From what I understand, those other fields are dot-walked from the reference field. So that would mean they belong to the referenced table right? So if we make them read-only on dictionary, wouldn't that mean modifying the original fields?

So, aren't UI policies the best and only approach(apart from client scripts) in this case? Though not 100% secure?