in this page I'll try to summarize the current ideas around how to implement Organization and to improve User Groups within Foreman.
|User||A User within Foreman||e.g. Alice|
|Group||Group can include other users and groups||e.g. Developers|
|Organization||A way to manage multiple resources as one, an Org could represent multiple things such as a BU, Location or a Tenant||Location = IL|
|Roles||What can a User / Group do - Set of permissions to all foreman resources||Create new hosts, view dashboard, edit templates..|
|Filters||Which resources can a user work with based on dynamic conditions||e.g. all hosts that belong to Organization IL and member of the groups that start with Dev|
|Move all of the permissions logic into Groups|
Filter per Role and
|Each role would have its own specific Filter per group|
An Organization should provide a way for a user to join Resources as one group.
The main goal here, is to allow the user to use only valid options when creating new resources within foreman, for example:
If you select to deploy a new host via EC2 compute resource, it does not make sense to allow you to use a puppet master within your local intranet.
Further, it should simply the filters which allows a user to see his allowed resources, so instead of saying systems on vmware and belongs to the dev domain, you could simply create an organization which represent that group of systems.
- should hosts belong to more than one org?
- Should we remove hostgroup location (org) based data and move them to Orgs?
- Default value per Org and Resource?
- how to migrate data from hostgroups to default values?
- Org Nesting
- Should permissions be done only via filtering?