On May 18, 2010, at 10:18 PM, sourcehound <[email protected]> wrote:
On May 18, 9:04 am, Christopher Forsythe <[email protected]> wrote:
On Tue, May 18, 2010 at 2:36 AM, Peter Hosey <[email protected]> wrote:
On May 18, 2010, at 00:33:34, [email protected] wrote:
Then users like me who don’t like to be told how to use their
computer by
their admin still have full control over their notifications
(provided they
can reach the prefpane/know how to dive into the ticket).
That depends on whether we should uphold our own long-standing
policy of
users having ultimate control, or let admins use the whitelist to
override
them.
I think we should maintain this, and can maintain it, while adding
the white
list feature.
What I think we should do is have the strike through like Peter
mentions,
and the white list. Add in the "ignore my admin" hidden default,
and I think
that solves the problem i.atent.dead has.
The only other thing we need to do is make sure it's apparent that
this is
what's happening, so that the user knows what is going on, if they
are like
i.atent.dead.
I don't like the disable everything on registration, because then
it's a lot
of work to get it back to how users like things, if they know
enough to know
they want to enable it all. It'd be easier for them to get going
with a
quick defaults command.
Chris
OK, if you add a white list feature, it should not be able to be
overridden by end user in any case.
This overrides one of our main goals, giving users the control. I'm ok
with a white list, but the end user must have control.
You cannot share control in a
managed environment. When Growl detects the presence of the white list
key and the array of allowed apps, it should simply inform the end
user that the notifications are being managed by their administrator -
and such a convention for System Preferences already exists - add a
"Lock" and use the Security Framework to require authentication to
change any settings in Growl. Now wait before you lose your lunch....
If the managed preference and whitelist do not exist, any user can
unlock the lock, or it is unlocked by *default*. However, if the
management key is in place, the lock is locked by default, and
requires an admin user to authenticate to unlock the
system.preferences right in /etc/authorization.
It's really simple.
1) Growl is working in unmanaged mode, lock is unlocked standard users
can change settings
2) Growl is working in managed mode, lock is locked, admin username/
password required to change any settings or start / stop the Growl
Helper App (simply enable all the controls once the lock is unlocked)
3) Additionally, the whitelist array should support other keys, such
as stickness and alerts style so the admins can control those with
granularity as well
I think using the SFAuthorizationView lock just works, no explanation
or hidden preferences needed - and any user would be able to
understand what was going on.
--
You received this message because you are subscribed to the Google
Groups "Growl Discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected]
.
For more options, visit this group at http://groups.google.com/group/growldiscuss?hl=en
.
--
You received this message because you are subscribed to the Google Groups "Growl
Discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/growldiscuss?hl=en.
