Thanks for checking further. We are temporarily converting some of our views to an SSRS report while we wait for this issue to be fixed. We went live with 10.2.600.8 this past weekend so no going back. Hopefully the fix is just a patch or two away from release.
I am pitching here something I thought could be a workaround … not knowing it can be done…but
If i launch my dashboard using an Ext-BAQ, via code from a UD screen , could we change the “active” user launching this menu item?
Like if user A has limited access, I do not want to give it security manager access… If this user launches my modified screen, could I mimic that the user is manager before calling the menu?
On the same note, instead of being a dashboard, would it have the same restrictions if it is transformed as a BAQ report ?
What I narrowed it down with @jgiese.wci (with @josecgomez supervising) is in 10.2.600.0 they had a method called “CanAccess” now its called “CanReadAccess” but it looks like in some places where they had “CanAccess” they are now looking for “CanModifyAccess”.
They all look like they are in good order, however I bet Epicor BO runs some of the other methods such as UpdateQuerySecurityFilters and so on, when merely executing the ExtBAQ and therefore it throws an error when used in a Dashboard etc…
Example the Method in the stack UpdateQuerySecurityFilters only required CanAccess, but NOW it looks for CanModifyAccess, like a few others and it triggers the exception.
The BAQDesigner BO adds also the following new classes:
I wonder if it knows how to distinguish from BAQ vs ExtBAQ. Perhaps the Row Level Security silently breaks during Runtime.
In that case they are calling UpdateQuerySecurityFilters method for BAQ and ExtBAQ, and then that calls the ExtBAQ one… note the CanModifyAccess addition, that should probably be CanReadAccess from what I can read, it just sets security filters on your query… not sure why one would need modify access to mess with tmp this method may be the culprit hm (CanModifyAccess checks for Author)
I probably wont be the long term maintainer for this. You know how that usually turns out though. I didn’t work closely with Dmitry, but I will miss him.
@JeffLeBert let’s assume you get to work on this next Sprint (assuming you will get the ticket), and assuming its a simple fix… would it make it into the next build or is your lag time 4-6 weeks? 2-3 builds out? Just wondering, since we have an upgrade this month, if we need to push out by 2-4 weeks.
I guess what I am asking when Epicor DEV gets a ticket, and fixes it, does it get pushed out a few patches?
This is on my list for this sprint (started sprint today). I’m not sure what the lag time is between when I’m “done” and we actually send it out. My goal is to get things done inside one sprint. I don’t have any pull outside of that. I know I have to do this and get it tested in current code before I can move it back into previous releases.
So it is always hard from dev to follow when things make it out into the wild but I can say the current sprint 2019 - any 10.2.600 fixes will go into 10.2.600.13. Assume I’m reading the list right I would expect that to be release sometime in early october
However our standard is to fix issues in vNext, test and confirm the fix, then apply it to an update. If for some reason it takes a significant amount of time to track this down and fix it could wind up going out in 10.2.600.14 - which would follow roughly 2 weeks after .13 assuming the scheduled customer delivery stays on pace.
All that said - lets let Jeff track down and fix it
Oh and as for Dmitry we will miss him, he worked at Epicor a very long time and shepherded BAQs as you all know a core component of all modifications customers make to the system very well. He is quite happy with his new opportunity that he sought out on his own and looking forward to the opportunity. I personally am very sad to see him go but he is likely to have a great time in his new role and should he not I’d be perfectly happy to welcome him back!
@hkeric.wci - thanks for not giving up on this issue and tracing it further. I was not pleased to see support was telling you this is not a critical issue. Good thing you don’t give up easily even if we all have to wait a bit longer than what I hoped for a fix. Thanks to @jgiese.wci and @josecgomez as well.
BAQ Views are ready to use in 600. You just need a bit of magic to make them visible to BAQ Designer. I’ve sent instructions to Rich and Steve some time ago.