ACLs Vs. Business Rules for security?

Short answer: ACLs.

Longer answer: ACLs, but also sometimes query business rules; but usually for performance reasons more than security.

There are benefits to using Query Business Rules. Namely, performance benefits. This is because query Business Rules fire before ACLs run, which means that not only are you potentially returning fewer records, but you’re also eliminating whatever performance cost may have been associated with the ACLs themselves (which is a non-zero amount, especially if they’re script-heavy). That’s not to say that you should aim to go and replace all of your ACLs with query Business Rules, but there is definitely a case to be made for using both.

On the topic of security, though: one reason that I see people using query Business Rules is because they want to get rid of that “n records removed due to security constraints” message which shows up when ACLs block access to records in a list view. However, that message is often good! It makes troubleshooting really easy! Personally, I've never had a user complain about this or be confused by it, and it's really simple to explain if they do. The lack of such a message, when records are removed by "security" (using query business rules, which provide no such message) is what anyone trying to troubleshoot missing records could find confusing.

Click “Read more” below, to see the full article!

After being asked how to remove information from, or delete, a journal entry three times in as many days, I finally decided to get off my butt, and write this tool. Then I realized that it's difficult to code standing up, so I sat down back on my butt, and got to work.

If you've ever tried to modify or delete a journal entry, you probably already know what an ordeal it can be, and you've likely sunk hours into the attempt, if not thrown your hands up in frustration altogether! There are at least four distinct tables involved in modifying/redacting or deleting a journal entry, each with a unique schema, some dependent on others, and some stand-alone:

Journal Entry [sys_journal_field]
Audit [sys_audit]
History Set [sys_history_set]
History line [sys_history_line]

"Why the hell is this so complicated?" would not be an unreasonable question to ask, but each of these tables actually does serve a unique and valuable purpose. The difficult part (once you've identified all of the tables a journal entry's data might reside in), is identifying how they all work together. Then you have to actually locate the record in each table that corresponds to the specific journal entry you want to redact, and modify it in some way (which may be different depending on what you're trying to do, and what table you're interacting with.

Or - you could simply grab the tool I've just written, and use that instead! Click below to read more.