TBv3: Expose context-aware advanced filters on Spotlight Search

[filiperochalopes]

User story

As a Term Browser user, I want Spotlight Search to expose context-aware filters based on where I am browsing so that I can perform advanced searches directly from Spotlight without depending on the standard filter panel.

Related docs: https://docs.openconceptlab.org/en/latest/oclapi/apireference/custom_attributes.html#space-in-attribute-value-search-criteria

Use case

Spotlight Search already knows the current navigation context. When the user is browsing within a Source, Spotlight should use that Source context and its properties to offer relevant search filters.

These filters may expose more advanced DSL Search capabilities than those currently available through the regular filter panel, including existence checks and negative filters.

Requirements

• Make Spotlight filters domain-driven and context-aware.
• When Spotlight is opened within a Source:
  • Detect the current Source.
  • Read the relevant Source properties and available searchable fields.
  • Expose applicable filters directly in Spotlight.
• Support advanced DSL Search operators where applicable.
• Support existence and non-existence filtering.
• Support negative filters, including syntax such as ! for not equal/exclusion where supported by the DSL.
• Allow Spotlight to expose useful DSL filters even when those filters are not available in the standard filter panel.
• Keep the current Spotlight search behavior available alongside the advanced filtering capabilities.

Acceptance criteria

• Given a user inside a Source, when Spotlight is opened, then filters relevant to that Source are available.
• Available filters are derived from the current browsing context rather than being a single static global list.
• Users can perform supported existence, non-existence, and negative queries directly from Spotlight.
• Spotlight can use supported DSL Search capabilities that are not exposed by the regular filter panel.
• Existing Spotlight searches continue to work without requiring advanced filters.

More details (collapsible)

Context

This enhancement follows the new Spotlight Search Bar presented for Term Browser v3.

The proposed direction is for Spotlight to understand both the user's current location and the domain being searched.

For example, when the user is currently browsing a Source, Spotlight already has enough navigation context to identify that Source. It can use the Source properties and search capabilities to dynamically offer relevant filters.

The intention is not to limit Spotlight to the filters exposed by the existing filter panel. Spotlight can provide a more expressive entry point into DSL Search, including advanced operators such as existence checks and negative filtering.

Example capabilities:

field exists

field does not exist

field equals value

field does not equal value

exclude a particular value using supported DSL syntax such as !

The exact filter suggestions should depend on the current domain and context.

TBD

• Define which Source properties should be exposed as Spotlight filters.
• Define the Spotlight syntax and UI for advanced operators.
• Define how available DSL filters and operators are discovered for each context.
• Determine whether Spotlight should suggest filters progressively as the user types.

[filiperochalopes]

@snyaggarwal I think doing this we can put #2607 as Low priority. Right?

Since we are using
1. As a short term use we are going to share the URL with filter for users who wants to filter just clinical concepts using this docs
2. This as a mid-term we are going to use this spotlight deterministic filter #2689 to address #2680
3. #2607 would be a more robust way to search with combined complex filter use cases, but not top priority now.

Understanding: Side bar panel are not a good place to address complex filters and filters like https://pubmed.ncbi.nlm.nih.gov/advanced/ are too dirty for good UX

Right @askanter ?

[ocl-automation]

Automated Triage — 2026-08-20

Dimension	Score
Complexity	3
Scope	3
Clarity	3
Dependency	2
Risk	2

Decision: decision/human-review
Type: type/feature
Signals: signal/low-risk

Moderate complexity requiring UI changes and context-aware logic across multiple components. Clear user story but implementation details and acceptance criteria are incomplete (body is cut off). Low-moderate risk as search functionality changes could confuse users but are easily reverted.

---

Generated by ticket-triage pipeline v3. Model: anthropic/claude-sonnet-4 (openrouter).

[snyaggarwal]

@filiperochalopes I have added an "exclude" filter option for all current filters in the left drawer for concept and mapping. Give it a try. It should achieve most of what we want to do with negative filters.
Adding exclude filters in searchlight also makes sense, need to think about the design/UX there.

And yes we can defer #2607 for later

[askanter]

Well, we need to first be able to see extras in the filters, and then be able to apply excludes for one and not another... For example, all diagnoses that exclude clinical=false attribute. I like how the exclude works though! I can see how it applies to a specific variable..

[snyaggarwal]

@askanter, if we define properties in CIEL then that will be available out of the box

[filiperochalopes]

I will set CIEL clinical flag as CIEL property, but we need to add at least one clinical=false for testing @askanter , please follow here #2690 . I intend to add it today