Theory: "Resetting" ACL on your Custom Tables on Upgrade on your Custom App/Scope

[ShaneFr]

Dear SN Community -

So I been doing a lot of programming lately in our SN instance... and I think it's somewhere in the 500+ hours while taking care of my primary responsibility to keep my hospital IT department operational and I think the biggest pain for me has been the ability to make sure that ACL records in my "app" are clean each time based off what I have developed based off in dev/test.

The idea is that you have to mark your "rules" false if they no longer apply seems really crazy to me. And you can't delete them manually because you will have "Customer Updates" and upgrading will become a problem if they have the same SYS_ID. Thus, a problem. Plus I seen my own app have better preformcenc e when I had 22 rules that 96 rules did the same so I re-desgined it tonight, but I also had to do like 4 point releases to fix it and not have it in Customer History Update sets.

Pradeep Sharma posts here the best practices. In theory this is the best way and safest way, but if you are like me and like perfection in your app and your update sets from your app I digress and move towards trying to clear up ACL rules. Hence, theory talk. I bring this up as theory because Scope Apps usually do not have Update Sets when moving around inst...

Fix Scripts, from what I can tell do this job really easy.\

Take this for example (and do this is a personal dev instance to try it out.)

1. Create a scoped app.
2. Create a simple table: Test
3. Get the SYS_ID of the "Test" app.
4. Enter a Fix Script with these checked off: "Before", "Flush cache",  and "Active" (Code @ Bottom)
5. Change the SYS_SCOPE to your SYS_ID of the APP.
6. Make several versions of your app and publish it to your prod/other instance with changes to ACLs that existed and then did not exist.
7. It should in theory reset your ACL rules each time your app is published to the system.

Unforgettably I can not test this currently. I don't have the ability to spin up instances that can transfer apps, but if anyone who does give this a try, let me know. This could in theory also clear all Customer Updates each and every time as well. Of course you as the app publisher can stop certain tables (like my Assignment Data Lookup Table table) to noy clear out each and every time so that the end user can modify the content outside of anything that I do. The Fix Script does not create a Customer Update "record" nor does it create a "version" record, so... yeah. Clean 🙂 You could in theory make sure that any extra stuff that you will put in and get rid of delete. You just have to test it extensively before sending to your clients/customers.

So... let me know what you think. This is all theory. I have not tested this out.

var gr = new GlideRecord('sys_metadata');
gr.addQuery('sys_class_name', 'sys_security_acl');
gr.addQuery('sys_scope', 'e6dfbce4db33130041b1f36f29961988');
gr.query();
gr.deleteMultiple();