[BUGFIX] Show the "deactivate current filter" button with the form filter - #7052
Open
nboisteault wants to merge 1 commit into
Open
[BUGFIX] Show the "deactivate current filter" button with the form filter#7052nboisteault wants to merge 1 commit into
nboisteault wants to merge 1 commit into
Conversation
…lter The `#layerActionUnfilter` button in the layer switcher was only toggled by the "full" filtering path (attributeTable.js), which builds the filter from a list of feature ids. The form filter panel defaults to the "simple" method (see `getFilterMethod()`), which applies a WMS/WFS expression filter through `lizMap.triggerLayerFilter()` / `lizMap.deactivateMaplayerFilter()` and never updated `lizmapLayerFilterActive` nor the button. Update the button state in the two "simple" branches of filter.js only. The low-level map.js helpers are deliberately left untouched because timemanager.js calls them on every time step, which would make the button flicker. Clicking the button already worked once visible: it triggers `layerfeatureremovefilter`, which attributeTable.js uses to clear the map filter and filter.js uses to reset the form fields. Fix 3liz#6775 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Fixes #6775.
The "Deactivate current filter" button (
#layerActionUnfilter, in the layer switcher dock) does not show up when the filter is applied from the form filter panel, while it does show up when the filter comes from the attribute table or the selection.Root cause
The button's visibility is driven solely by the
lizMap.lizmapLayerFilterActiveglobal, and it was toggled in a single place:attributeTable.js(updateLayer()). That code is only reached by the "full" filtering path, which builds the filter from a list of feature ids.The form filter panel picks its method in
getFilterMethod()(filter.js): it defaults to "simple", and only uses "full" when the layer has an attribute table config with a single-column primary key. The "simple" path applies a WMS/WFS expression filter vializMap.triggerLayerFilter()/lizMap.deactivateMaplayerFilter()(map.js), which never touchedlizmapLayerFilterActivenor the button.Fix
The button state is now updated in the two
'simple'branches offilter.js.The low-level
map.jshelpers are deliberately left untouched:timemanager.jscallstriggerLayerFilter()on every time step, so updating the button there would make it flicker while the Time Manager plays.Nothing else was needed — clicking the button already worked once visible: it triggers
layerfeatureremovefilter, whichattributeTable.jsalready handles to clear the map filter (exp_filter/filtertoken/filter+expressionFilter) andfilter.jsalready handles to reset the form fields.Test
Added a Playwright test in
form-filter.spec.js.The existing
form_filterfixture has single-column primary keys on both layers, sogetFilterMethod()always resolves to"full"there — which is why the existing tests never covered this. The new test forces the"simple"path withfilterConfigData.filterMethod = 'simple', the extension point already documented infilter.jsfor project custom scripts, so the existing tests on that fixture keep exercising"full"unchanged.Verified locally: the new test fails on
expect(unfilterButton).toBeVisible()without the fix, and passes with it.Note:
Form filter with comboboxfails on my local stack because of an echo-proxy setup issue ingetEchoRequestParams; it fails identically on a cleanmaster, so it is unrelated to this change.🤖 Generated with Claude Code