FilterGroup(-1) does not work when applied to a page
1. Describe the bug FilterGroup(-1) does not apply to pages.
2. To Reproduce Add this code to the Customer List page:
trigger OnOpenPage()
begin
Rec.FilterGroup(-1);
Rec.SetRange("Country/Region Code", 'DE');
Rec.SetRange(Name, 'Relecloud');
end;
3. Expected behavior Customers that have 'DE' as their "Country/Region Code", or 'Relecloud' as their name, are shown when you open the page.
4. Actual behavior No filters whatsoever are applied when the page is opened.
5. Versions:
- AL Language: v8.2.550913
- Business Central: ES Business Central 19.1 (Platform 19.0.31889.32155 + Application 19.1.31886.32186)
This is known, and I thought it was documented, but I can't find that now.
I imagine it's because FilterGroup -1 is used for the cross-column Search box, so it would be confusing/ambiguous to also allow setting it in code.
It may be more a bug for the documentation. There is already this over there: https://github.com/MicrosoftDocs/dynamics365smb-devitpro/issues/6056
I actually thought that it might be a known limitation, but I was surprised that lack of support for flowfields is clearly specified in the docs, but there is no mention on pages.
Is there any particular reason for this, though, if that is indeed the case?
If not possible/implemented, could we at least get an error instead of nothing happening? Obviously it would be better for us if it worked, but an error at least would be unambiguous about the reason, and avoid developers expending time wondering whether they did something wrong 😅
I was surprised that lack of support for flowfields is clearly specified in the docs
It wasn't until I ran into the issue when writing code, and raised multiple bugs, at least one of which was on PartnerSource ;-)
Weirdly, FlowFields work in the client, when doing the Search - and often slow that process down dramatically - but not in code. That's almost more strange to me.
I agree fully with the rest you said, though. The FlowField thing was a great example of that. It lets you write the code, and only find out later after testing lots of red herrings, that said code won't actually do what you think. We need better tools than that.
We have internally discussed this issue and have decided not to accept this issue to be fixed at the moment to prioritize other issues. Thank you for raising this concern.
The reason for not accepting is down to capacity, and that this can also be addressed through better docs. I agree that it would be better to have an error raised for this (likely a codecop rule), but it's unlikely that we'll have the capacity to invest in that now.