`sap.m.SelectDialog` with OData V4 + `$apply groupby` selects wrong item after search/filter

[evapoorada]

What is the issue and how can we reproduce it?

Bug Report: sap.m.SelectDialog with OData V4 + $apply groupby returns wrong item via selectedContexts after search/filter

Description

When using sap.m.SelectDialog bound to an OData V4 model with
$apply: 'groupby((PropertyName))' in the binding parameters, filtering
the dialog via the search field and then selecting an item causes
selectedContexts to return the wrong binding context.

The returned context path (e.g. /EntitySet/0) corresponds to the item
at that index in the original unfiltered collection, NOT the item at
that index in the filtered results. This means the confirmed item is
completely different from what the user selected.

---

Steps to Reproduce

1. Bind a SelectDialog to an OData V4 model using $apply groupby:

<SelectDialog
    multiSelect="true"
    items="{
        path: '/EntitySet',
        parameters: {
            $apply: 'groupby((SomeProperty))'
        }
    }"
    search=".onSearch"
    liveChange=".onSearch"
    confirm=".onConfirm"
    rememberSelections="true">
    <StandardListItem title="{SomeProperty}" type="Active" />
</SelectDialog>

2. Search/filter handler:

onSearch: function (oEvt) {
    var sValue = oEvt.getParameter("value");
    var oFilter = sValue
        ? new Filter("SomeProperty", FilterOperator.Contains, sValue)
        : [];
    oEvt.getParameter("itemsBinding").filter(oFilter);
},

onConfirm: function (oEvt) {
    var aContexts = oEvt.getParameter("selectedContexts");
    aContexts.forEach(function(oCtx) {
        // oCtx.sPath is e.g. "/EntitySet/0"
        // but /0 is the first item of the ORIGINAL unfiltered list,
        // NOT the first item of the filtered results!
        console.log(oCtx.sPath);       // "/EntitySet/0"  ← WRONG index
        console.log(oCtx.getObject()); // returns wrong item
    });
}

3. Open the dialog.
4. Type in the search field so only 1 or a few results remain visible.
5. Select the visible item (e.g. the first and only result after filtering).
6. Confirm the dialog.

---

Expected Behavior

selectedContexts should return the context of the actually selected
visible item after filtering — for example, if the user selected the
only visible result after filtering, the context should point to that
specific entity, regardless of its position in the original unfiltered
collection.

---

Actual Behavior

selectedContexts returns a context whose sPath is re-indexed based
on the filtered result position (e.g. /EntitySet/0 because it is
the first visible item after filtering), but the OData V4 model resolves
/EntitySet/0 against the original unfiltered collection — returning
the first item of the full dataset instead of the selected filtered item.

Concrete example:

Position in original list	Value
/EntitySet/0	Alice
/EntitySet/1	Bob
/EntitySet/2	Charlie

User searches for Charlie → only Charlie is visible (position 0 in filtered view).
User selects Charlie.
selectedContexts[0].sPath → /EntitySet/0
selectedContexts[0].getObject().SomeProperty → "Alice" ❌ (wrong!)

---

Root Cause

$apply: 'groupby(...)' on an OData V4 binding produces aggregated
contexts. When SelectDialog applies an additional client-side search
filter on top, the visible items are re-indexed starting from 0. The
context paths returned in selectedContexts reflect this re-indexed
position, but the OData V4 model resolves them against the full original
dataset — causing an index mismatch and returning the wrong entity.

---

Workaround

Fetch data manually via requestContexts(), deduplicate in the
controller, and bind the dialog to a local JSONModel instead:

onOpenDialog: function () {
    var oListBinding = this.getView().getModel().bindList("/EntitySet");
    oListBinding.requestContexts(0, Infinity).then(function (aContexts) {
        var aSeen = new Set();
        var aUnique = [];
        aContexts.forEach(function (oCtx) {
            var sVal = oCtx.getObject().SomeProperty;
            if (!aSeen.has(sVal)) {
                aSeen.add(sVal);
                aUnique.push({ SomeProperty: sVal });
            }
        });
        var oLocalModel = new JSONModel({ items: aUnique });
        this._oDialog.setModel(oLocalModel, "localModel");
        this._oDialog.open();
    }.bind(this));
},

