Skip to Main Content
Feature Request FR-3800
Product Area Page Components
Status DELIVERED

31 Voters

Popup LOV Filter Option Value% Vs %Value%

jon dixon Public · May 18 2024

Idea Summary
Currently, when filtering a Popup LOV, the default is to search across the entire field. If you have values 000123 and 123000 and start typing 000, both values will be included in the filter result. While in many cases, this is preferred, in many other use cases, it is preferable to have a value% filter rather than a %value% filter.

Use Case
In situations where end users typically know the value they want to enter (e.g., when entering financial account values, project numbers, cost center numbers, etc.), it is much faster for them to enter the values if the filter works from left to right, i.e., value %. This can also improve performance, as the value% filter will use indexes. I have encountered this requirement with several customers where the input speed is essential for end users.

Preferred Solution (Optional)
Ideally, there would be a declarative selector for Popup LOV page items, where you can select the filter style as value% or %value%. As a bonus, it would be nice to also have an option to decide if the filter should ignore the case of the entered filter criteria.

This has been delivered in Oracle APEX 24.2!

Comments

Comments

  • juancarlos OP 2.3 years ago

    Perfect.

  • divisi0n OP 2.3 years ago

    Not in the field settings, but in the LOV column settings (search => yes (Value%), yes (%value%), no) instead of a checkbox.

  • carlos.ramirez OP 2.3 years ago

    Additionally, it would be great if the search could update dynamically as one types in the box, ensuring a dynamic display of search results.

  • vincent morneau Admin OP 2.2 years ago

    Hi @jon dixon 

    With APEX 24.1 out, I'd like to circle back to this idea. Now that APEX has Combobox, Select One and Select Many, and they all support an attribute called “Match Type” 

    Do you think that fulfills your requirement if you were to switch your Popup LOV item to one of those new components?

  • jon dixon OP 2.2 years ago

    Hi Vincent,

    Select One with the ability to return the ID, search by the Value, and display anything you want on the drop-down list is perfect. Add to that the fact that it also defaults the value if you tab out and only have one value in the list and you have the perfect Item Type. Wow!

    It would still be nice to have Match Type on the Popup LOV :)

  • juancarlos OP 7 days ago

    Extend "Tokenize Row Search" to List of Values (Popup LOV, Select One/Many, Combobox)

    I'd like to add support for this request, and also flag a real regression that makes it more urgent than a "nice to have."

    Up to 24.1, the Popup LOV search field let users type % and have it behave as a genuine LIKE wildcard. Our users relied on this heavily and deliberately — not randomly — to search for several substrings within a single entry, e.g. typing A%B%C to find rows containing A, then B, then C. It was a fast, powerful, muscle-memory way to narrow long lists.

    In 26.1 the unified LOV search escapes % and _ as literal characters. I understand the reasoning (consistency across Select One/Many, Combobox, and Popup LOV, plus the new Match Type and Case Sensitive attributes), and those are welcome additions. The problem is that a very useful capability was removed outright, with no equivalent replacement and no opt-out: Match Type = Contains only performs a single contiguous substring match, so it cannot reproduce the multi-token / ordered-wildcard search users had before. There is no bind for the search term either, so recovering the old behaviour requires per-item plugins and hand-written predicates across, in our case, hundreds of LOVs.

    This is the part I'd respectfully push back on: an upgrade shouldn't quietly drop a feature that many users depend on unless it's replaced by something at least as capable, or left behind a compatibility toggle. Right now it's a step backwards for LOV search ergonomics.

    The good news is that APEX already has the right building block — the Tokenize Row Search parameter used by Interactive Reports and Interactive Grids does almost exactly what our users want, splitting the entered text into tokens and AND-ing the matches. It feels like the feature was left half-finished: it never made it to LOV components.

    So my concrete proposal is to extend the existing Tokenize Row Search parameter (plus Case Sensitive / Match Type) to the LOV item types — Popup LOV, Select One and Many, and Combobox. That would:

    • restore, in a modern and declarative form, the multi-substring search users lost;
    • keep behaviour consistent with IR/IG, which is the direction APEX is already evolving in;
    • avoid forcing plugins and bespoke SQL across large applications.

    Ideally, please also consider exposing the raw search term as a bind (e.g. for Function-Returning-SQL LOVs) so advanced cases can build custom predicates, and/or a compatibility option for teams that need the previous wildcard behaviour during migration.

    Thanks to the team for the ongoing work on LOVs — the new attributes are genuinely useful. I'd just like to see this gap closed so the upgrade is purely additive rather than a loss of an everyday capability our users valued.