Perspective
Correct row and rowIndex values of the expand and collapse subview events initiated by the Table's script callable methods expandSubviews and collapseSubviews.
This change note appears on the 8.1.28 Release Notes, and I was unable to find any extra information on what the issue was.
We have used a couple of table subviews lately. My project team were not planning to upgrade to 8.1.28 at this time so I was hoping to get some extra info on what this bug was, and what version it first appeared, so I can look out for it.
Since the introduction of the ability to expand/collapse subviews in 8.1.17, the functions have incorrectly used the supplied values due to a miscommunication in terminology.
The term "indices" was often interchanged with the "id" of the row, whereas "id" means something completely different as far as the Table is concerned. As a result, some examples and quite a bit of internal testing revolved around supplying the 'id' of the row. It was recently discovered that the terminology had been mixed up and was the cause of several bugs users had encountered when attempting to expand or collapse their subviews based on the true indices of the table.
Starting in 8.1.28, we've reconciled all of the usages of the Table to correctly use the values supplied within the array as indices instead of ids. We did not adjust any arg names because they were technically correct - it was the backend usage of the supplied values which was wrong. As a result, your scripts should not break, however the rows displayed by your scripts could potentially no longer line up with expectations based on whether you're suppling the id of the row or the index.
In most scenarios, users won't even notice a change here. The most obvious scenario which would have been impacted would have been the following:
While Viewing a Table with 300 rows, and displaying only 25 rows per page, if a user is on page 3 (viewing rows 50-74) and attempts to expand the subview of row 20, swapping to page 1 would result in the subview of row 20 not being expanded because the supplied index wasn't visible. On the back-end, we had attempted to act on an index which the Table couldn't operate on (because it's dealing with 50-74). Now, the back-end correctly identifies the supplied value as being the id of the row within the data, and so when the Table switches pages the back-end data has been appropriately flagged as being expanded and the user sees that the subview for row 20 is expanded.
One thing not mentioned in the release notes but which was repaired as a result of these changes is that the onSubviewExpand and onSubviewCollapse were previously executing even if the subview was already expanded or collapsed. Users should notice no detrimental impact from this part of the fix.
1 Like
Makes sense, thanks for the detailed answer!