Is there any reason why the record.setSublistValue...
# suitescript
s
Is there any reason why the record.setSublistValue would fail to update a record on beforeSubmit when a role other than admin creates a record? The script is deployed and available to all roles. We're currently testing it with roles other than admin and it's not providing any error, it's just failing to update the sublist values
b
is the code actually running?
s
Yes the code runs when triggered by an admin. I found that it's because the permissions are locked down on the field.
What I am not confused about, is that this field is supposed to be executing as the administrator. @battk
b
the record was loaded with the permissions of the current user
that record still would be limited by the permissions of that user even if the script was running using different permissions
s
Okay, got it. Thank you for your help. Is there a way that you could think of that would get around this limitation other than setting the field permissions for those roles?
b
make the change in after submit
or a scheduled script/ map/reduce script if you want to avoid the performance penalty of saving the record twice
s
I attempted to refactor that script to use the afterSubmit entrypoint and it seems to not have made any difference 😞
b
and your code looks like?
s
I am using a helper function
Copy code
- redacted -
and the actual entrypoint script looks like this
Copy code
- redacted -
b
you need to load the record again and submit it
its why this technique is unfavorable performancewise
s
Oh, I see.
b
you can try minimizing by using record.submitFields, but it will still slow your record save
s
Okay, I appreciate your help! I'll take this back to my team and see what direction they want to take. This makes a lot more sense to me now.
p
This happened to me once and it ended up being i was over the 10 client script allowance.