Rework permissions and restrictions

[MarcusCaepio]

Is your feature request related to a problem? Please describe.

The docs say "There are two ways to configure restrictions: prefix-based and access controls [...]". So I suggested, that on the one hand, I can give "view" rights in BPs via access control roles in the BP config and on the other hand, can give "create" and "modify" rights on prefix-based BPs. But it seems, that prefix-based configs just overwrite the "view" rights of the access control. A role called "TeamA" with the prefix "teama" can only see BPs with this prefix, although I have added "TeamA" to the allowed roles of a BP which is named with another prefix.

Describe the solution you'd like

Instead of prefix-based or access control restrictions, it should be merged: If a prefix is given:

• allow create(if enabled),modify(if enabled), view to BPs with this prefix
• additionally allow to view BPs where the user/group/role was added in the BP config

Describe alternatives you've considered

A more granular restriction on the BPs level. Instead of just give access, there should be a modify and view option. So the prefix is not needed anymore.

Additional context

I currently have the problem, that I cannot give a role the right to create/modify their own BPs with a prefix and let them view specific other BPs. The "showall" option is just a workaround, because I only want to give view access to specific ones. Version 2.4.0

Cheers, Marcus

[nilmerg]

If we really start here changing anything, we should start from scratch:

Drop support for AllowedRoles, AllowedGroups and AllowedUsers

This should have been a part of the role configuration from the beginning. It makes more sense to reference business processes in roles than the other way round.

So there should be a new restriction called businessprocess/filter/configs which takes a comma separated list of configuration names. This could also support wildcards which then makes the businessprocess/prefix restriction obsolete. If it accepts just a single wildcard, it could also make businessprocess/showall obsolete.

Permissions should be linked to restrictions like in Icinga DB Web now

Well, at least the businessprocess/modify permission. It should not apply globally on all configs, only those the same role gives access to. (If it does not restrict access, it's a global permission still)

[MarcusCaepio]

But would it be possible to create own business processes on the one hand and give other roles readonly access on the other hand, when you drop the Allowed* parts? Basically I like the Allowed* config more then the prefixes. We have several BPs that are created from my team, viewed by other teams (which should not modify it) and vice versa. And as there are more and more BPs coming, some teams just want to see their relevant ones (and not "showall").

[nilmerg]

But would it be possible to create own business processes on the one hand and give other roles readonly access on the other hand, when you drop the Allowed* parts?

Yes and no. The give readonly access part requires role configuration access in case those users are restricted by businessprocess/filter/configs in some way.

some teams just want to see their relevant ones

That was the idea of the prefix restriction. They'll prefix their configs according to some rules.

Basically I like the Allowed* config more then the prefixes.

I guess because you're actually looking at this from a sharing point of view. Be it businessprocess/filter/configs, businessprocess/prefix or the Allow* parts, they're all restrictions and will narrow access.

What I think you'll want is a way to widen access. But that's an entirely different topic. As by default all users have access to all configs. The sharing feature would make sense if only the owner of a config has immediate access.