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.
this method may be the culprit hm (CanModifyAccess checks for Author)
(wait but who will fix Task Agent thenā¦)
