All I think I found an issue with Views and the reset filter in the GoodData UI/SDK/etc. Seems that when you interact with the reset filter button, it destroys the views you have saved.

Hi Steve, thank you for reporting this. The behaviour does not look intended indeed, could you let me know if you are having the same issue in the platform? Additionally, what SDK version are you using? Ideally, please share the package.json file. Thanks!

This is in gooddata ui directly

Thanks for the details. Could you please send me a direct link to the workspace in question? I will take a closer look.

We saw it in every workspace/dashboard we have, but this is the one I used for the videos https://analytics.golmn.com/dashboards/#/workspace/LMN_31259/dashboard/31bfea7f-73ed-4873-a5b0-28bfcf75a4f4

@Steve Fox our apologies for the radio silence, please be aware that according to your subscription, you can also reach out to us via an internal ticket any time; I would recommend keeping this in mind depending on how critical the issue is. We have checked the dashboard entity in the parent workspace: https://analytics.golmn.com/dashboards/#/workspace/LMN_Single_Parent/dashboard/31bfea7f-73ed-4873-a5b0-28bfcf75a4f4 and found that the definition for the filter attribute in the filter context is using the incorrect id; For example, in the following filter context:

"attributeFilter": {
"displayForm": {
"identifier": {
"id": "DIM_DIVISION.DIM_DIVISION_ID.divisionname",
"type": "label"
}
},
"selectionMode": "multi",
"localIdentifier": "94769c46b0894461aa53bec77665bb7e",
"attributeElements": {
"uris": []
},
"negativeSelection": true
}
},

The id is set to

DIM_DIVISION.DIM_DIVISION_ID.divisionname

, instead of

DIM_DIVISION.DIM_DIVISION_ID

. If you change the id so it is set to the primary label of the attribute, then the saved view will behave correctly. You can check the definition from the filter context entity, e.g:

/api/v1/entities/workspaces/LMN_Single_Parent/filterContexts/bda52822-1164-49e4-97ef-4b2d299dda7b

and modify it via a PUT call.

Not following, that filter is using the attribute for display are we saying that we have to use the ID's to display?

That's correct, you will always have to use the primary label as the id for the attribute in the filter context. Regarding the Job Group filter, I see it has the same issue: Definition in the filter context:

{
            "attributeFilter": {
              "displayForm": {
                "identifier": {
                  "id": "DIM_JOB_GROUP.JOB_GROUP_ID.jobgroupname",
                  "type": "label"
                }
              }

But according to the LDM, it should be:

DIM_JOB_GROUP.JOB_GROUP_ID

Let me know if you are still experiencing the same issue after setting the correct ID.

I'm sort of confused then. Are we saying our PDM is backward?

There are no issues with your PDM, the issue here is specifically related to the ID in the filter context definition highlighted previously. You can check for instance, the metadata for the dashboard entity and see the "displayAsLabel" key under the attributeFilterConfigs array, this defines the label you are using for the filter, e.g., if you are using the secondary label, that's OK, but if you check the definition for the filter context, it has incorrectly assigned this same label (secondary) instead of the primary one; The id of an attribute in the filter context entity can only be its primary label.

I feel like something is off here. If the attribute is defined based on the id, I'm using the secondary attribute to do the filtering, yet you're saying Gooddata is using the attribute's secondary label as the filter context. How do I fix it? Apologies, I feel like I'm missing something fundamental here.

It can be done via a PUT call. You can check the definition from the filter context entity, e.g:

/api/v1/entities/workspaces/LMN_Single_Parent/filterContexts/bda52822-1164-49e4-97ef-4b2d299dda7b

. We noticed this behaviour on a another customer's setup and it was fixed the same way.

@Moises Morales sorry that this took so long for me to get back to, but I'm having some trouble trying to fix this issue. 2 things 1. I switched the primary label to be the name, so that when I default bring in the column things match 2. regardless of how I setup the LDM -> whenever I select the name instead of the ID, the attribute ID uses the "wrong" value as you describe here. According to what you're saying in this thread, the ONLY way for this field to work properly is for me to use the ID field for sorting, which seems like I'm at a loss for how to implement this while showing the meaningful value with the Display text. For background, we've found that we need to name the ID field as the base and then add things like the display name or other labels ontop to make sure that when using these the sorts/filters use the ID field to define the query. But for some reason this one does not.

Thanks for following the steps and no worries, it is in our best interest this is cleared out. Just to make sure, could you please send over a link to the dashboard with the issue persists? I will explore once again all possibilities for the issue to make sure nothing was overlooked last time. Once I get the link to the dashboard, I will circle back to you with my findings. Thanks!

https://analytics.golmn.com/dashboards/#/workspace/lmn_single_authoring/dashboard/a408fe39-851a-48bb-8ece-c68e2ad4dcad I created a clone to experiment with

Morning Steve, thank you for the additional remarks and further investigation. In the end it does seems that the issue is due to those secondary levels used instead of the correct one, although I am still double checking this on my end and working on a reliable reproducer. I will circle back to you with an update as soon as I know more. In the meantime, do you know by any chance how were the filters created originally? Was it done programmatically or via the UI?

Via the UI.