[BUGFIX] Time manager: keep the filter already set on the layer

[nboisteault]

Problem

Fixes #6773.

When a controlled layer already has a filter — typically set from the form filter — the time manager and that filter do not compose: the date range never restricts the features that the layer filter selected.

Root cause

setLayersFilter() passed only its own date filter:

filter = buildDateFilter(config.timemanagerLayers[l], lowerBoundary, upperBoundary);
lizMap.triggerLayerFilter(l, filter);

lizMap.triggerLayerFilter() replaces request_params.exp_filter on the layer, so the filter already applied was dropped at the first date step. Symmetrically, closing the time manager called deactivateMaplayerFilter(), wiping the layer filter along with the date one.

Reproduced with a form filter keeping gid <= 2: the GETFILTERTOKEN sent when opening the time manager contained only "test_date" conditions, the "gid" condition was gone.

Fix

The filter each controlled layer has when the time manager is opened is captured in tmBaseFilters and combined with the date filter of every step. Closing the time manager restores that filter instead of clearing the layer, so only the date part is removed.

When the layer had no filter, the filter string is byte-for-byte unchanged, which keeps the existing (quite precise) GETFILTERTOKEN assertions in time-manager.spec.js and time-manager-years.spec.js valid.

Known limitation: the base filter is captured when the time manager is opened, so changing the form filter while the time manager is running is not picked up until it is reopened. Handling that properly needs the layer filters to be tracked per origin rather than as a single exp_filter string, which is a larger change.

Test

Added a test in time-manager.spec.js: it filters the layer with the form filter, then asserts the time manager's GETFILTERTOKEN carries both the "gid" and the "test_date" conditions, and that closing the time manager restores the "gid" condition alone.

The time_manager test project had formFilterLayers: {}, so no layer filter could coexist with the date filter; a numeric form filter on gid is added to the fixture.

Verified locally: without the fix the test fails on the "gid" assertion (the filter contains only "test_date"), and passes with it.

Unrelated pre-existing local failures, identical on a clean master on my QGIS 3.44 stack: Manual play, Let's play and Auto play uses full ISO dates in filter (my stack resolves the time frame type to months, showing January 2007 where the tests expect 2007).

🤖 Generated with Claude Code

[meyerlor]

Hey @nboisteault, that is almost the same fix I did in #6847, and it's basically the same tmBaseFilters capture/combine/restore shape, so nice that we (or our Claudes 😄 )landed on the same idea. Your Playwright test + gid fixture are a solid addition mine didn't have.

One thing before it lands: this captures the base filter from exp_filter only. That covers the form filter panel, but the attribute-table filter tool stores its filter inrequest_params['filter'] instead (see getDataAndFillAttributeTable, request_params['filter'] = filter), not exp_filter — so a filter set from the attribute table gets dropped again once the time manager kicks in. In #6847 I read request_params['filter'] first (stripping the wmsName: prefix) and fall back to exp_filter, which handles both origins. Happy to fold that into this PR if useful.

Bigger picture though, this is exactly the mess I flagged in #6876: request_params.filter vs exp_filter, no ownership metadata, every tool guessing what was already there. This PR is a fine as a tactical fix — I'd just keep the per-layer FilterState idea from #6876 as the real target and treat the filter-key case as the one gap to close here - what do you think?