Fixes #38727 - Make autocompletion honor permissions

[adamruzicka]

An alternative to #10197

[sbernhard]

Does this solves the following issue, too?

2 organizations: org1 and org2. Both organizations have hosts.

User U has access to hosts of organization org1. So the user has the permission to to view hosts etc but only on org1.

Can you maybe add such a test case?

[adamruzicka]

So the situation you're asking about is:

1. There are organizations org1 and org2
2. There is a user U
3. User U is a member of both organizations
4. There is a role "org1 host manager", the role has all *_host permissions assigned, the role is assigned to org1
5. User U has the "org1 host manager" role assigned

The expectation is that User U should be able to view only hosts from org1, no matter what org the org selector is set to? Doesn't this work currently?

[sbernhard]

So the situation you're asking about is:

1. There are organizations org1 and org2
2. There is a user U
3. User U is a member of both organizations
4. There is a role "org1 host manager", the role has all *_host permissions assigned, the role is assigned to org1
5. User U has the "org1 host manager" role assigned

The expectation is that User U should be able to view only hosts from org1, no matter what org the org selector is set to? Doesn't this work currently?

Sorry, the issue was pretty old that I have mixed something up. Just have retested the case:

1. There are organizations org1 and org2
2. In org1 there is CV1, AC1, Repo1. In org2 there is CV2, AC2, Repo2
3. There is a user U who has the role "manager"
4. User U is a member of org1 - NOT org2
5. If User U is logged in and the "org1" is selected, there is NO content in Content Views, Activation Keys, Lifecycle Environments
6. User U uses the Host search bar in "Content Hosts" and enters "content_view = " and is able to see all contet views which are configuerd in org2. Same for activation keys, repositories,

[adamruzicka]

Just have retested the case:

Unless I took a wrong detour somewhere, the issue can be simplified t othis

1. Be admin
2. Have katello stuff in org2
3. Switch to org1
4. In hosts page search for content_view =

This pr doesn't help with that at all, that will need to be fixed in katello.

[sbernhard]

Just have retested the case:

Unless I took a wrong detour somewhere, the issue can be simplified t othis

1. Be admin
2. Have katello stuff in org2
3. Switch to org1
4. In hosts page search for content_view =

This pr doesn't help with that at all, that will need to be fixed in katello.

Well, its even worse because the user is only in org1 but can see content of org2.

[ofedoren]

I'm not sure this PR does anything... While it might be my setup, it didn't fix the issue described with reproducing steps even with Katello counterpart :/

Also, should this fix also affect search in Audits page?

[adamruzicka]

Well, its even worse because the user is only in org1 but can see content of org2.

From the user's point of view that's indeed worse, but including fine-grained permissions in the mix shifts the focus to a slightly different place.

I'm not sure this PR does anything...

I aimed to address scoping on the immediate resource

1. Have a user
2. Have orgs A and B
3. Assign the user to both organizations
4. Create a subnet in org A
5. Create another subnet in org B
6. Create a role
7. Assign the role to org A
8. Add view_subnets to the role
9. Assign the role to the user
10. Log in as user
11. Set context to any/any
12. Go to Infrastructure > Subnets
13. Put name = into the search bar

it didn't fix the issue described with reproducing steps even

The ones in redmine? I must admit I connected a bunch of issues to this post-mortem, maybe that wasn't the wisest thing to do

should this fix also affect search in Audits page?

That depends, what's wrong with search in audits page?

[adamruzicka]

Alright, so I tried going about it a bit differently, this seems to work as I'd expect for foreman resources. My katello dev env got eaten while I was on pto, it will take a while to get it back up.

[adamruzicka]

Interestingly enough, the new approach seems to also work for katello, or at least for katello resources which include the module?

[ofedoren]

Agh, it's pain to test :/

The steps from #10645 (comment) have the same result with or without the patch. Also, it's for some reason not possible to select any location if a user has 1 assigned. any org is possible to select if a user has 2 assigned.

Also, I think it's still mixes up logic: permissions vs taxonomy scoping. It's kinda hard to say whether one cannot see a resource due to perms or taxonomy.

In any case, this PR doesn't solve the bug described in the issue. I'd vote for rather different approach/fix or this fix is for a different issue.

[adamruzicka]

The steps from #10645 (comment) have the same result with or without the patch.

Odd, I'm getting different behaviour. Could you double check the permission in the role doesn't have the unlimited checkbox checked (which by a different bug gets set by default).

Also, there's a test which fails without the code change and passes with it so there has to be some merit to it?

I think it's still mixes up logic: permissions vs taxonomy scoping

If you set the context to any-any, then it should be strictly a matter of permissions.

[ekohl]

This reminds me of theforeman/foreman_monitoring#99 where we found that scoped_search doesn't take constraints into account.

[adamruzicka]

Ok, alternative, taxonomy-less reproducer:

1. Create domain called foo
2. Create a domain called bar
3. Create a role
4. Add view_domains permission to it, limit it by search to name ~ f*
5. Create a user
6. Give the role to the user
7. Log in as user
8. Go to infrastructure > domains
9. Put name = into the search bar

Autocomplete should offer you both domains without this patch and only foo with this patch

[ofedoren]

Thanks, @adamruzicka for context.

This patch indeed fixes your reproducer, but I'm afraid this is still true:

In any case, this PR doesn't solve the bug described in the issue. I'd vote for rather different approach/fix or this fix is for a different issue.

This could help with the original one, but in unexpected (requires more steps) way, but didn't try it though.

[Copilot]

Pull Request Overview

This PR makes autocompletion honor user permissions by implementing permission-based filtering for autocomplete suggestions. It adds a completer_scope method to the Authorizable concern that filters results based on view permissions, and includes a test to verify that users only see autocomplete options they have permission to view.

Key Changes:

• Added completer_scope method to Authorizable concern to filter autocomplete results by view permissions
• Added test coverage to verify permission-based filtering works correctly for autocomplete functionality

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
app/models/concerns/authorizable.rb	Implements completer_scope method that filters results using view permissions
test/controllers/concerns/auto_complete_search_test.rb	Adds test to verify autocomplete respects user permissions

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The options parameter is not used in the method implementation. Consider either removing it if it's not needed, or using it to provide additional filtering capabilities for the completer scope.

Suggested change

	def completer_scope(options)
	def completer_scope

[adamruzicka]

It is a callback from scoped search. The argument is always passed so the method needs to accept it. I can prefix it with an underscore though

[ofedoren]

Thanks, @adamruzicka !

Changing the scope a bit quite helped to push this further.

I confirm that the test fails without this patch, the fix itself is only tighten to autocompletion, thus shouldn't introduce some hidden issues.