angular-ui/ui-grid

Filtering a row does not deselect it

Open

#5,170 opened on Feb 26, 2016

View on GitHub
 (4 comments) (1 reaction) (0 assignees)JavaScript (5,395 stars) (2,496 forks)batch import
help wantedtype: enhancement

Description

If you select a row, then filter it out, the row remains selected. Not sure if this is actually a bug, but it does not seem to be intuitive default behaviour.

For example, you select a number of rows, then set a field which causes them to be filtered. Then, later you select some other rows, and delete them. This will also delete the non visible rows.

This has the added effect of making getSelectedRows() unusable when using filtering, instead you must use getSelectedGridRows(), and filter out the visible rows, then map to a list of entities.

In my current project I have added a row processor to remove selections when rows become non-visible. I suggest this should be default behaviour, or have some additional documentation.

Contributor guide

Tech stack
javascriptangular
Domain
frontend
Issue type
bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
half day
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
basic Angular knowledgeunderstanding of ui grid selection API
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
30
Research direction
Investigate the interaction between row selection and filtering. Look at the selection service (likely GridSelection.js) and the filter service. Determine how row visibility changes and how selection state persists. Consider implementing deselection of non visible rows upon filtering, or adding documentation warning about the behavior. Note: The issue is from 2016 with no recent activity; maintainer input on preferred approach would be helpful.