THREESCALE-11644: Fix policy registry permission (and THREESCALE-6482)

[mayorova]

What this PR does / why we need it:

After fixing member permissions per service in #3929, policy registry operations are not working as expected. This PR fixes it.

This PR changes the permission model, and now the policy_registry is considered a "service-level" permission, so it can be applied to a subset of serviced, or all services.

This also affects the UI.

1. Member user permissions:

2. Dashboard for the user that only has policy_registry permission for a single service:

3. Product details for a user with policy_registry permission:

This PR also fixes an issue reported in https://issues.redhat.com/browse/THREESCALE-6482: when the member user only has Analytics permission, they can see "Explore all Products" link on the dashboard, and also "Products" entry in the context selector, they bring them to the Products list path, but the access is denied.
In this PR products list is shown to any member user that has access to some services with Analytics, Plans or Policy Registry permissions.

Which issue(s) this PR fixes

https://issues.redhat.com/browse/THREESCALE-11644

also fixes https://issues.redhat.com/browse/THREESCALE-6482

Verification steps

TBD

Special notes for your reviewer:

[jlledom]

This checkbox makes much more sense now.

I tried and works well for me. Having the policies box checked, API endpoints didn't work before and now work.

However there's a small UI bug. the Dashboard shows now the allowed service, but you can't interact with it. Clicking the link does nothing, and the dropdown is empty. See the screenshot

You can also visit /apiconfig/services/2/policies/edit and makes changes in the policy, I guess that's right and expected.

[akostadinov]

Shouldn't this be like:

Suggested change

	if can?(:manage, :plans)
	actions << { name: 'ActiveDocs', path: admin_service_api_docs_path(product) }
	actions << { name: 'Integration', path: admin_service_integration_path(product) }
	elsif can?(:manage, :policy_registry)
	actions << { name: 'Policies', path: edit_admin_service_policies_path(product) }
	end
	if can?(:manage, :plans)
	actions << { name: 'ActiveDocs', path: admin_service_api_docs_path(product) }
	actions << { name: 'Integration', path: admin_service_integration_path(product) }
	end
	if can?(:manage, :policy_registry)
	actions << { name: 'Policies', path: edit_admin_service_policies_path(product) }
	end

Can't user manage both?

[mayorova]

Yes, they can, and at first I wanted to do it as you are suggesting. But, I think that having both "Integration" and "Policies" items is redundant, because "Policies" is a sub-section of "Integration". So, if we have access to the parent section ("Integration"), we have just that one. And if we don't have access to "Integration", but only to its child "Policies", then we have "Policies" in the list.

[akostadinov]

Will this require changes to existing user permissions to make them compatible with the new approach?

[jlledom]

By accident I discovered a side effect, not sure if it's correct or a regression:

1. Uncheck the Create, read, update and delete box
2. Check the Access & query analytics of: box
3. In master: Product -> Integration -> Policies is not in the menu, but is accessible anyway
4. In this branch: Product -> Integration -> Policies is in the menu and accessible

[mayorova]

By accident I discovered a side effect, not sure if it's correct or a regression:

1. Uncheck the Create, read, update and delete box
2. Check the Access & query analytics of: box
3. In master: Product -> Integration -> Policies is not in the menu, but is accessible anyway
4. In this branch: Product -> Integration -> Policies is in the menu and accessible

Good catch @jlledom
This was not expected 😬

[mayorova]

I couldn't find any place where :policy_registry_ui would be used...

[jlledom]

Just to confirm:

config/abilities/provider_admin.rb: Permissions for provider admins
config/abilities/provider_member.rb: Permissions for provider members
config/abilities/provider_any.rb: Common permissions for provider admins and members.

Am I right?

[mayorova]

Just to confirm:

config/abilities/provider_admin.rb: Permissions for provider admins config/abilities/provider_member.rb: Permissions for provider members config/abilities/provider_any.rb: Common permissions for provider admins and members.

Am I right?

Exactly