ANNOUNCING NEW FEATURE!
So… there have been many discussions about improving BAQ Speed, especially in instances where the QUERY involves Customers. You see… due to some security-minded people, we added some strong capability to intentionally hide certain types of records from people who are sales persons… the system will automatically filter out all orders/quotes/customers that are NOT in the sales persons territory. BUT this extra security comes at a cost.
In Kinetic 2024.2, we added a feature to help speed up queries for people who are NOT in a sales team and who want better performance. This could also include companies where you DO have sales teams, but you dont care if everyone can see everyone elses customers/orders/quotes.
The new feature is activated on a USER level… you can simply include a user into the “BAQ Territory Security Exempt” group. When this happens, then the BAQ system does NOT add the extra filters to your queries that hides records. This can significantly improve the speed of your queries.
(Yet another reason to upgrade)
Is there any plans to put this on a BAQ setting? For us, most of the time it’s more related to what the BAQ is doing rather than the person. Although I could see both options being helpful in different scenarios.
It’s good to see this, but not as another kind of hardcoded security. This isn’t consistent with Epicor’s established security management, and breaks our ability to consistently maintain or audit our own security.
This isn’t like “security manager” - that’s definitely a distinct role and a checkbox on the user’s account is appropriate. This new one associates to the activities of a user’s role, and that needs to be managed at the role level, which is the job of security groups.
That said, at least it’s not another hardcoded security group (rant deleted)…
Actually, Epicor changed its direction a few years ago, and we added the concept of specitaly security groups that are created and distributed by Epicor. These security groups are typically single funciton security groups, and act much like the “checkbox” concept that we used to use. The differece is that we dont have to add a new field to the user security table every time we want to add a new security feature. Instead we add a new special security group. Here are examples of what is currently in 2024.2 (or coming in 2025.1) Note that each of these is a single purpose security group and we have “hard coded” the functionality within each of those apps to look for this security group to be applied to the user. For example, in order to develop External BAQs (which are now done in the regular BAQ editor), you must be in the external BAQ Designer group. Same goes for Functions developer.
They’re a redundant layer on top of granting access to a single thing directly to single users, identical in practice to granting menu access directly instead of through a role map. In the case of system groups, they also aren’t compatible with and don’t work like established security groups; they aren’t security groups and shouldn’t be there.
I understand why some of them are necessary though. Client managed security only controls navigation. ‘External BAQ’ for example, has no menu navigation path that clients can control. Directly securing a process with the current system requires a security variance.
Between user account maintenance and system group workarounds, we’ve accumulated over 30 discrete embedded security workarounds. It might be time to update security management.
This will be a nice feature for us because we have never been worried about territory security and have allowed all salespeople to view all territories so the BAQ logic was just extra and unnecessary for us. Thanks!