Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems getting the filter fields in alphabetic order #1262

Open
guleri opened this issue Aug 26, 2024 · 1 comment
Open

Problems getting the filter fields in alphabetic order #1262

guleri opened this issue Aug 26, 2024 · 1 comment
Labels

Comments

@guleri
Copy link

guleri commented Aug 26, 2024

ldproxy Version

3.6.1.

Current Behavior

I also posted this in the discussions section (#1255), but the difference between how this works when I specify the fields vs. when I use "include all", makes me believe that this isn't intended behavior. Something similar was also perceived as a bug/regression in #795.

I'm having some problems getting the filter fields in alphabetic order. That is, I'm having problems when I'm using "include all" like this:

buildingBlock: QUERYABLES
enabled: true
included:
    "*"

If I specify what fields I want to include, e.g.:

included:

  • vernetype
  • navn

the filter fields are sorted.

Expected Behavior

I expect that the filter fields are rendered in alphabetical order, regardless of if I specify the fields I want to be included or if I specify to include all existing fields.

Steps to Reproduce

Adding the following in a config-file under defaults or for a specific service.

 - buildingBlock: QUERYABLES
   enabled: true
   included:
     - "*"

Relevant log output

No response

@guleri guleri added the bug label Aug 26, 2024
@guleri
Copy link
Author

guleri commented Sep 20, 2024

Looks like I was wrong about the filter fields being sorted if I specify fields. The filter fields order seems to be decided by the property order in the provider. Anyway, it seems like there's been a regression again (as mentioned in #795 and addressed in #848), so unless there's a workaround, I'll probably postpone the upgrade to v4.x, hoping it will be resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant