On 2/17/2012 6:08 PM, Charles Crouch wrote:
>
> ----- Original Message -----
>> That seems sensible, and consistent with the opt-out approach
>> commonly
>> taken by companies for customer privacy.
>>
>> I guess it depends what the requirement is - does the admin want
>> the
>> ability to prevent his users from seeing each others details, or
>> would they be happy as long as their users had some way to make
>> their
>> details private if so desired?
> I think its the latter, i.e. not opt-in/opt-out...
> Quote from the customer:
> "What we want to do is allow developers to view app server resource
> performance information. We can already do this by restricting a
> role to sub system permissions like "measure". Adminstrators would
> of course have much greater access. However for developers, no JON
> account information should be exposed to them in any form."
>
> So this sounds like a role based approach would give them the
> flexibility they need.
To maintain back compatibility we'd need to ensure that hiding info
was
not the default. Then again, I'm not sure we need back compatibility
for this.
I think backward compat is important here, otherwise we're going to be hearing from
people about why the click through to a user's information doesn't work anymore.
So I agree hiding info should not be the default.
>
> Cheers
> Charles
>> On 02/17/2012 05:42 PM, Jay Shaughnessy wrote:
>>> How about if the user can control whether his info is public or
>>> not?
>>>
>>>
>>> On 2/17/2012 5:35 PM, Ian Springer wrote:
>>>> That would be more work implementation-wise, but if you think
>>>> that
>>>> level of granularity is required, that sounds like a good way to
>>>> go.
>>>> One possible use case is an admin wanting to make user details
>>>> visible to employees, but hide them from contractors.
>>>>
>>>> In either case, should hiding user details mean hiding
>>>> everything
>>>> or
>>>> still leaving things like full name and department visible?
>>>>
>>>> On 02/17/2012 05:10 PM, Charles Crouch wrote:
>>>>> Doesn't it make more sense for this to be part of the
>>>>> permissions/role infrastructure, rather than server wide
>>>>> setting?
>>>>> e.g.
>>>>>
>>>>> VIEW_USER_DETAILS: True/False
>>>>>
>>>>> We could add the permission to all existing roles and set it
>>>>> True
>>>>> When you are creating a role, it would be defaulted to True,
>>>>> but
>>>>> an
>>>>> admin could choose to turn it off for particular roles.
>>>>>
>>>>> Cheers
>>>>> Charles
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> Yeah, ideally I would just leave everything public too, but
>>>>>> the
>>>>>> BZ is
>>>>>> saying we should hide everything, so I was trying to find some
>>>>>> sort
>>>>>> of
>>>>>> compromise. Perhaps it should be configurable via a server
>>>>>> setting,
>>>>>> e.g.:
>>>>>>
>>>>>> [ ] yes [x] no - Hide User Details - hide details of users
>>>>>> from
>>>>>> non-admin users
>>>>>>
>>>>>> The setting could be false by default, which would keep things
>>>>>> the
>>>>>> same
>>>>>> as they've always been by default, but give admins who are
>>>>>> hardcore
>>>>>> about privacy a way to hide the details.
>>>>>>
>>>>>> On 02/17/2012 04:37 PM, John Mazzitelli wrote:
>>>>>>> I would leave phone and email open. Because if you see
>>>>>>> something
>>>>>>> bad
>>>>>>> happening on a resource that a user modified or owns or
what
>>>>>>> have
>>>>>>> you,
>>>>>>> you will want to get in touch with them. Being able to find
>>>>>>> the
>>>>>>> email/phone would be helpful.
>>>>>>>
>>>>>>> Hiding phone/email from everyone except for MANAGE_SECURITY
>>>>>>> users
>>>>>>> seems
>>>>>>> less useful.
>>>>>>>
>>>>>>> On Fri, 2012-02-17 at 16:33 -0500, Ian Springer wrote:
>>>>>>>> I'm working on
>>>>>>>>
https://bugzilla.redhat.com/show_bug.cgi?id=786159.
>>>>>>>>
>>>>>>>> Currently, a regular user can view the following
details
>>>>>>>> about
>>>>>>>> any
>>>>>>>> other
>>>>>>>> user (via #Administration/Security/Users):
>>>>>>>>
>>>>>>>> username
>>>>>>>> first name
>>>>>>>> last name
>>>>>>>> department
>>>>>>>> email
>>>>>>>> phone
>>>>>>>> login enabled?
>>>>>>>> ldap user?
>>>>>>>>
>>>>>>>> The assigned roles of other users cannot be viewed.
>>>>>>>>
>>>>>>>> I propose we change it so they can only view the
following
>>>>>>>> fields:
>>>>>>>>
>>>>>>>> username
>>>>>>>> first name
>>>>>>>> last name
>>>>>>>> department
>>>>>>>>
>>>>>>>> I think it makes sense to keep these basic details
public,
>>>>>>>> because
>>>>>>>> it's
>>>>>>>> useful to know the real name and department for other
users
>>>>>>>> in
>>>>>>>> the
>>>>>>>> system. For example, if I see that user pilhun deleted
my
>>>>>>>> WAR
>>>>>>>> a
>>>>>>>> few days
>>>>>>>> earlier, it would be nice if I could find out that
pilhun is
>>>>>>>> Heiko
>>>>>>>> Rupp
>>>>>>>> from the JON dev team (facts not obvious from the
username),
>>>>>>>> without
>>>>>>>> having to go find an RHQ Admin and ask them. I can see
>>>>>>>> hiding
>>>>>>>> people's
>>>>>>>> phone number and email address for privacy purposes.
I'm up
>>>>>>>> in
>>>>>>>> the
>>>>>>>> air
>>>>>>>> about the two boolean fields.
>>>>>>>>
>>>>>>>> Users with MANAGE_SECURITY would of course be able to
view
>>>>>>>> and
>>>>>>>> edit all
>>>>>>>> details for all users, as they can today.
>>>>>>>>
>>>>>>>> Please let me know if you have an opinion on this, as
I'd
>>>>>>>> like
>>>>>>>> to
>>>>>>>> come
>>>>>>>> up with a plan so I can implement it next week.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Ian
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> rhq-devel mailing list
>>>>>>>> rhq-devel(a)lists.fedorahosted.org
>>>>>>>>
https://fedorahosted.org/mailman/listinfo/rhq-devel
>>>>>>> _______________________________________________
>>>>>>> rhq-devel mailing list
>>>>>>> rhq-devel(a)lists.fedorahosted.org
>>>>>>>
https://fedorahosted.org/mailman/listinfo/rhq-devel
>>>>>> --
>>>>>> Ian Springer
>>>>>> Principal Software Developer
>>>>>> JBoss Operations Network
>>>>>> Red Hat
>>>>>> ian.springer(a)redhat.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> rhq-devel mailing list
>>>>>> rhq-devel(a)lists.fedorahosted.org
>>>>>>
https://fedorahosted.org/mailman/listinfo/rhq-devel
>>>>>>
>>>>> _______________________________________________
>>>>> rhq-devel mailing list
>>>>> rhq-devel(a)lists.fedorahosted.org
>>>>>
https://fedorahosted.org/mailman/listinfo/rhq-devel
>>>>
>>> _______________________________________________
>>> rhq-devel mailing list
>>> rhq-devel(a)lists.fedorahosted.org
>>>
https://fedorahosted.org/mailman/listinfo/rhq-devel
>>
>> --
>> Ian Springer
>> Principal Software Developer
>> JBoss Operations Network
>> Red Hat
>> ian.springer(a)redhat.com
>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel(a)lists.fedorahosted.org
>>
https://fedorahosted.org/mailman/listinfo/rhq-devel
>>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel