Is there any way to prevent grid data from automatically loading when dashboards are launched? I have many dashboards displaying panel card grids attached to BAQ’s. Some of these BAQ’s return hundreds of thousands of rows, causing the dashboards to be extremely slow after launching. In Classic this wasn’t a problem, grids wouldn’t load unless the user manually refreshed them after entering additional filters (or none at all, causing one of these large queries).
It would be great if the cards stayed expanded at launch (without data loaded) so that users can see what data columns are expected from the query before they select/enter filters. Only would a filter action (tab out of text box, select a date, combo box, etc.) or manual grid-refresh cause the query to fire.
There’s some “hacky” solutions in this post, just looking to see if there’s been any more user friendly options discovered within the last year.
I THINK a BAQ grid (BAQ set in the provider model) will run the BAQ when the grid is painted.
If you switch those over to dataview driven grids (where the DataView is populated by a BAQ), those dataviews should load empty. They won’t get populated until you call the respective events to run the BAQs.
Thank you for the suggestion David! This works great. Now I’m trying to implement the same filters as before (using the WHERE List clauses I had set up for the previous ‘BAQ Grid’). Now that I’m populating the DataView/grid separately using rest-erp, being limited to the single “Where” textbox in BAQ Execute Options is becoming tricky.
I have 2 date picker controls to filter the grid by JobHead_ReqDueDate. The clause I’m currently using is JobHead_ReqDueDate BETWEEN {TransView.FromDate} AND {TransView.ToDate}.
When my event fires with no dates selected, I get this parsing error in the debug console:
Now after selecting a date range:
I’ve tried adding single quotes for ‘{TransView.FromDate}’ and ‘{TransView.ToDate}’ without success (along with other random syntax changes to see if I could get it working).
Any idea how I can get these date filters to parse correctly? I can understand the dates being undefined on initial load, but still getting this error after selecting a date range has stumped me.
EDIT: Got this working only when two dates are selected by just using JobHead_ReqDueDate >= {TransView.FromDate} AND JobHead_ReqDueDate <= {TransView.ToDate}
While this is great, it seems like I would need to add multiple condition widgets on my event to check if these TransView values are set, and if not, set them with row-update? For example, if a “From Date” is chosen but not a “To Date”, the BAQ should run from that From Date to today. Currently, since the TransView.ToDate doesn’t get updated unless a To Date is picked, the query returns No Records as it remains ‘undefined’ in the Where clause.
This seems like I’d need some pretty beefy events with condition widgets if I had other additional filters (textbox searches, combo box dropdowns, etc.) to ensure these also aren’t undefined when erp-baq is executed with the singular WHERE clause..
You can try to add empty values in your condition by adding OR statements to both sides. I don’t have a good BAQ to test this against… but I’m thinking something like:
({TransView.FromDate} IS NULL OR JobHead_ReqDueDate >= {TransView.FromDate}) AND ({TransView.ToDate} IS NULL OR JobHead_ReqDueDate <= {TransView.ToDate})
So, for example, if the FromDate is 7/1/2025 AND ToDate is null… it should hopefully still work and it will open up the right-hand-side of the range.
Not sure if what I have above is exactly correct… but perhaps worth testing things of that nature.
When the dates aren’t selected, they are parsed as undefined rather than a database NULL or valid date literal, causing this Where clause (and all others I’ve tried) to fail.
An alternative solution I’ve tried and have (somewhat) working is manually setting the ‘Baq ID’ on the Provider Model of the grid within my event using property-set. This allows me to use the Where List (rather than being forced to a single Where Clause) making it much easier to uplift Classic dashboards that have multiple filter controls for a single BAQ Grid. The only issue I’m having is the empty Panel Card Grid must be closed and re-opened for the actual data to appear on screen. After being re-opened, everything works as intended.
I thought throwing a simple grid-refresh following the property-set in my event would do the trick-- nope. The only action I’ve taken to get the grid to display the BAQ query data is to manually close and re-open the panel.
Both actions run successfully when the event fires:
Using property-set to open/close a Panel Card Grid with the ‘expanded’ property doesn’t work unfortunately, so now I’m going to rebuild and test this solution using a standard Grid opposed to a Panel Card. Thank you for your assistance so far, David!
Could you initialize the date fields to today’s date? Or try adding the columns explicitly to TransView so they may return null or empty rather than undefined.
Was in the middle of testing this when my CTL+ALT+L debug shortcut stopped working.. This happened to me when using Edge a few days ago so I switched to Firefox with no issues until today.
I’ve restarted, cleared cache and used private tabs on both browsers with no success. All other shortcuts seem to work fine, any ideas?
I’ve ran into an issue with CTL+ALT+L not working to view component models when debugging. Is this something you’ve experienced before? Firefox worked for me when it randomly stopped working in Edge, but now I’m in the same boat with Firefox
For me, it’s consistently been another app grabbing the ctrl-alt-l shortcut, I think Microsoft Microsoft PowerToys did it once (they added a super cool interface to tell you about hotkeys conflicting)
AMD Radeon tools did it once too. You could try something like booting into safe mode, see if the shortcut works there. If it does there’s a conflicting app overriding the hotkey.
As long as I click on Kinetic screen then in debug mode (CTRL+ALT+8) then CTRL+ATL+L works. If not, then its a conflicting app or add-in as Gabe mentioned
You’re using a date range to pass to your where clause… this clause works as long as the dates aren’t blank/null/undefined. So… pre-set the default bounds.
Add an event (after Form_onLoad) and row update:
TransView.FromDate: set expression to “1900-01-01T00:00:00”
TransView.ToDate: set value (json) to “{Constant.Today}”
This pre-sets the bounds of your Where clause. If they don’t SET the FromDate, you’re still going to pass a valid date of 1/1/1900.
If they don’t set the To Date… you’re still going to pass today’s date (which should be the most up-to-date records you have).
Then your original Where expression of… JobHead_ReqDueDate >= {TransView.FromDate} AND JobHead_ReqDueDate <= {TransView.ToDate}
My go-to is passing parameters to the BAQ instead of where clause. You basically setup the parameters in your BAQ with all the filtering logic there, then in your dashboard you just have to send the parameter with the baq widget.
I’m just so effing tired of the syntax guess work in Kinetic, I just ship all the logic in the baq… i guess that’s what Epicor wants anyway
This approach works great-- I’m just not sure how to implement the other filter controls without adding a ton of messy conditional statements to the erp-baq event. For instance, if I have a text box to allow the user to filter by Resource ID. If they refresh the grid without anything entered in the text box, the Where Clause will fail as TransView.ResourceID is undefined. I’m unable to initialize TransView.ResourceID to anything that would allow the user to view all Resource ID’s for the selected date range.
I assume this would be just as tricky with combo boxes, radio buttons and other filter controls-- how would these filters be ignored in the single Where Clause if the user decided not to use them?
I can only think to use conditional blocks in my refresh_onClick event, with different erp-baq widgets setup with different Where Clauses to reflect the filters that were actually used (using Boolean values in TransView to detect which filter controls were modified by the user, and firing the right erp-baq call accordingly)
The syntax guess work hasn’t been my favorite.. Been determined to avoid modifying the BAQ’s themselves but that’d certainly make filtering much easier for those that return large queries.
