I hope this helps provide some details. I’m not trying to say anything about the validity f your concerns, just sharing some data.
4 Likes
3 Likes
Here’s another idea from Epicor dev on the matter:
You can create an Updatable BAQ on QueryHdr and update SecCode.
Unfortunately this will not work on System BAQs.
Add the UBAQ to a UDASH.
Copy to Excel then make the changes in Excel to the SecCode field and copy everything without the header row in Excel and then in the UDASH Paste Update.
Make sure they have a backup just in case and that they should test it out on a few records first to make sure it updates correctly and that the users cannot see it in the HomePage.
Nice idea… Still, hoping the checkbox and default security code ideas get taken seriously soon 
1 Like
Just added my 3 votes.
1 Like
Also on this note make sure you all do Menu Level Security… some folks put Folder Security and then dont realize that someone can still add a dashboard to auto-run via Tab in classic/modern.
3 Likes
Has anyone heard of any progress on this issue with 2023.1? I’m seeing a field in SysUserFile that I don’t remember - CanMaintainFavQueries - but toggling it doesn’t do anything.
Not only is going through the system BAQs a labor intensive process, but selecting each BAQ’s security to ensure that it won’t mess up any of my users seems tricky at best.
Security Code or Access scope is correct way to limit query execution.
Any client-related limitation can be abused in a simple REST call on REST help page or Postman.
1 Like
Olga, can you please explain more about that?
I assumed that the only way to set a security code was on-by-one on each BAQ (There are currently 763 system BAQs without security for my company).
This is the first I’m hearing about access scopes, but it sounds like I’d either grant a user full access to all BAQs or limited access to specified BAQs. If the system BAQs are controlling things like search boxes/tables, I’d still have to select from 763 system BAQs for each access scope i set up or risk locking users out of something they need. Is there something I’m misunderstanding, or a way to make that process easier?
No, I think you desribe it correctly.
Just my 2 cents, but for extra-sensitive information I would setup security at the field level if you really care, that’s the only real way to prevent access from everywhere at once…
1 Like
How would you describe the easier process?
The only thing I can think of (if not using Field Security) is to add to what Support told @jnbadger
First, determine which TABLES you are concerned with and assign a sensitivity number to them (zero to ten where ten is most sensitive)
GL*
AP*
EmpBasic,
Etc
- Add Ice.QueryTable to the BAQ above.
- Create a Calculated field that assigns the value from above.
- Add a SubQuery and include the above subquery
- Take the MAX of that value and use that in your Excel to assign a SECCode for the UDASH.
That should cut down on the effort of going into each query to identify sensitive information and assigning the SECCode.
Just a thought…