Given the following task, "create a host group," what permissions are required?
create_host_group
- Certainly needed
view_host_group
- Not strictly needed, but probably useful?
- Required to view "Parent" choices
view_domain
- Required to view domain choices
view_subnet
- required to view subnet choices
view_architecture
view_operating_system
view_media
view_partition_table
view_location
view_organization
In the UI currently (on @mhulan branch, which likely has not touched implementing role/perm in the UI):
create_host_group
view_host_group
- required to see menu entry
Once on the page, all the available choices are available to view (ie. I can see all available domains, subnets, etc.). Is this the correct behavior? This effectively prevents the admin from hiding anything from users.
Note too, that the hammer cli (via api) is entirely locked off. Is this expected behavior? It's contrary to the UI where items can be listed.
I would suggest that the UI needs to honor the role/perm and filter what is displayed on the user's permissions.
Assuming that is the case, how do we make a more sensible role creation user experience? As @jsherrill suggested, "A role creator should not have to login as the user to see if they did it correctly."
···
--
@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
Sorry for late answer. New permissions should be compatible with old system
(at least this is scope of #812). In old system e.g. if user has permission
create_hostgroup it means he can select any architecture and it's not checked
whether he has view_architectures permission or even some subset of them.
In new system with granularity it makes sense to limit also architectures but
I think it should be another issue. Also it's not clear whether adding
hostgroup to architecture is 'viewing architecture' or 'editing architecture'
but I'd vote for viewing probably.
Some permissions are used though, for parent hostgroup choices and domains.
···
--
Marek
On Monday 17 of February 2014 14:56:49 you wrote:
Given the following task, “create a host group,” what permissions are
required?
create_host_group
- Certainly needed
view_host_group
- Not strictly needed, but probably useful?
- Required to view “Parent” choices
view_domain
- Required to view domain choices
view_subnet
- required to view subnet choices
view_architecture
view_operating_system
view_media
view_partition_table
view_location
view_organization
In the UI currently (on @mhulan branch, which likely has not touched
implementing role/perm in the UI):
create_host_group
view_host_group
- required to see menu entry
Once on the page, all the available choices are available to view (ie. I
can see all available domains, subnets, etc.). Is this the correct
behavior? This effectively prevents the admin from hiding anything from
users.
Note too, that the hammer cli (via api) is entirely locked off. Is this
expected behavior? It’s contrary to the UI where items can be listed.
I would suggest that the UI needs to honor the role/perm and filter what is
displayed on the user’s permissions.
Assuming that is the case, how do we make a more sensible role creation user
experience? As @jsherrill suggested, “A role creator should not have to
login as the user to see if they did it correctly.”
–
Marek
