Auto-creation of roles

Development
1

After trying to create an "org admin" today[1], I am seeing a lot of merit in an idea @jsherrill suggested: When an org is created, create the roles for that org at the same time. You'll note that there at least are 40(!) filters to create for an org admin (feels like 40 factorial mouse clicks). While I appreciate the granularity as being a requirement, it is insane to think anyone would remain sane at the end of this process. As @ehelms has suggested often, I will augment my weekend ranting emails with more details and suggested solutions.

First, the roles and filters need a new UI and searchable fields. As the number of roles and their contained filters grow, the existing UI breaks down. It is not possible to search by resource (correct me if I'm wrong) nor by permission (again, correct me). Given that there are 40 filters that need to be created, this spans two pages of UI: If I edit one of those filters, please please please don't bring me back to page one and clear my search. This will become a problem if my next suggestion is implemented…

Next, for many resource types it would be fantastic to auto-create roles to match. For example, when an organization is created, simultaneously auto-create an org admin and an org auditor. When a host collection is created, create an admin for that. I think the list of auto-roles won't be too long in the end, but it will save users a lot of time if this can be done.

I will also admit to massive confusion on how to assign organizations and locations to roles. If I put a permission into a location, does that mean the permission is granted to that location regardless of location? If I leave the location blank, does that mean any location or none? Having a way to view the resources that a permission applies to in that context is absolutely necessary, in my opinion. Making roles feels like gambling at the moment: Roll the dice, who knows what objects you'll get admin for.

I will suggest that all devs consider creating themselves an org admin user by hand (use hammer-cli-csv if you are felling lazy) and stop using the built in admin user. It is eye-opening. Good luck!

[1] https://github.com/Katello/hammer-cli-csv/blob/master/test/data/roles.csv#L120

··· -- @thomasmckay

–
“The leader must aim high, see big, judge widely, thus setting himself apart form the ordinary people who debate in narrow confines.” ~ Charles De Gaulle

“Leadership is about making others better as a result of your presence and making sure that impact lasts in your absence.” ~ Harvard Business School

2

Hello,

> After trying to create an "org admin" today[1], I am seeing a lot of merit
> in an idea @jsherrill suggested: When an org is created, create the roles
> for that org at the same time. You'll note that there at least are 40(!)
> filters to create for an org admin (feels like 40 factorial mouse clicks).
> While I appreciate the granularity as being a requirement, it is insane to
> think anyone would remain sane at the end of this process. As @ehelms has
> suggested often, I will augment my weekend ranting emails with more details
> and suggested solutions.
>
> First, the roles and filters need a new UI and searchable fields. As the
> number of roles and their contained filters grow, the existing UI breaks
> down. It is not possible to search by resource (correct me if I'm wrong)
> nor by permission (again, correct me).
You can use searches on filter page like this
"role = "demo1" and permission = view_hosts"

We could add other fields (like resource_type) to search DSL. Also I think we
could allow similar search on roles page. But I agree work with resulting set
is not very comfortable, we should add some tools for actions over multiple
items.

Btw other tools we have - we can either have global roles shared for all orgs
(not sure whether this will change anytime soon) or use clone role to easily
build upon templates.

> Given that there are 40 filters that
> need to be created, this spans two pages of UI: If I edit one of those
> filters, please please please don't bring me back to page one and clear my
> search. This will become a problem if my next suggestion is implemented…

+1

> Next, for many resource types it would be fantastic to auto-create roles to
> match. For example, when an organization is created, simultaneously
> auto-create an org admin and an org auditor. When a host collection is
> created, create an admin for that. I think the list of auto-roles won't be
> too long in the end, but it will save users a lot of time if this can be
> done.

This will work for small number of resource instances. Maybe it could be
optional?

> I will also admit to massive confusion on how to assign organizations and
> locations to roles. If I put a permission into a location, does that mean
> the permission is granted to that location regardless of location? If I
> leave the location blank, does that mean any location or none? Having a way
> to view the resources that a permission applies to in that context is
> absolutely necessary, in my opinion. Making roles feels like gambling at
> the moment: Roll the dice, who knows what objects you'll get admin for.

Would a link to manual on the page or form inline help solve this?

··· On Saturday 17 of May 2014 19:18:40 Tom McKay wrote:

I will suggest that all devs consider creating themselves an org admin user
by hand (use hammer-cli-csv if you are felling lazy) and stop using the
built in admin user. It is eye-opening. Good luck!

[1]
https://github.com/Katello/hammer-cli-csv/blob/master/test/data/roles.csv#L
120

–
Marek

3

> Hello,
>
> > After trying to create an "org admin" today[1], I am seeing a lot of merit
> > in an idea @jsherrill suggested: When an org is created, create the roles
> > for that org at the same time. You'll note that there at least are 40(!)
> > filters to create for an org admin (feels like 40 factorial mouse clicks).
> > While I appreciate the granularity as being a requirement, it is insane to
> > think anyone would remain sane at the end of this process. As @ehelms has
> > suggested often, I will augment my weekend ranting emails with more details
> > and suggested solutions.
> >
> > First, the roles and filters need a new UI and searchable fields. As the
> > number of roles and their contained filters grow, the existing UI breaks
> > down. It is not possible to search by resource (correct me if I'm wrong)
> > nor by permission (again, correct me).
> You can use searches on filter page like this
> "role = "demo1" and permission = view_hosts"
>
> We could add other fields (like resource_type) to search DSL. Also I think we
> could allow similar search on roles page. But I agree work with resulting set
> is not very comfortable, we should add some tools for actions over multiple
> items.
>
> Btw other tools we have - we can either have global roles shared for all orgs
> (not sure whether this will change anytime soon) or use clone role to easily
> build upon templates.
>
> > Given that there are 40 filters that
> > need to be created, this spans two pages of UI: If I edit one of those
> > filters, please please please don't bring me back to page one and clear my
> > search. This will become a problem if my next suggestion is implemented…
>
> +1
>
> > Next, for many resource types it would be fantastic to auto-create roles to
> > match. For example, when an organization is created, simultaneously
> > auto-create an org admin and an org auditor. When a host collection is
> > created, create an admin for that. I think the list of auto-roles won't be
> > too long in the end, but it will save users a lot of time if this can be
> > done.
>
> This will work for small number of resource instances. Maybe it could be
> optional?

After more usage, I would make another suggestion:

  • One builtin role as true "root" users (the existing Manager role, I believe).
  • Every org created should get a Manager role (that org plus all locations)
  • Change interaction with roles to have the organization and location there and not accessible to filters (ie. no code change, just change where org/loc is exposed to user)
  • Each role may have only one org (or none which means "all")
  • Each role may have any number of locations (or none which means "all")
  • Provide a way to copy a role (and all of its filters) to allow easy duplication to new orgs

Suggested auto-create roles:
org admin
org viewer
host collection edit

··· ----- Original Message ----- > On Saturday 17 of May 2014 19:18:40 Tom McKay wrote:

I will also admit to massive confusion on how to assign organizations and
locations to roles. If I put a permission into a location, does that mean
the permission is granted to that location regardless of location? If I
leave the location blank, does that mean any location or none? Having a way
to view the resources that a permission applies to in that context is
absolutely necessary, in my opinion. Making roles feels like gambling at
the moment: Roll the dice, who knows what objects you’ll get admin for.

Would a link to manual on the page or form inline help solve this?

I will suggest that all devs consider creating themselves an org admin user
by hand (use hammer-cli-csv if you are felling lazy) and stop using the
built in admin user. It is eye-opening. Good luck!

[1]
https://github.com/Katello/hammer-cli-csv/blob/master/test/data/roles.csv#L
120

–
Marek

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

4

Taxonomy association of roles makes sense if the underlaying logic remains the
same. One of the reasons for taxonomied filters was that you could have one
role granting view all and edit something just in particular org. When we
group that as you suggest we will have to assign two or more roles to achieve
the same and to forget assigning some role when creating a user may be quite
easy. But I agree that assigning taxonomy on role level would simplify it for
users. If we realize it's a common issue we can always re-enable taxonomies on
filter level (role would be just a tool to set taxonomies for all its filters
but you could still customize them).

Auto creation of role seems as a good idea as well.

··· On Monday 19 of May 2014 09:23:59 Tom McKay wrote: > ----- Original Message ----- > > > Hello, > > > > On Saturday 17 of May 2014 19:18:40 Tom McKay wrote: > > > After trying to create an "org admin" today[1], I am seeing a lot of > > > merit > > > in an idea @jsherrill suggested: When an org is created, create the > > > roles > > > for that org at the same time. You'll note that there at least are 40(!) > > > filters to create for an org admin (feels like 40 factorial mouse > > > clicks). > > > While I appreciate the granularity as being a requirement, it is insane > > > to > > > think anyone would remain sane at the end of this process. As @ehelms > > > has > > > suggested often, I will augment my weekend ranting emails with more > > > details > > > and suggested solutions. > > > > > > First, the roles and filters need a new UI and searchable fields. As the > > > number of roles and their contained filters grow, the existing UI breaks > > > down. It is not possible to search by resource (correct me if I'm wrong) > > > nor by permission (again, correct me). > > > > You can use searches on filter page like this > > > > "role = "demo1" and permission = view_hosts" > > > > We could add other fields (like resource_type) to search DSL. Also I think > > we could allow similar search on roles page. But I agree work with > > resulting set is not very comfortable, we should add some tools for > > actions over multiple items. > > > > Btw other tools we have - we can either have global roles shared for all > > orgs (not sure whether this will change anytime soon) or use clone role > > to easily build upon templates. > > > > > Given that there are 40 filters that > > > need to be created, this spans two pages of UI: If I edit one of those > > > filters, please please please don't bring me back to page one and clear > > > my > > > search. This will become a problem if my next suggestion is > > > implemented... > > > > +1 > > > > > Next, for many resource types it would be fantastic to auto-create roles > > > to > > > match. For example, when an organization is created, simultaneously > > > auto-create an org admin and an org auditor. When a host collection is > > > created, create an admin for that. I think the list of auto-roles won't > > > be > > > too long in the end, but it will save users a lot of time if this can be > > > done. > > > > This will work for small number of resource instances. Maybe it could be > > optional? > > After more usage, I would make another suggestion: > > + One builtin role as true "root" users (the existing Manager role, I > believe). + Every org created should get a Manager role (that org plus all > locations) + Change interaction with roles to have the organization and > location there and not accessible to filters (ie. no code change, just > change where org/loc is exposed to user) + Each role may have only one org > (or none which means "all") > + Each role may have any number of locations (or none which means "all") > + Provide a way to copy a role (and all of its filters) to allow easy > duplication to new orgs > > Suggested auto-create roles: > org admin > org viewer > host collection edit

–
Marek

I will also admit to massive confusion on how to assign organizations
and
locations to roles. If I put a permission into a location, does that
mean
the permission is granted to that location regardless of location? If I
leave the location blank, does that mean any location or none? Having a
way
to view the resources that a permission applies to in that context is
absolutely necessary, in my opinion. Making roles feels like gambling at
the moment: Roll the dice, who knows what objects you’ll get admin for.

Would a link to manual on the page or form inline help solve this?

I will suggest that all devs consider creating themselves an org admin
user
by hand (use hammer-cli-csv if you are felling lazy) and stop using the
built in admin user. It is eye-opening. Good luck!

[1]
https://github.com/Katello/hammer-cli-csv/blob/master/test/data/roles.cs
v#L
120

–
Marek

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.