We are SaaS and just went live yesterday after upgrading to 2024.2.4. We are now seeing major problems in browser based Grids where you click on data in the grid and it switches the row on you. I am noticing that it happens most often if you have grid filters, or have grouped by a column, and are selecting rows not near the top. The biggest problems happen on updatable dashboards. Users are updating the incorrect rows.
The workaround I have found, is to click on the left of the row and select the entire row before then clicking into a cell in the grid.
I have a ticket in with Epicor that was converted to a problem, but am worried it will take a while for a fix. Does anyone have any other fixes?
I used a field linked to TransView to filter the grid and limit the dataset. The issue seems to go away if you donāt use the built in filters. Seems to be okay as a work around for now.
I have three related cases openā¦ they have confirmed itās an issue (it happens across all dashboards). Prompted them today on all 3 - they are 3 days out of getting back to meā¦ so they say.
Please put in a case ASAP. We are always ahead of the curve on these (reporting), but the more that get in the faster they realize this is a global problem (which it is).
Yeah i entered a case on the Work Queue a couple weeks ago, but didnāt realize it in dashboards till this morning. I escalated my original case. Then Support called me before doing that and said that they had gotten a lot of cases about this in the last couple days (not surprising), so it should be a higher priority.
They split my work Queue case into 2 cases, in case the dashboard was different and should possibly be handled by the customization team, but support also said it looked like it was all the same issue.
Iāve found that when I make a edit in an updatable dashboard without selecting the row first, it is actually updating 2 rows. it is updating the intended row and another.
Upon further testing, it isnāt really updating 2. My example is a checkbox. When i click into the checkbox on a filtered grid, if i am clicking in the 5th visible row, the checkbox of the 5th row of the unfiltered grid, is being checked. But that 5th visible row doesnāt show as checked for me on 1st click. So i click it again and then it is checked. When i hit save, both rows update.
So what is really happening is that 2nd click is in a selected row so it works as expected, but you have already checked a row that might not be visible.
Can confirm issues with the grids after the 2024.2.4 update. Seems they are totally broken across multiple apps. For us we are seeing it in PO approvals, material queue manager, and cycle count discrepancy reason codes apps. Here is are examples from cycle count and mtl queue manager
:
Worst thing about thisā¦ Epicor rated this/our tickets as MODERATE - Itās an Epic Dumpster Fireā¦ Every Dashboard/Landing Screen is affected by this and there are more than a few resultant, non-wanted behaviors happeningā¦
This is a thing Iāve been seeing progressively more often. The reason is that rows and even columns are clearly being tracked in code by position rather than a key or name value.
If you only have one grid, the key or name value follows the record, while the position can contain any record. If the grid remains static, relying on position can work out, but still adds pointless risk if a key or name reference can be used.
If you have multiple datasets (ie, the loaded data and the displayed data) or the grid isnāt static (sorting, filtering), the key or name value will always return the associated record if it exists in the displayed grid, else nothing. The important part is, thatās true even if you lose track of which grid youāre pointing to! Returning the position causes errors when code loses track of which grid to refer to, or fails to update when the grid is filtered, or when itās sorted, etc.
Thatās the cause of āout of indexā errors (the position doesnāt exist in the grid itās being applied to), the grid visually jumping around when you click on it (the selected position is applied to the wrong grid - causing the displayed grid to move to that position), values changing like this (the selected position retrieves the value present at that position from the wrong grid).
Weāre also seeing this. Nothing like trying to launch a new dashboard requested by your companyās president and it is largely unusableā¦ not to mention looking like an idiot developer in front of corporate ownership.
ā¦ not saying theyāre wrongā¦ but in THIS case, I canāt control whatās happening.
This issue is across all dashboardsā¦ this was a major QA Fail, IMHO. I also just uncovered a related sort issue with regard to draggin columns to make pivot tables in Dashboardsā¦ Long Story Shortā¦, it completely breaks and freezes everything. Sigh.
