ACL for sc_request table field: Requested for

ajlabate · ‎10-10-2014

When a user is submitting a request from the Service Catalog, I present them with a variable field that is pre-populated with them as the requester. They have the ability to enter a different valid name if they are submitting it for someone else. When I test this it works fine, but that's because I am an admin. I'm trying to figure out how to make that field in the sc_request table editable by anyone (even users). I created an ACL for the field with no conditions and no script. I just added the user role to be able to execute, create, or write. However, this does not work. Can someone tell me what I need to do to make this work so that anyone submitting a request from the catalog will have the ability to overwrite this field?

ajlabate · ‎03-19-2015

I did get this resolved, but can't remember the actual fix. The only thing I could find was that I updated the "Write" operations of the ACL's for sc_cart.* and sc_cart to force the script to always evaluate to True. This is what I have in the Script section:

var answer = true;

answer;

No roles or conditions are used. See if that does the trick for you.

>>> Marik Daniel <community-no-reply@servicenow.com> 3/18/2015 3:35 PM >>>

( https://community.servicenow.com/?et=watches.email.thread )

ACL for sc_request table field: Requested for

reply from Marik Daniel ( https://community.servicenow.com/people/NMSLAcker?et=watches.email.thread ) in Authentication - View the full discussion ( https://community.servicenow.com/message/765519?et=watches.email.thread#765519 )

Anthony did you get this fixed in your Dublin instance yet?

I am running into the same problem with our script not populating for non-admin users.

It was working until recent patching.

I've looked at the sc_cart ACL's and even made one specific to the Requested_for field but it is still not working.

Even specifying the test user directly in the ACL's didn't work for the non admin user.

We are currently on patch dublin-09-13-2013__patch7-hotfix5-01-22-2015 where the script is not working.

I believe we were on patch 3 when it was known to be working.

Any feedback you might have would be useful.

Reply to this message by going to ServiceNow ( https://community.servicenow.com/message/765519?et=watches.email.thread#765519 )

Start a new discussion in Authentication at ServiceNow ( https://community.servicenow.com/choose-container.jspa?contentType=1&containerType=14&container=2103&et=watches.email.thread )

Following ACL for sc_request table field: Requested for ( https://community.servicenow.com/message/765519?et=watches.email.thread#765519 ) in these streams: Inbox

( https://www.facebook.com/servicenow ) ( https://twitter.com/servicenow ) ( http://www.linkedin.com/company/servicenow ) ( http://www.servicenow.com )

"This electronic mail message contains information which may be confidential, privileged and protected from further disclosure. Such information relates to and is used for all purposes outlined in the statutes below, including Peer Review, Performance Improvement, Quality Assurance and Claims Management and Handling functions and/or Attorney-Client Communications. It is being produced within the scope of all Georgia and Federal laws governing record confidentiality, including (but not limited to) Official Code of Georgia Annotated Sections 31-7-15; 31-7-130; 31-7-131; 31-7-132; 31-7-133; 31-7-140; 31-7-143.

If you are not the intended recipient, please be aware that any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please reply to the sender immediately and permanently delete this message and all copies of it. Thank you.

Communication of electronic protected health information (ePHI) is protected under the Health Insurance Portability and Accountability Act (HIPAA) Act of 1996. Electronic mail (e-mail) communication is not encrypted or secure. The HIPAA Security Rule allows for patients to initiate communication of personal health information over this medium and for providers to respond accordingly with the understanding that privacy of communication is not guaranteed."

View solution in original post

ajlabate · ‎10-13-2014

My issue isn't with getting the field to be updated, it is with non-admins being able to execute the workflow and having it get updated with their input. When I do it, it works fine, but I am an admin. If I impersonate an itil user, it will not work. I just can't determine where it is only allowing an admin to update that field.

Raj4 · ‎10-23-2014

I had the same issue. I had to create an acl on Shopping Cart table to allow write access to itil users.

DianeBrees · ‎11-19-2014

Anthony, I'm having the same problem. Below is the script I'm using but again, it only works if you are an admin. I would like to find out how to make this work for all others. Many times an administrative assistant will submit a request for their VP, put the VP's name in the requestor variable but the Requested For field gets populated with the administrative assistant name instead of the VP's name. However, if I perform the exact same steps the VP's name will show up in the Requested For field. Its very frustrating and I would really like to figure out how to have the Requested For populated correctly.

If you have found an answer could you please post it. Thanks!!!

function onSubmit() {

//-- Populate Request For from variable

var for_userid = g_form.getValue('requestor');

var userid = g_user.userName;

var cart = new GlideRecord('sc_cart');

cart.addQuery('user.user_name', userid);

cart.query();

if (cart.next()) {

cart.requested_for = for_userid;

cart.update();

}

ajlabate · ‎11-20-2014

If I remember correctly, there was an out of box ACL on the sc_cart that had to be removed. Once that was removed everyone was able to override the default Requested For field.

randrews · ‎11-20-2014

if it is working for admins and not for users.. yes look for an acl on the requested item table.... on the requested for field specificly