How to 'specify permissions' on an Umbraco dashboard?
See original GitHub issueI found the documentation for managing dashboards. It is not helpful for my task. I need to hide the Redirect URL Management dashboard from users in the Writers group. (It seems like a bug that it shows for them!) In other words, I need to ‘specify permissions’ on an Umbraco (built-in) dashboard. The docs do not cover this important task. They only show how to remove an Umbraco dashboard. I cannot remove the Redirect URL Management dashboard, because Administrators use it.
I tried putting a package.manifest in the App_Plugins folder; however, I do not know the alias of the Redirect URL Management dashboard.
I found the Redirect URL Management view, but I could not easily track down its alias.
{
"dashboards": [
{
"alias": "redirectUrls",
"sections": [ "content"],
"access": [
{ "deny": "writer" },
{ "grant": "admin" }
]
}
]
}
In v7, its alias was RedirectUrlManagement. In early v8, it appears it was RedirectUrlDashboard. In the aforementioned documentation, it only references its language key, which is dashboardTabs/contentRedirectManager.
Sadly, once again, something that was dead simple in v7 is complicated and poorly documented. Any help would be greatly appreciated.
This item has been added to our backlog AB#5462
Issue Analytics
- State:
- Created 4 years ago
- Comments:29 (11 by maintainers)
Thanks, @Shazwazza! I express my gratitude with a PR.
https://github.com/umbraco/UmbracoDocs/pull/2335
This should work:
Can this be easier? Yes! Ideally the interface for IDashboard could have allowed a mutable collection for access rules but unfortunately thats not the case otherwise it would have been reasonably easy. The IAccessRule themselves is mutable but that doesn’t solve this problem of adding/removing rules from the dashboard definition.
We could allow adding custom filters to override rules which could look something like:
The
Modify
method could also allow modifying the sections.Some things in v8 had to be rebuilt, things that relied on the legacy configuration patterns and configuration ‘provider’ models. The config first approach is legacy because it is inflexible, error prone, doesn’t allow for modern coding standards, etc… With these components rebuilt the way they are, it is certainly possible to re-add configuration back in where it makes sense. We didn’t remove file based configuration just to be annoying, it was just re-added for the 8.0 release since we need to gauge the requirement for it and whether/where it makes sense.