This message was deleted.

Might wholly depend on what you want to hide… You can override list views with a new set of columns I think. And detail views can be overridden also… The key thing in your statement that might pose a challenge is “for specific personas”…

Very generally the UI hides content, or doesn't show it, given settings or permissions on specific resources. For instance if the signed in user cannot see cluster role template bindings we don't show cluster member features. So I guess we'd need to know more about specific places to see if that pattern applies... or something different is needed. There are some known cases already, for instance installing the KubeWarden extension reveals the kube warden pages to all, for the purpose of installing the kube warden chart, however maybe it should be hidden for non-admins.

For that Rancher provides RBAC. You can “extend” the Rancher interface but it’s not meant to “replace” or mimic the current RBAC (user roles and permissions) in order to hide features from users

I definitely don't want to butcher the existing RBAC. But I figured the extension may need to implement it's own logic for that, (like the NV extension by checking for namespace existence and whatnot). There are a some different cases we need: • We need to be able to control who gets what extensions, so that different end-user types can get access to the tools they need, but not distracting extras. (i think this is coming or is already here, uncertain) • this is maybe a broken example, but for the sake of context, [it would be nice if] a helpful extension could augment the UI in ways that should not be controlled by resource access limitations. In some cases, I'd like a developer to have a simplified dashboard view for deployments that are managed by other tools, like Epinio. Maybe I don't really need them to see the Image column, so maybe the Epinio extension can hide it for users that are members of my epinio-developer group? I also may not need those developers to see the new Compliance tab added by the Neuvector extension, but I need my security folks to see it. • to replace/augment an existing control. for @big-greece-35822, that may be replacing Rancher's Health and State columns with StackState's determined workload health. For extra context, i'm also trying to address some specific needs: • we're trying to avoid "yet-another-portal" syndrome. All roads lead home to Rancher, and I believe we (platform team x) should be able to drive more users into Rancher. I don't want to say "don't use Rancher then, just use [insert specific tool, like argo, grafana, neuvector, kibana, sentry, servicenow, etc etc etc]", I want to encourage users to think of Rancher as their cloud, not bypass it. But I also need to present them with the right tools at the right time for their needs/abilities. The moment we ask users to bypass Rancher, they fall back into the old traps and they get fixated by the tools we provide access to (like Argo), and it's very difficult to reel them back. • Rancher Dashboard has become too complex for new users, or users with lower cloud-native experience (good thing, bad thing). For most operator/maintainer users, it has everything they need. For others, I may need to strip away some layers and add them back over time or in specific cases. If I'm providing portals, I'd like to be able to add some of that logic to extensions developed specifically for those users. (sounds like its a little bit "opt-in to opt-out". • Rancher absolutely needs to provide guardrails to prevent us from butchering things with extensions, and needs to encourage us to follow good practices for k8s and infrastructure in general, but it also shouldn't have to be Rancher's responsibility to address every nuanced use-cases. The ability to hide something, perhaps gated by enabling the person installing my extension to give my extension the permissions to hide something, would be awesome sorry for the long post here! I know some things are coming which might address this, but wanted to share the thoughts!

@witty-honey-18052 no worries. I totally understand you point. It’s an interesting usecase. From an extensions pov, this needs some thought on how such mechanism can be achieved without negative impact to user/client in terms of updates/support. There might be a couple of “intrusive” ways to achieve some of the things you would like to do right now, BUT they would mean that you would be overriding Rancher code and therefore lose any bug fixes or feature updates on those specific areas. We don’t want to share or encourage such practices. Thanks for sharing your ideas 🙏

All good, I think we can do this without breaking, forking, or overriding