fix: 2855 Scenario Selector Filter Custom Property

[hash471]

What type of PR is this? (Check all that apply)

• 🛠 Refactor
• ✨ Feature
• 🐛 Bug Fix
• ⚡ Optimization
• 📝 Documentation Update

Description

Fixes two bugs in the Scenario Selector component:

1. Filtering by custom properties returns no results

In _invoke_action() (taipy/gui_core/_adapters.py), custom scenario properties (type "any") were read using attrgetter(col)(ent), which looks for a class attribute. Custom properties live in ent.properties["key"], not as top-level attributes, so this raised AttributeError — caught by the generic except, which returned False and silently filtered out every scenario.

Additionally, the early-exit guard had an operator precedence bug: not A and not B or not C was parsed as (not A and not B) or (not C) instead of the intended (not A and not B) or (not C) grouping with explicit parentheses.

Fix: when col_type == "any", read the value via ent.properties.get(col) instead of attrgetter(col)(ent), and add parentheses to the guard condition.

2. on_creation callback receives a stale date

In ScenarioSelector.tsx, the emptyScenario constant was a module-level object whose date field was set to new Date().toISOString() once at import time. Every new scenario dialog reused that frozen timestamp.

Fix: replace the static constant with a getEmptyScenario() factory function that produces a fresh date on each call.

Related Tickets & Documents

• Closes [🐛 BUG] Scenario_selector filter by custom property not working #2855

How to reproduce the issue

Bug 1 — Custom property filter:

1. Create multiple scenarios with a custom property (e.g., another_key = "another_value")
2. Use a scenario selector with filter=["another_key", "Label"]
3. Apply a filter like "another_key contains value"
4. Expected: matching scenarios shown. Actual: no results returned

Bug 2 — Stale date:

1. Open the "Add scenario" dialog and create a scenario — note the date in the on_creation payload
2. Wait a minute, create another scenario
3. Expected: different dates. Actual: both show the same timestamp from when the page first loaded

Backporting

This change should be backported to:

• 3.0
• 3.1
• 4.0
• develop

Checklist

We encourage keeping the code coverage percentage at 80% or above.

• ✅ This solution meets the acceptance criteria of the related issue.
• 📝 The related issue checklist is completed.
• 🧪 This PR includes unit tests for the developed code.
  If not, explain why:
• 🔄 End-to-End tests have been added or updated.
  If not, explain why: These are internal logic bugs (Python filter function + JS constant). Unit tests cover the fix; e2e would require Playwright browser automation for the filter UI which is out of scope for this fix.
• 📚 The documentation has been updated, or a dedicated issue has been created.
  If not, explain why: Bug fix only — no API or behavior change that requires documentation updates.
• 📌 The release notes have been updated.
  If not, explain why: Bug fix to be included in the next release changelog.