https://www.gooddata.com/ logo
Join Slack
Powered by
Dear masters! I have a workspace where the API end...
# gooddata-cn
v
Dear masters! I have a workspace where the API endpoint (
/api/entities/workspaces/<wsid>/analyticalDashboards
) shows 3 dashboards, but if I log into the system I can only see one of these dashboards. If I am trying to load the URL of the other 2 dashboards, I get a "The dashboard has not been found.\nCheck the URI and make sure you are authorized to access it." message. Is this a known bug, or do you need some more details? We ran an upgrade from 1.4 to 1.5 five days ago.
Okay, looks like this happens if you change the data model in a workspace with existing dashboards. As I switched to another DataSource, my dashboard was not showing up on the UI. Once I switched back to the old DataSource, the dashboard reappeared. Is this a bug?
d
Hi Vajk, the behaviour you observe is not a bug, rather a not very user friendly feature. When you change data model some of the metrics typically become invalid (e.g. due to them pointing to no longer existing facts) and therefore also insights and dashboards they are using become transitively invalid. UI currently simply hides such broken metrics/insights/dashboards. In the future we would like to improve the situation, e.g. by highlighting or ignoring just the broken insights in a dashboard and not hiding the whole dashboard.
Also may I ask you what would be your expected behaviour in such a situation when a metric/insight/dashboard is broken by upstream change (e.g. deleting a fact source column in a data source)?
v
Great follow up question David, thanks. Problem: My problem is that in our internal system (which connects to GD.CN through the API), we receive the invalid dashboards as well. We display them. When the users navigate to them, they receive an error message. Expectation (either one): • Have an API endpoint that only returns the valid dashboards within a workspace • Have a field in the 
/api/entities/workspaces/<wsid>/analyticalDashboards
response. E..g: 
analytics.analyticalDashboards[].transitively_valid
that would simply tell if this is a valid dashboard. • Have a formula that I could use on the 
/api/layout/workspaces/<wsid>
response to determine validity
d
There indeed is such a field in the dashboard entities API. It is computed when you supply the X-GDC-VALIDATE-RELATIONS header (which is exactly what the UI tools do). See for more details: https://www.gooddata.com/developers/cloud-native/doc/1.5/api/api_reference_all/#/entities/getEntity%40AnalyticalDashboards
❤️ 1
Another follow-up question from my side: What's the main reason why your dashboards are getting broken? Is there anything GD.CN can be more helpful with?
Also previously you mentioned that you switch between data sources. This naturally and necessarily (at least from GD.CN point of view) typpically breaks all the existing entities. I wonder what are you trying to achieve with that. Or was it just a test for the perceived buggy behaviour?
v
Yeah, agreed, this is not something we should do. It just came up during we were experimenting with the dashboards. First these seems to be as a potential bug, wanted to get to the bottom of it. Now, I just want to make our API usage foolproof, and remove inconsistencies between the GD webapp and what we display.
Thanks for pointing out X-GDC-VALIDATE-RELATIONS, that as exactly what I was looking for.
Open in Slack
PreviousNext
Powered by