- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-04-2017 08:47 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-04-2017 10:59 AM
Yes it is. You can prove this by doing a debug statement like
gs.info(gs.getUserID()); // display this user's user ID.
Why do you ask?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-04-2017 10:58 AM
Can you give more context? Is there a specific business rule you're curious about? There are Glide Session methods like gs.getUser() which return the logged in user.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-04-2017 10:59 AM
Yes it is. You can prove this by doing a debug statement like
gs.info(gs.getUserID()); // display this user's user ID.
Why do you ask?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-04-2017 11:04 AM
We were having a discussion as to why BR doesn't adhere to ACLs when they update a record etc..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-04-2017 11:31 AM
That's where I thought you were going. If the script uses a GlideRecord() operation, then the system account is used and effectively, ACLs are ignored. The best practice is to use GlideRecordSecure() as a default to enforce security and use GlideRecord() as an exception.
