Comments
-
Greg Hurrell
I agree this would be a good thing to have as an option. The only question is, how should it be done? When I say "how" I'm not so much referring to the technical implementation side as to the user interface side.
There a few options:
1. Remove the "Show root user" and "Open Accounts..." items when running under non-administrator accounts. In other words, it wouldn't be optional, but a blanket thing applied automatically.
2. As above, but instead of removing (hiding) the options, ghost them out.
3. As above, but instead of removing or ghosting, show a dialog when a non-administrator user tries to use them explaining why they can't do it.
4. As per "3", except instead of just showing the dialog actually prompt for a password and allow them access if they enter it correctly. This one is slightly tricky and I am not all that inclined to do it.
5. Provide a special user interface for admin users which allows them to manage the privileges of non- admin users. This could mean having white lists (non-admin users on the list have the privileges but all others don't), black lists (users on the list don't have the privilege if they're on the list, otherwise they do), or a simple check box which turned the privileges on/off for all non-admin users at once.
6. Permit the same kind of customization, but instead of developing a full-blown UI for it make it a command-line-only feature.
There are a couple of questions to be resolved in the cases of options "5" and "6". Like, what happens if one admin tries to set things up a certain way and another tries another way? How is the conflict resolved? How are these system-wide preferences managed in a way that only admin users can change them? Do we have an admin-group writable prefs file in /Library/Preferences/?
Basically, I would want to come up with a proposal that is both elegant (ie. it works simply and it works well) and flexible (ie. it works in a way that everyone is happy with). I don't think it will be that easy, but perhaps through discussion here we can come up with a good plan.
Marking as ASSIGNED.
-
DaMacGuy
This is why you're a developer - I don't think I would have thought of more than half of those options. (grin)
If I had to pick three of those options I'd consider 1, 2, and 4.
1 offers the ability to not confuse users without access to change the options.
2 offers the ability for a user with admin access who migh tbe logged in as another user to recognize that he needs to change to another account.
4 allows the user from 2 to have the ability to still make the change w/out resorting to switching accounts.
Whichever is easiest to implement.
(In reply to comment #1)
I agree this would be a good thing to have as an option. The only question is, how should it be done? When I say "how" I'm not so much referring to the technical implementation side as to the user interface side.
There a few options:
1. Remove the "Show root user" and "Open Accounts..." items when running under non-administrator accounts. In other words, it wouldn't be optional, but a blanket thing applied automatically.
2. As above, but instead of removing (hiding) the options, ghost them out.
3. As above, but instead of removing or ghosting, show a dialog when a non-administrator user tries
to
use them explaining why they can't do it.
4. As per "3", except instead of just showing the dialog actually prompt for a password and allow
them
access if they enter it correctly. This one is slightly tricky and I am not all that inclined to do it.
5. Provide a special user interface for admin users which allows them to manage the privileges of
non-
admin users. This could mean having white lists (non-admin users on the list have the privileges but
all
others don't), black lists (users on the list don't have the privilege if they're on the list, otherwise they do), or a simple check box which turned the privileges on/off for all non-admin users at once.
6. Permit the same kind of customization, but instead of developing a full-blown UI for it make it a command-line-only feature.
There are a couple of questions to be resolved in the cases of options "5" and "6". Like, what
happens
if one admin tries to set things up a certain way and another tries another way? How is the conflict resolved? How are these system-wide preferences managed in a way that only admin users can
change
them? Do we have an admin-group writable prefs file in /Library/Preferences/?
Basically, I would want to come up with a proposal that is both elegant (ie. it works simply and it
works
well) and flexible (ie. it works in a way that everyone is happy with). I don't think it will be that easy,
but
perhaps through discussion here we can come up with a good plan.
Marking as ASSIGNED.
-
Greg Hurrell
Changing assignment to reflect my new email address.
https://wincent.dev/a/news/archives/2006/05/change_of_email.php
-
Greg Hurrell
I'm marking all WinSwitch issues closed seeing as I personally no longer use it, and in fact haven't for around 4 years now.
WinSwitch addressed a real problem with the initial implementation of Fast User Switching in Panther (released October 2003), namely, the excessive screen real estate that it chewed up. Apple fixed that problem in Tiger, if I recall correctly, which came out in April 2005 (or if I'm wrong about it being Tiger, then it was definitely fixed by the time Leopard came out, in October 2007).
With this change, most of the justification for WinSwitch's existence went away, at least for me. So that's why I'm going to close all these tickets: I can't really support something that I don't use myself.
But it's open source, so if any one wants to tackle any of these issues and submit patches, I'll be happy to accept them.
-
Greg Hurrell
Status changed:
- From: new
- To: closed
Add a comment
Comments are now closed for this issue.