*** Bug 1220781 has been marked as a duplicate of this bug. ***

yes they are reporting the same issue. 

But it's slightly different I feel.

Even after we hit the "refresh" button, with proper orgs selected for the user, this issue is seen.

sorry correction may be I got confused with other similar issue while raising this bug and hence thought so that proper orgs and location was set. this issue is seen only when orgs and locations are not set and we are updating new roles at the user_group level.

Upon unassigning roles from user-group and associating orgs and locations to the user and then again updating roles at the user_group level solves this issue.

So the question is if this is still a bug when:

updating roles for a user-group without assigning orgs and locations first to the user.

1. configure LDAP authentication using http://theforeman.org/manuals/1.8/index.html#4.1.1LDAPAuthentication
2. create a user-group "katello" with external user-group "foobargroup"(i.e. here from Active Directory)
3. Make sure "foobar" user is part of "foobargroup" at the AD side.
4. Create a custom role "prd_role" and assign all the permissions to it.
5. Assign this "prd_role" role at the user_group level for user_group "katello" created above.
6. login as a AD user "foobar", which is part of the external user-group, to check that the permission on "prd_role" is visible and logout.
7. Login as admin (make sure no orgs or location are assigned to the user) and now create "ak_role" role via the roles and assign all the "activation keys" permissions via the filters.
8. assign the role "ak_role" at the user_group level(only after step 6) performed to reproduce this bug) and hit submit.
9. At this stage you may also hit the "Refresh" button too.
10. Log back in as "foobar" user to see only the prd links visible and no ak links visible, which says that the permissions of the role "ak_role" are not getting updated for some reason at the user_group level.

Following these steps I do see "Content">"Activation keys" at the end of the process although it's a 403 - reasonably as the user has no organizations set.

This issue does exist and if it's not reproducible, I can reproduce and share it.

As said in comment9 , this is a bug and happens when org and location are not set for the user.

Created redmine issue http://projects.theforeman.org/issues/14410 from this bug

Upstream bug component is Content Management

Hey - can you try to reproduce this with other permission? I was able to reproduce this a few weeks ago, not now though. I think it had to do with the order in which Katello permissions ere loaded.

Ah, finally found the cause. It doesn't have to do with external user groups as far as I can see. You'll probably struggle to reproduce this one, as it requires:

    Upgrading from some verison
    Fail during the upgrade so that some migration does not run

At that point, Foreman::AccessControl does not load the permissions from plugins properly, as per line https://github.com/theforeman/foreman/blob/develop/app/services/foreman/plugin.rb#L217

