apache
Hiding Force refresh in Dashboard
Bug description
Hello,
I want to disable Force Refresh in Dashboard for users. It should only be accessed by the admins.
I created a new role and given only read only permissions, still users are able to do force refresh.
Which permission should I revoke for Gamma users to hide this option ?
How to reproduce the bug
Go to the dashboard. In menu, use Force refresh.
Screenshots/recordings
Superset version
3.1.2
Python version
3.11
Node version
16
Browser
Chrome
Additional context
No response
Checklist
- [X] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [X] I have searched the GitHub issue tracker and didn't find a similar bug report.
- [X] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.
I'm not sure if there is such a granular permission for that. I'm curious the use case and why you wouldn't want users to refresh... maybe for embedded purposes?
Maybe @eschutho or @dpgaspar know a permission that can address this.
@rusackas Frequent refresh causes a lot of query to Athena which also increases our Athena cost.
Sounds reasonable, but just to play devil's advocate here... are you sure you have a lot of users doing "force refresh" or is the dashboard's cache timeout too short? Also maybe worth noting that people can still run these queries via the chart builder or SQL lab views as frequently as they want.
Another solution would be to put a tool in the middle that queries athena on a schedule (or provides an additional layer of caching, at least), keeping the resulting data in a more cost-effective warehouse/lake/db/etc. which you'd connect Superset to.
I'm not sure if there is such a granular permission for that. I'm curious the use case and why you wouldn't want users to refresh... maybe for embedded purposes?
Maybe @eschutho or @dpgaspar know a permission that can address this.
No specific permission for it. As you said, user's can always hit the endpoint explore_json or chart/data`, rate limit could be a solution also
I'm adding a note here as I'm thinking about evolving the security model, and going with a hierarchical action model. I want to make sure that the model we'll come up with will work to support the perm requests across the community.
Here the resource would be Dashboard and action would be read.refresh.force, where composing a role you could specify you give read.* minus !read.refresh.force. Clearly will require work to attach perms to actions across the frontend/backend, but seems the model I have in mind (and will publish soon) should support this.
No update on my side, was mostly thinking about a recent SIP and how it relates to this, but I wouldn't couple the solutions.
I can point to this https://github.com/apache/superset/pull/27029 as a recent similar PR that may be used for inspiration as to how to implement more granular perms.