onConfirm: function (oEvt) {
    // Now works correctly — JSONModel paths are stable
    var aContexts = oEvt.getParameter("selectedContexts");
    aContexts.forEach(function (oCtx) {
        console.log(oCtx.getObject().SomeProperty); // ✅ correct item
    });
}

---

Environment

SAPUI5 Version	1.140.0
OData Version	V4
Browser	Chrome 145
OS	Windows 11

Which OpenUI5 version is your project targeting?

1.140.0

Is the issue device- or browser-specific?

No

Confirmation

• I have searched the existing issues and reviewed the relevant documentation as well as the API reference.
• I am not disclosing any internal or sensitive information.

[MapTo0]

Hey @evapoorada

Could you please confirm that the reported behaviour is reproducible in the following example: https://jsbin.com/tejotohazi/edit?html,console,output

Best Regards!
Martin

[ThomasChadzelek]

When you show a path like "/EntitySet/0", that looks to me like "SomeProperty" is not the (only) key property of that entity. Wouldn't it be better to use context paths with key predicates instead of indices? It should happen automagically once all key properties are available. Indices inside a path are kind of legacy today ;-)

Note: Once you use "groupby", that's kind of like $select: only properties listed therein are available!

[ThomasChadzelek]

Could you please confirm that the reported behaviour is reproducible in the following example: https://jsbin.com/tejotohazi/edit?html,console,output

Well, if I follow that link, it looks very much like a V2 model being used there. Are you sure this is what you would like to demonstrate?

[evapoorada]

Hey @MapTo0,

Not exactly. The example you shared uses an OData V2 model, but the issue I reported is specific to OData V4 with $apply groupby.

V2 cannot reproduce this bug because $apply doesn't exist in V2. Every entity returned by V2 always includes its key properties, so the binding always generates stable key-based context paths like /Customers('ALFKI'). The positional fallback /Customers/0 only happens in V4 when the response is missing key properties, which is exactly the case with $apply groupby, since groupby behaves like $select and only returns the properties you explicitly list.

I put together a JSBin that reproduces the issue using V4: https://jsbin.com/pipevufuno/3/edit?html,console,output

Steps to reproduce:

1. Open the Bug dialog
2. Search for "Bar"
3. Select the only visible result
4. Confirm -> the wrong item is returned

The root cause is that ODataListBinding falls back to positional indexing (/EntitySet/0) when key properties are absent from the response. When SelectDialog clears the search filter on close, the binding resets and those positional paths re-resolve against the original unfiltered list returning the wrong entity.

Best regards,
Eva

[evapoorada]

@ThomasChadzelek Thanks for the clarification! I think that makes sense, groupby only returning listed properties means the key is absent from the response, so the binding falls back to positional indexing.
However in our use case, adding the key to groupby defeats the purpose since we're using it specifically to get distinct values of a single property. Including the key would make every row unique again and eliminate the deduplication.
So I guess the question becomes: should ODataListBinding handle this case by constructing a synthetic stable predicate from the grouped property values themselves, since by definition they are unique in a groupby result? Or should SelectDialog not rely on context paths surviving a filter reset?

[ThomasChadzelek]

Or should SelectDialog not rely on context paths surviving a filter reset?

Well, if it would boil down to this simple question (and I'm not yet sure it does) I would fully agree. One should not rely on certain context paths or instances surviving a (filter) reset.

Q: Why would one do that in the first place?
A: OK, I could imagine this is about a "browse & collect" pattern being implemented here. Not sure if rememberSelections makes any difference here?

[ThomasChadzelek]

When SelectDialog clears the search filter on close, the binding resets

That sounds like the root cause to me. I understand that at some point you might need to reset the search filter when you are about to reuse a select dialog. But if you do that "on close" and the binding resets, how can we be sure we don't trigger yet another GET request to the backend, which would be a total waste? Also, it seems to defeat the very purpose of a select dialog if the wrong thing is "selected" in the end ;-)

I would be willing to join a meeting and discuss this matter. Whoever thinks my input could help: "give me a call".

P.S.: I'm the team architect of the v4.ODataModel