Issue 45551: Request for option/flag to clear row selections upon request success

issues
Status:closed
Assigned To:Guest
Type:Feature Request
Area: 
Priority:3
Milestone:22.07
Opened:2022-05-24 13:53 by mohara
Changed:2022-06-27 09:58 by mohara
Resolved:2022-06-27 09:56 by hannahb
Resolution:Won't Fix
Related:42307
Support Ticket: 
Pull Requests:
Closed:2022-06-27 09:58 by mohara
2022-05-24 13:53 mohara
Title»Request for option/flag to clear row selections upon request success
Assigned To»triage
Notify»Keith
Type»Feature Request
Priority»3
Milestone»22.07
Related»42307
The related ticket has 2 comments.

Client would like support for being able to clear selected rows upon completion of some action. The use case is related to clearing selections after a success action, where those selected rows still exist, but are no longer shown by current filtering. Another example of how this "sticky" selection of rows impacts the client is when you are completing different actions on the same data in different browser windows, you can quite easily end up acting on 'stale' row selections.

The request is for either changing the default 'clear selections after action' behavior (which would likely impact others currently expecting the previous "sticky" selections) or ability to control the behavior with a flag like "clearSelectionOnRequestSuccess"

And if that is added, it's possible that "clearSelectionOnRequestFailure" and/or "clearSelectionAfterRequest" in general would be appropriate.

2022-06-06 14:12 hannahb
Assigned Totriage»xyang
NotifyKeith»Keith;adam;jeckels
Adding a flag (rather than changing the default) seems appropriate - assigning to Xing maybe as Data region owner (?) for estimation.

Please let me know if there are other complications or concerns about having a flag like this.

2022-06-06 14:39 jeckels
As noted in the related ticket, we already have this flag in DataRegionSelection, which I believe is what Ben is requesting. It defaults to clearing the selection. Thus, I don't think there's anything to do for the issue as requested here. Xing, please take a quick look and see if I'm missing anything.

We could separately alter the code that's retrying pipeline jobs to be more aggressive at clearing the selection. Maybe it should clear the jobs that were retried successfully, leaving any unhandled jobs selected?

The ticket then diverged into a discussion on tracking selection on a per-browser tab basis instead of for the whole user session.

2022-06-06 15:24 xyang
Assigned Toxyang»triage
NotifyKeith;adam;jeckels»Keith;adam;jeckels;xyang
I agree with Josh's assessment
- that such flag already exist, and we are using different flag value per different actions.
- that we would just work on pipeline reset action to clear selection. I don't know how feasible it is for the region to remove only successful run selections. Even though a run might finish fast, it's probably still in a background job and not synchronous. Removing all selection regardless of run status seems more realistic to me.

BUT, looking at the code, RetryStatusAction already clear all the dataregion selections, see DataRegionSelection.clearAll(getViewContext()). The key step to repro the client's scenario is "If you do this too quickly"... So if I understand this correctly, this is a race condition that the client is describing. Tab 1 selects A, tab 1 hits "Retry", tab 2 selects B, tab 2 hits "Retry" (both A and B are retried, B is selected from current form checkbox, A is from session), tab 1 finished retry and clear selection. Those type of scenarios with accessing a shared resource are common with a multi user setup. And the correct behavior is what we are currently doing: show error to tab 2 "hey, A cannot be retried...".

If we care enough to modify pipeline grid, perhaps we can force the retry action to only fetch from from checkbox, but don't look at session. I estimate that to be 1-3 hours.

2022-06-06 15:36 jeckels
I'd suggest that we shouldn't special-case this grid to only use the selection from the current page. While users may not already like either selection approach, it's even harder to explain how things work when it's unpredictable.

Note that the clearing of the selection only happens if all of the jobs can retry. If we make any change, I recommend clearing individual job selection as they successfully retry instead of clearing all or nothing at the end.

2022-06-27 09:56 hannahb
resolve as Won't Fix
Statusopen»resolved
Assigned Totriage»mohara
Resolving this as Won't Fix given the comments

2022-06-27 09:58 mohara
close
Statusresolved»closed
Assigned Tomohara»Guest