If you run foreman-rake db:migrate and systemctl restart httpd, permissions will be reloaded again and it will work.
So I guess we should either log this better or turn on the check for missing migrations in production. (https://gist.github.com/stbenjam/c182ff0b1fe99bef6680ea4463f1f156)

Related to https://bugzilla.redhat.com/show_bug.cgi?id=1316246

Upstream bug component is Provisioning

Under review at https://github.com/theforeman/foreman/pull/3426

Upstream bug component is Upgrades

Moving to POST since upstream bug http://projects.theforeman.org/issues/14410 has been closed

General mechanism seems fixed and role applied properly. Verified both on 6.2.7 and 6.3.0, but that exact scenario described in the initial issue (with ak_roles) gives me exception when I try to select 'Content'->'Activation Keys' for that AD user (also reproduced both on ):

2017-01-17 04:55:06 a948ee3d [app] [I] Started GET "/activation_keys" for 10.36.6.247 at 2017-01-17 04:55:06 -0500
2017-01-17 04:55:06 a948ee3d [app] [I] Processing by Bastion::BastionController#index as HTML
2017-01-17 04:55:06 a948ee3d [app] [I]   Parameters: {"bastion_page"=>"activation_keys"}
2017-01-17 04:55:06 a948ee3d [app] [I]   Rendered home/_submenu.html.erb (2.6ms)
2017-01-17 04:55:06 a948ee3d [app] [I]   Rendered home/_user_dropdown.html.erb (2.3ms)
2017-01-17 04:55:06 a948ee3d [app] [I] Read fragment views/tabs_and_title_records-33 (0.2ms)
2017-01-17 04:55:06 a948ee3d [app] [I]   Rendered home/_topbar.html.erb (13.8ms)
2017-01-17 04:55:06 a948ee3d [app] [I]   Rendered layouts/base.html.erb (16.1ms)
2017-01-17 04:55:06 a948ee3d [app] [I]   Rendered /opt/theforeman/tfm/root/usr/share/gems/gems/bastion-3.3.4/app/views/bastion/layouts/assets.html.erb (30.2ms)
2017-01-17 04:55:06 a948ee3d [app] [I]   Rendered /opt/theforeman/tfm/root/usr/share/gems/gems/bastion-3.3.4/app/views/bastion/layouts/application.html.erb (31.0ms)
2017-01-17 04:55:06 a948ee3d [app] [I] Completed 200 OK in 50ms (Views: 29.2ms | ActiveRecord: 5.5ms)
2017-01-17 04:55:06 a948ee3d [app] [I] Started GET "/assets/bastion/bastion-89f6a0b75db9dd30679e14c8288fb865c7594c6f70092687c6ac721d087dbd73.css" for 10.36.6.247 at 2017-01-17 04:55:06 -0500
2017-01-17 04:55:06 a948ee3d [app] [I] Started GET "/assets/bastion_katello/bastion_katello-8ae772c29a0c0008f4c2b68153d26b7f1b30dcdde06076373e390f33e506219c.css" for 10.36.6.247 at 2017-01-17 04:55:06 -0500
2017-01-17 04:55:06 a948ee3d [app] [I] Started GET "/assets/bastion/bastion-6d4a3fd06675ee53273e772b29a517952db6a7b883b3570c8c8a0ac40c2922c9.js" for 10.36.6.247 at 2017-01-17 04:55:06 -0500
2017-01-17 04:55:06 a948ee3d [app] [I] Started GET "/assets/bastion/angular-i18n/angular-locale_en-135e9f6ac2f6380915044f0f12995fe888b96cc759b6622269eb4ca48cd31c5d.js" for 10.36.6.247 at 2017-01-17 04:55:06 -0500
2017-01-17 04:55:06 a948ee3d [app] [I] Started GET "/assets/bastion_katello/bastion_katello-027269ecd528e3c604c438dbafd836b84224ecff3aa000eb0a81715dea55908c.js" for 10.36.6.247 at 2017-01-17 04:55:06 -0500
2017-01-17 04:55:07 a948ee3d [app] [I] Started GET "/katello/403" for 10.36.6.247 at 2017-01-17 04:55:07 -0500
2017-01-17 04:55:07 a948ee3d [app] [I] Processing by Katello::ApplicationController#permission_denied as HTML
2017-01-17 04:55:07 a948ee3d [app] [I] Completed 500 Internal Server Error in 25ms (ActiveRecord: 4.4ms)
2017-01-17 04:55:07 a948ee3d [app] [F] 
 | ActionView::MissingTemplate (Missing template katello/common/403 with {:locale=>[:en], :formats=>[:html], :variants=>[], :handlers=>[:erb, :builder, :raw, :ruby, :rabl]}. Searched in:
 |   * "/usr/share/foreman/app/views"
 |   * "/opt/theforeman/tfm/root/usr/share/gems/gems/foreman_openscap-0.6.3/app/views"
 |   * "/opt/theforeman/tfm/root/usr/share/gems/gems/redhat_access-1.0.14/app/views"
 |   * "/opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.2.0/app/views"
 |   * "/opt/theforeman/tfm/root/usr/share/gems/gems/foreman_azure-1.2.0/app/views"
 |   * "/opt/theforeman/tfm/root/usr/share/gems/gems/foreman_discovery-7.0.0/app/views"
 |   * "/opt/theforeman/tfm/root/usr/share/gems/gems/foreman_bootdisk-8.0.2/app/views"
 |   * "/opt/theforeman/tfm/root/usr/share/gems/gems/bastion-3.3.4/app/views"
 |   * "/opt/theforeman/tfm/root/usr/share/gems/gems/foreman_ansible-1.3.0/app/views"
 |   * "/opt/theforeman/tfm/root/usr/share/gems/gems/foreman_remote_execution-1.2.2/app/views"
 |   * "/opt/theforeman/tfm/root/usr/share/gems/gems/foreman_docker-3.0.0/app/views"
 |   * "/opt/theforeman/tfm/root/usr/share/gems/gems/foreman-tasks-0.8.2/app/views"
 |   * "/opt/theforeman/tfm/root/usr/share/gems/gems/foreman_theme_satellite-1.0.1/app/views"
 |   * "/opt/theforeman/tfm/root/usr/share/gems/gems/apipie-rails-0.3.6/app/views"
 | ):
 |   katello (3.2.0) app/controllers/katello/application_controller.rb:303:in `block (2 levels) in render_403'
 |   katello (3.2.0) app/controllers/katello/application_controller.rb:302:in `render_403'
 |   app/controllers/application_controller.rb:64:in `deny_access'
 |   app/controllers/application_controller.rb:56:in `authorize'
 |   lib/middleware/catch_json_parse_errors.rb:9:in `call'
 |   lib/middleware/tagged_logging.rb:18:in `call'
 | 
 | 
2017-01-17 04:55:07 a948ee3d [app] [I] Started GET "/organizations/views/organization-selector.html" for 10.36.6.247 at 2017-01-17 04:55:07 -0500

+ Next more complex scenario is also doesn't work.

1. configure LDAP authentication using http://theforeman.org/manuals/1.8/index.html#4.1.1LDAPAuthentication
2. create a user-group with external user-group (example Active Directory)
3. login as a AD user, which is part of the external user-group
4. Re-login as admin user
5. create a org_role via the roles and assign all the "Organization" permissions via the filters.
6. assign the role "org_role" at the user_group level(only after step 3) performed to reproduce)
7. Re-login as AD user
8. Check that org_role is applied and you can access necessary tab (that step works properly)
9. Re-login as admin user
10. create a "location_role" via the roles and assign all the "Location" permissions via the filters.
11. assign the role "location_role" at the user_group level
12. Re-login as AD user
And you will see that second role was not assigned or triggered
And you yes, all these re-logins are required, because if you just assign two roles in a row, AD user has all correct permissions

Strange that I see similar behavior for both last snaps of 6.2 and 6.3. Maybe fix was applied to both branches

This bug has an upstream issue. When this issue is resolved, it will be included in the next Satellite release. We will no longer be tracking this downstream. If you feel this should not have been closed, please feel free to re-open with additional details.