Bug #9506

Filter with permission edit_config_groups is not actually limited by search expression

Added by Roland Leissl over 7 years ago. Updated almost 4 years ago.

Users, Roles and Permissions
Target version:
Bugzilla link:
Fixed in Releases:
Found in Releases:


I try to restrict access to specific config groups for a specific user. The new role should be able to filter the available config groups through their names. Therefore this user should not be able to change production relevant config groups.
I would need to use this feature in a real world DevOps scenario.

- create a new role and add filter 1 for host class permissions.
- select items "edit_classes" for filter 1.
- create filter 2 with config group permissions.
- select items "view_config_groups" and "edit_config_groups" for filter 2.
- uncheck unlimited checkbox for filter 2.
- enter search expression into search textbox like "name != production-apache" for filter 2.
- associate the role with restricted user.
- create config group with a name like "production-apache"
- login with the restricted user.
- on the menu go to configure - config groups.

expected result -> the user should not be able to view or edit config groups with the string "production" in their names.
actual problem -> the user is allowed to view and edit all config groups, even ones with matching names to the exclusion search expression.

Thanks for your attention,

Related issues

Related to Foreman - Bug #10923: Permission behaviour not consistentNew2015-06-24

Associated revisions

Revision 6825f8de (diff)
Added by Marek Hulán about 7 years ago

Fixes #9506 - Add granular permissions to config groups

Revision 787d5795 (diff)
Added by Marek Hulán about 7 years ago

Fixes #9506 - Add granular permissions to config groups

(cherry picked from commit 6825f8de6debe3854e03d171f6de5b630bfc85b9)


#1 Updated by Thomas Kuther about 7 years ago

I can reproduce this on our local instance.

It seems like "Host class > edit_classes", which provides no search filter itself, causes this "all-or-nothing" condition.

If a role has that right, it can add/remove classes from config groups with a != matching search filter
(i.e. the filter is set to "name != production-apache-servers", and still, the role can fully edit that group)

Vice versa: if it doesn't have edit_classes, it cannot add/remove classes from a config group even the search filter should allow it.

I didn't have any chance to dive into the code yet. Is the missing piece maybe a search filter for edit_classes?

#2 Updated by The Foreman Bot about 7 years ago

  • Status changed from New to Ready For Testing
  • Pull request added
  • Pull request deleted ()

#3 Updated by Marek Hulán about 7 years ago

  • Assignee set to Marek Hulán

#4 Updated by Dominic Cleal about 7 years ago

  • Legacy Backlogs Release (now unused) set to 50

#5 Updated by Marek Hulán about 7 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100

#6 Updated by Dominic Cleal almost 7 years ago

  • Related to Bug #10923: Permission behaviour not consistent added

#7 Updated by Shimon Shtein over 6 years ago

  • Bugzilla link set to 1284475

Also available in: Atom PDF