There isn't an appropriate role to list all the catalog services in group but list only owned services

[mkumatag]

As a user I want to list/use all the service catalogs in my group but only want to see only the services deployed by me. Rightnow there isn't a way achieve this flow.

Matrix discussion link - https://matrix.to/#/!fNWKLobuKKpFTwgXzO:gitter.im/$NXWkd1YY_tzWWvyt9dGtowOtkerfIbB6K1NANtD79XM?via=gitter.im&via=matrix.org&via=grare.com

[mkumatag]

The scenario is that user A and B are part of group G and I have shared set of service catalogs for that group and both users ordered the services, e.g: user A ordered a service S1 and user B ordered a service S2 and per current setting what I see is that both user A and B sees service S1 and S2, can operate(retire) other's service as well. So my use case is user A and B should list all the catalogs in group G but user A should see only S1, user B should see only S2.

I tried setting the option as user created scope which solved partial problem where I was able see only what user created but user was not able to see the catalogs which are created by the admin.

[kbrock]

The newly created resource will get the group of the requester or the service.
If the catalog is owned by the group of A and B, then yes, this will be assigned the shared group. And yes, this sounds different from what you want.

If the service catalog is owned by a parent tenant, does the service get the parent tenant's default group, and get you what you want?

[mkumatag]

I just have one tanent in the system and all the resources under that, e.g:

And then I have create a group and assigned A and B into that pac-group-basic and assigned Role pac-user_self_service

And then I have assigned the catalog to that group so that user A and B can see which is all good.

But my concern is that user A and B both can see all the service instances deployed by both and user A can retire the service deployed by B which I don't want to see.

[jaywcarman]

@kbrock

If the service catalog is owned by a parent tenant, does the service get the parent tenant's default group, and get you what you want?

Is it possible to set the catalog owner to a tenant? Looks like ownership can only be set to a user and/or group:

[Fryguy]

I was pretty sure catalog could be set to tenants, but apparently not? @kbrock ?

[kbrock]

You need to set it to a group from the desired tenant. Then it will get the tenant from the group.

But that drop down does not show the tenant's default groups. (This could be a bug)

If you create a group in your desired tenant, will it show up in the drop down?

[jaywcarman]

@kbrock I think I'm getting a bit closer, but am not quite there yet. I'm running on an manageiq-libvirt-oparin-1.1.qc2 appliance. Here's my config:

I created a "child-tenant", which is a child of the default "My Company" tenant:

Then I created "child-tenant-group" and assigned a couple of test users:

The group is using the out-of-box "EvmRole-user_self_service" role:

Now I've created a service catalog item that is owned by the "EvmGroup-user_self_service" group (which is one of the groups that comes under the default top level tenant). I also check the "child-tenant" box under the "Additional Tenants" section. I'm not sure if this is correct since my test users don't belong to this group. The problem is that Tenant seems to be set by the group ownership, so if I set the service catalog item is owned by "child-tenant-group" group it is also owned by the "child-tenant" tenant.

With things setup as shown in the screenshots above the test users don't have access to the service catalog item.

Any ideas? This test env is still up - I'm happy to provide connection info privately if you want to go play around @kbrock.

[jaywcarman]

@mkumatag I discussed this with @Fryguy and team earlier this week. Since there is a single role access restriction set for catalog items and vms (among other things) we don't think it's possible to assign catalog items to a group but restrict the created VMs to a single user 😞:

So I think the next step will be coming up with an enhancement/refactor to allow finer access restriction settings. @Fryguy: was there anything else from our discussion that I missed?

[mkumatag]

So I think the next step will be coming up with an enhancement/refactor to allow finer access restriction settings. @Fryguy: was there anything else from our discussion that I missed?

:( Is there any stopgap solution at the moment to workaround the issue, because enhancement/refactor will take more time sure.

[jaywcarman]

Maybe something like this could work:

• Assign users to a role with Access Restriction = Only User Owned
• Create a service catalog item to use as a template from which to make copies
• For each user, create a copy of the service catalog item with ownership set to the user (instead of group)
  • If you have too many users to manage this through the GUI, perhaps we could script automation through the Service Management API

[mkumatag]

Maybe something like this could work:

• Assign users to a role with Access Restriction = Only User Owned

• Create a service catalog item to use as a template from which to make copies

• For each user, create a copy of the service catalog item with ownership set to the user (instead of group)

  • If you have too many users to manage this through the GUI, perhaps we could script automation through the Service Management API

hmm.. This is a tedious job sure, I may need to have a script always looks for a new user and keep doing this for newly onboarded user.. Users being managed via keycloak will create scenario even more complicated!

[mkumatag]

@jaywcarman Wondering who can help us creating that enhancement to enable this feature?

So I think the next step will be coming up with an enhancement/refactor to allow finer access restriction settings. @Fryguy: was there anything else from our discussion that I missed?

[Fryguy]

The fundamental problem is that the Access Restriction encompasses multiple types of objects

Access Restriction for Catalog Items, ... , VMs, and Templates

The way to enable this type of change would be to split this setting apart, either into related groups or perhaps individually. However, this is a deeper enhancement and will take some time to fix. Changed this from bug to enhancement.

[Fryguy]

Reopening this issue because the change in #22573 is backend only, but there's no way to change that value in the UI as of yet.

[Fryguy]

@jaywcarman Will you also be working on the frontend changes?

[jaywcarman]

@jaywcarman Will you also be working on the frontend changes?

Yes: ManageIQ/manageiq-ui-classic#8833

[Fryguy]

closed via ManageIQ/manageiq-ui-classic#8833