- My View
I have 6 catalog item that will contain SSI info. Let say, Employee Termination. It would be use by a manager or HR for immediate termination, "get ready to get walked out" kind of thing so they lose access to system immediately or End of Day. So the ACL has to be tight and limit to the Opened_by, the Approving Manager and the Network Security Team. Don't log or email or show in Reports....
I have an ACL on sc_req_item that uses a script and a system property that has all the sys_id's of the SSI catalog items. It's working. Looks something like this.
!gs.getProperty(security_forms).includes(current.cat_item) ... and more logic to let in the people we want hasRole, isApproving....
The part that is stopping me is writing the SC_Request ACL. The requests short description and the requested_for tell the story that Employee X was walked out so I need to hide it from view but I can't figure out how to write the ACL on sc_request because I can't read the sc_req_item.cat_item. I can't use glide as I assume record level would cripple the system.
I tried Business Rules, that almost worked but it wasn't very secure (I hacked around it in minutes) and it got in the way of WF actions like Approval and create SC_Task.
So, I need some advice or ideas on hiding REQ if any of it's RITM are SSI. I maybe can live with hiding the 3 fields but that would have to be every place you can see REQ info.
I'd rather not hack in some SSI true/false flag when I have the information in a related record.
Thanks for the time
Here's a different approach for you
Add a Yes/No field to the sc_request table named "u_secure_ritm_present". Default it to No.
Then, in the workflow for each of the sensitive catalog items, add a "Run Script" widget and set "parent.u_secure_ritm_present" to Yes.
Then modify your ACL for the sc_request table to hide the request if "u_secure_ritm_present" is yes.
You can use whatever name you like though...
Thanks, I was hoping to avoid storing information I should be able to access but I feel I may have to. I found a community thread (#251998) that reported HI telling them to use GlideRecord in a read ACL. wow, that can't be good.
For long term support, I think I'm going to use a string for "u_secure_ritm_present" and concatenate the groups with access from the WF. That way I can test if the SSI groups split, my code doesn't break. Yes/No would work today but I'm sure they are going to tell me to show Vendor SSI records to legal people for contract breach or something. If I have to save the info I may as well store details.
Unless something fantastic is posted in the next day or so, i'll mark you correct.
Sounds like you have a good bead on things. I like your approach of adding the groups in the field. It gives you more flexibility with reports. Should make any auditor happy!