I'm going to put that on my list of things to take a look at at some point in the
future. It strikes me that it's one of those UX elements which might be confusing to
some users. The current structure is dictated by PM requirements, right?
Thanks for the quick reply!
On Feb 21, 2012, at 8:38 AM, Scott Seago wrote:
On 02/21/2012 11:33 AM, Kenneth Keiter wrote:
> Ah, interesting. We should come up with a way to remove the requirement of having
those in the name, in the future, so that we can group them in the UI by type.
>
> Thanks Scott!
>
> On Feb 21, 2012, at 8:29 AM, Scott Seago wrote:
>
It's not quite as simple as that. The roles are a collection of lower-level
privileges and, for the most part, they fall into a smaller subset of "useful
combinations (user, owner, etc) -- but especially as I know we're moving in the
direction of even finer-grained permissions in the future, we won't always have such a
predictable set. Also, in the future we'll have a role management UI (for now there is
no UI to manipulate roles) which will allow admins to create/modify roles which define new
combinations of allowed actions on a given resource (or at a global level).
That said, I'm sure there's a way to organize this that improves usability, but I
don't think it's as simple as assuming the current role names are all we'll
need to deal with.
Scott
>> On 02/21/2012 11:04 AM, Kenneth Keiter wrote:
>>> From a user experience standpoint, you're fine here. If everything else
is in "<object> user" format, those should be too, unless there's a
technical reason (which would be more than a little weird).
>>>
>>> I think it's a bit odd, overall, to have the "user" suffix
appended to every role name -- isn't it apparent in the UI which user you're
connecting with which role, or must there be redundancy?
>>>
>> It's certainly not on every one -- in fact, 'User' is used as opposed
to 'Owner' or 'Administrator' or some such. So in this case 'user'
is not an example of redundancy -- it indicates a level of access less than that of an
owner or admin or similar.
>>
>> For example, a "Pool User" has access to a pool, can launch
deployments, etc but can't edit the pool or see/modify anyone else's instances. A
"Pool Owner", however, has full access to the pool -- edit pool properties,
start/stop anyone's instances in the pool, etc. Also, it's not<object> user
-- the role is "<object-type> user" (or "<object-type>
owner", etc., but it's applied to a specific object. i.e. as a user, I may have
the "Pool owner" role on "pool1" but "Pool user" role on
"pool2" -- the role is defined as "Pool user" not "pool1
user" -- but it's _assigned_ to me on a specific pool -- but I may have different
roles on different pools.
>>
>> Scott
>>
>>> --
>>> Kenneth Keiter
>>> Sr. Software Engineer, Cloud BU
>>> kenkeiter(a)redhat.com
>>>
http://twitter.com/kenkeiter
>>> IRC: tigger or tiggerer
>>>
>>> On Feb 20, 2012, at 2:50 PM, Jason Guiditta wrote:
>>>
>>>> Hello list,
>>>> I was just looking at seeds.rb to see about extracting our role names
>>>> into i18n files so we can leverage the configuration I added there
>>>> last week, and noticed what seems to me to be a minor inconsistency.
>>>> Disregarding role with the name 'Administrator', it seems most of
our
>>>> roles are named:
>>>> "{object name} user"
>>>> or
>>>> "{object name} owner"
>>>>
>>>> There are 2 exceptions I see to this - the Instance and Deployment
>>>> objects. These both use 'Controller' instead of 'User'.
>>>>
>>>> I would like to propose making those consistent as part of
>>>> the patch I am working on, unless there is some reason they are like
>>>> this of which I am unaware. Thoughts?
>>>>
>>>> -j
>>>>
>>>
> --
> Kenneth Keiter
> Sr. Software Engineer, Cloud BU
> kenkeiter(a)redhat.com
>
http://twitter.com/kenkeiter
> IRC: tigger or tiggerer
>
>
>
--
Kenneth Keiter
Sr. Software Engineer, Cloud BU
kenkeiter(a)redhat.com