On May 18, 11:22 pm, Chris Forsythe <[email protected]> wrote: > 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.
What do you mean by control here? A whitelist implies that the admin decides which applications can use Growl. I'm not really understanding here. Please clarify. Are you saying that a) Admins should be set a whitelist of allowed apps but a standard user can override that whitelist on their own? or b) End users cannot add alerts for additional apps on their own, but can customize the alerts settings for predefined whitelisted apps In any case, please consider extending the white list to provide alerts style and sticky settings for the whitelist so the admin can set those for consistency throughout the organization. That way, the admin an use the existing MCX settings to deny access to the Growl System Preference altogether, but still manage the alerts through MCX as well. That would work, and require no compromise in the project's foundational goals. > > > > > > > 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 > > athttp://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 > athttp://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.
