Apologies if this has been answered; I did search and couldn’t find anything that seemed relevant.
Is it possible to simply hide UI elements (eg: the “Edit” button) from a Dashboard for a specific user?
We want to create users that are able to access Dashboards, but have no ability to modify them. We do have it so that they are unable to save attempted edits, but the “Edit” button remains visible, which misleads them into thinking they can edit.
Currently using the last version of OpenDistro, but am preparing to migrate to OpenSearch.
@dmbreakey there is no option as far as I’m aware. The closest would be the kibana_read_only role, which only allows access to dashboards, however the edit button is still present.
I’d recommend raising an issue here, as this would be a great addition.
Curious, because I am certain I have seen someone who, as far as I can tell is using OpenDistro, and in their instance, the “Edit” button appears to be gone.
I’d have to assume they’re using a custom plugin, in that case? Or is that even feasible? I think they are using a slightly older release (a couple of point-releases behind).
Or, could they be doing something as simple as custom CSS, that just instructs the browser to not render the button? Can you even do that on a per-user basis?
I’m beginning to suspect we might have hit upon a regression, although I am not convinced of that yet (seems like this would be a rather obvious bug to have been overlooked).
After comparing the other’s deployment against ours (by reviewing the raw HTML) I am convinced that he’s not doing anything that isn’t already fully supported in the version we’re running, as the relevant HTML is the same in both cases except for a key attribute in the BODY tag. It appears to be the fact that our deployment is not inserting this attribute that is preventing this from working.
And given the name of the class and attribute in question, security-isReadOnlyTenant, I do have to wonder if I messed something up when defining the user permissions.
It’s either that, or this really is a regression… hopefully I’ll know soon.
@dmbreakey I tried to odfe 1.10.1 and the “edit” button is still there. So doesn’t look like a configuration issue from your end. I do have a feeling that older versions didn’t have this button, but I could be mistaken.
On the other, older install, the “Edit” link is definitely there, and fully functional; all I need to do is go into the DOM Inspector in my browser and instruct it to ignore the {display:none} directive, and then I can click on it and get exactly the behavior I’d expect. The only tricky part is finding it in the HTML.
Namely the edit controls appear in the dashboard elements. I’m confident this means I misconfigured something on our local install; I just don’t understand what yet.
The CSS is being applied to a class, which seems to be applied to the <BODY> tag; specifically the relevant CSS is .security-isReadOnlyTenant[security_path^="dashboard"] [data-test-subj="dashboardEditMode"], with the former attribute (security_path) applied to the <BODY> tag, and the latter attribute applied to the container element holding the Edit link.
On our installation, the .security-isReadyOnlyTenant class is not applied to the <BODY> tag; it is present on the other, working install.
This is what makes me think this is deliberate, supported behavior out of the box.
@dmbreakey had a chance to try to with older version (1.3.0) and can confirm the behaviour was not present there (i.e. no edit button). Haven’t tried the later versions.
But I think it would make more sense not to have Edit button if the user is mapped to dashboard read-only mode.
I’ve been digging into this extensively in the final build of OpenDistro, and it appears the function to hide/show the “Edit” button is present, and there’s a flag present that tells it whether to present a “read-only dashboard”, and as far as I can tell code is present (in the JavaScript pieces) that checks this flag and reacts to it. If the flag is set to show a read-only Dashboard, it hides the “Edit” button… I’m pretty sure, anyway.
What doesn’t appear to be present is any ability to change the default value of this flag. It defaults to allowing Dashboards to be edited, and as far as I can tell there’s no code that actually changes it, or allows it to be changed.
I may well be misreading this (I’m getting reasonably proficient at Python, but JS still throws me–not confident I understand how it handles object references and relationships, nor do I yet “get” the app framework), but it seems to me that, in theory, all we need is to write a plugin that allows us to control that flag, either directly or indirectly, and it should take care of itself automatically. I think…
I’m guessing what is supposed to happen is that the Security plugin controls this flag, based on whatever criteria it chooses, and then the Dashboard just “does the right thing” automatically. But for whatever reason, it seems the OpenDistro (and I’m guessing now OpenSearch) Security plugin doesn’t manage this flag for some reason. Maybe because the OSS build of Elastic doesn’t? But that’s only speculation.
You can use RBAC feature in opensearch to manage who can access and modify dashboards. By creating custom roles with specific permission you can allow some user to only view dashboard without being able to make any change.