/**********************************************************************/
/** Microsoft LAN Manager **/
/** Copyright(c) Microsoft Corp., 1990, 1991 **/
/**********************************************************************/
/*
uissues.txt
User Tool func spec issues
Note. The rule is, you may add to this file, but you may not delete
any items.
FILE HISTORY:
rustanl 24-Jun-1991 Created. Added feedback on NT
Windows User Manager (change bar
version), revision 1.1.
jonn 29-Jul-1991 Added Big Issues section at beginning
jonn 29-Oct-1991 Added CURRENT ISSUES section at beginning
*/
CURRENT ISSUES
This section lists current issues, both unresolved issues, and resolved
issues which aren't yet in the spec. It is permitted to remove items if
they are resolved _and_ updated in the latest spec. Please see the User
Manager schedule for a complete list of "Post-Halloween" items.
ADMINS/USERS/GUESTS: The specced functionality for renaming these
groups to "Domain Users" etc. is a real nightmare. Can we drop this and
just leave them with their original names?
User Enumeration: There are three enumeration APIs and three host
platforms:
NetUserEnum[10] I_NetUserEnum2 NT/NetUserEnum
LanMan20 X
LanMan21 X X
NT X X
Which API/APIs we use depends on which platforms we intend to support.
NetUserEnum[10] is not resumable and therefore not well-suited to
domains with many users.
Local Administration: We do not currently support making an ADMIN a
member of any operator rights group. However, on a machine on which the
"Domain admin -> local admin" bit is off, the only way for a remote
admin to administer the machine is to be a member of these operator
rights groups.
Group Memberships: If all selected users are members of more than one
of the GUESTS/USERS/ADMINS groups (on an NT server), do we display this
fact in this subproperty dialog? Or do we pretend that membership in
these groups is based solely on the user's simulated privilege level?
Phantom Groups: How do we prevent the creation of groups named e.g.
"Domain Users" or "Domain Account Ops" on a LanMan2X domain? Should the
API do this? MNet?
Logon Hours: Do we do this?
Changing Logon Name: Do we do this?
Parms field: Spec should note settlement of this issue.
BIG ISSUES
[Please tab subsequent comments and resolutions 4+ spaces to the right.]
Multiple selection of users: do we support?
JonN/RustanL: The User Tools is pretty lame if we don't. We may
refuse to bring up some subdialogs if the selected users differ.
Multiple selection of groups: do we support?
JonN/RustanL: This is about half of the work of user multiselect and
about 1% as useful.
System Groups: Are these handled as groups or as radio buttons?
Operator Privileges: Are these handled as groups or as checkboxes?
PDC unavailable: Do we allow Properties dialogs? Do we allow Set Focus
on such a domain at all?
Find User / Set Selection: which do we support (if either)?
Changing Logon Name under NT: how?
Logon Script / Home Directory: supported? where?
Logon Hours: supported? punted?
Section 1. Functionality of the Tool
"Accounts operator privilege may be redefined [...]".
Using groups instead of operator rights is a good idea in the
long term. However, now is not the time:
If the UI maps groups to operator privileges, then the
mapping NetAPI may have to map back to groups for NT.
If these two mappings are not one-to-one, there may be
problems displaying and entering the right stuff.
Since the same UI will be used in LM 2.2, it seems strange
to move operator privileges to groups without a new
major release of the product.
Section 2. Invoking the Tool
USERMGR.exe or USRMGR.exe?
Section 2. Invoking the Tool. Next to last line, page 5.
"Select Domain dialog". This is not sufficient for focussing
on down-level (and may not be sufficient for up-level either).
Instead, revert to allowing focus to be set to servers
or domains.
Section 2. Invoking the Tool. Last line, page 5.
"[...] an error message box is displayed above it".
This is obsolete. Instead, first display the error, and then
bring up dialog.
Same comment a few paragraphs down.
Section 3. Main Window.
Nice column-header bars!
Bitmaps cannot only exist in header, but must reside next to
each item, so as to indicate drag-and-drop support, and to
show difference between different users (see also the Server Tool).
Note, don't be fooled about the "Ticketing Agents" contents
displayed in the group pane. Spaces are currently not valid group
characters, and we don't do anything too fancy with upper/lower-
case letters. Need to specify how group names are upper/lower-
cased.
Section 3. Main Window.
"Issue: do we need to have vertical splitter bars?"
Yes. Users will like to customize the size and layout of the
window.
Section 3.1. Upper Client Area.
Should mention that upper and lower client areas are multiple
select listboxes (group pane needs it not for Properties, but
for initial group membership for new groups). Also, mention
that there will never be a selection in both upper and lower
panes at the same time.
The text about icons next to each user/group displayed should
revert back to old spec. In other words, icons are needed, and
should be displayed next to each user.
Section 3.1. Upper Client Area.
"Do we want to retain icons for each user account to show the
priv. level and whether it is enabled or not?"
Yes.
Down-side: These require a different info level and will thus be more
expensive to retrieve from network.
Up-side: Good to be consistent with server tool.
Mentioned down-side does not really affect the space
needed on local machine, since superfluous data can
be discarded, once retrieved from network.
Section 3.1.1. Down-level Variation
"Why is the order [...]? Is this [...]?"
Correct.
There should also be an option to change the sorting order
from the View menu.
"Will SAM have [...]?"
No, they are fullnames.
"Does LM 1.x have user security?"
Nope.
Section 3.3. Drag and Drop Actions.
Needs a dialog taking the form of a MsgPopup with a listbox.
This is used in several placed in the User Tool, but is
not (currently) on anyone's schedule.
Section 3.3. Drag and Drop Actions.
"Is it inconsistent that you can drag a user INTO a group, but
not back out again. [...]"
Punt. Too much work (programmer time and run-time) to show group
memberships here. The alternative of allowing dragging a user
outside the window change a group membership is too dangerous to
do--it is too easy to do accidentally!
Section 4.1. Action Bar Errors When the PDC is Unavailable
"[...] is displayed unmapped, and then an OK/Help [...]".
^^^^
So, two popups are displayed???
"[...] You cannot make changes to the security settings at this
time."
Does this part of the message always stay the same, or does it
change depending on what task is being performed?
"The user is then returned to the main window without invocation
of the appropriate dialog, or is presented with a special variant
dialog"
In the former case, the popup should be of severity error, and in
the latter case it should be of severity warning.
Section 4.2. The User Pulldown.
"Note that the Standards Document may be inconsistent with
this placement of the Copy and Delete commands."
Yes, and there is a good reason for putting the Copy and Delete
options from the User menu. They should be moved back there.
This "Copy..." does not copy to the clipboard, but rather
provides an initialized version of "New...". One may consider
renaming it "Duplicate..." or "Clone..." to make the distinction
clearer.
This "Delete" option does not delete to the scrap. Hence,
it, too, does belong in the User menu, and not the Edit menu.
Section 4.2.2. New User...
"[...] otherwise the user's group memberships are left uninitialized."
Unless for System gropu, which get the "User" default"
What if more than 1 System group is selected? Where/when is the
error produced?
Section 4.2.3. New Group...
"[...] page 57"
Bogus. Should be "section 4.1"
Section 4.2.4. Properties...
"[...] the Properties dialog is then produced, with all controls
filled with the correct values, but disabled so that no changes
can be made."
Where do these come from is the PDC is down? In other words,
which backup DC should we select for getting the info? Perhaps
the first one returned from NetServerEnum2?
Section 4.2.4. Properties...
"or a selection of one or more groups"
Nuke "or more".
Similarly, last bullet in this section: "multiple-selection
group properties dialog". Not so interesting. Thus, nuke.
Section 4.2.4. Properties... Second bullet (deleted).
Reintroduce this bullet.
"There are plans to reintroduce either multiple user selection or
a primary group management scheme"
Choose the multiple user selection.
Section 4.3.1. Copy...
(As mentioned above, Copy... and Delete need to move back to
User menu.)
The Copy... menu item should be disabled if the listbox selection
contains other than one item (user or group).
Section 4.3.1. Copy...
"[...] copied over except [...] First and Last Names, Initials,
[...] Password Age, Parms".
Should only copy fullname (besides, first and last names, and
initials don't really exist, anyway).
Why not copy Password Age and Parms?
Section 4.3.1. Copy...
"How does [the event of selecting a group] work? Can you have
a selection in BOTH the Users pane and the Group pane?"
Nope, selection never occurs in both panes. The feature described
(Copying a Group) is a different one from Copying a user.
Section 4.3.2. Delete
"The group %1% cannot be deleted"
May also want to give indication that operation will cancel.
Otherwise, it is unclear if clicking OK will delete the rest of
the selected groups or not.
Is displaying this message done once if a system group is part
of the selection? That should be so, and the operation should
be cancelled immediately afterwards.
Section 4.3.2. Delete
About the (deleted) text on the home directories: Good that
we are deleting, even if homedirs stay around. This is tedious,
and probably not too valuable.
Section 4.3.3. Find
I suggest we punt the Find dialog.
We do need a Set Selection dialog, though. We can possibly add
the SID to it, and have it scroll to the item it just highlighted.
Matching the SID may be a time consuming operation, depending
on what API support we get, and what we decide to store in the
listbox.
Wouldn't it even be much nicer if we could remove this altogether.
This means a user cannot (easily) map a SID to a username.
I think that's fine: We want the user to think of accounts
as names, not numbers. Moreover, we only reveal the SID in the
one dialog that allos the user to change the name of an account.
My suggestion: Punt not only the Find dialog, but also the
finding/searching/selection-setting SID functionality.
Section 4.5.1.2. Behaviour [of Security Settings dialog]
Password Content control.
I assume this is up-level only.
Section 4.5.1.2. Behaviour [of Security Settings dialog]
"The Domain static text [...]"
What if a server is selected? Then, the text should read
"Server:".
Section 4.5.2. Select Domain/Focus
This dialog must allow the user to select a server as well.
We will certainly encourage the user to admin entire domains,
but we cannot toss out the admining server functionality.
Thus, this dialog should revert back to being a Set Focus dialog.
Section 4.5.2.2. Behaviour [of Set Focus dialog]
"[...] NEW 'Set Focus' dialog".
Once this new dialog is added to the spec (see implementation
in ADMIN_APP), need to add details on when domains are toggled.
The behavior differs from the Browser, but the spec should say
by how much.
In the new Set Focus dialog, the default selection is not the
first item, but the logon domain.
"[...] the UI will find the primary domain controller [...]
and will be able to write changes to it. [...] however,
indicate that focus is on the specified server."
This is too complicated. We could instead try to prevent
users from selecting such servers from the Set Focus dialog,
or at least warn them about that.
"Is is reasonable to suppose [...]"
Seems unlikely, especially if one is claiming to be the
administrator of the domain.
The way the listbox is used in the Browser, it allows the
user to type the name of a server. This server will then be
added to the listbox, and so will the domain in which it
existed (if not already in listbox). Could a similar behavior
be used here? Although not used the same way here as in the
browser, I think it would be nice to keep the same functionality
of the Set Focus dialog as exists in the browser.
Section 4.5.2.3. Errors
"You typed an invalid [...]"
Is this validation (and display of the message) done before
or after the dialog is dismissed? (If after, the dialog
would be brought up anew.)
Section 5.1. Properties Dialog (single selection)
"Why are the graphical buttons not disabled?"
I presume the contents of them are.
Section 5.1.2. Philosophy
"Although the account is enabled by default, the control for
enabling accounts is presented in this dialog [...]"
May need more opinions.
Section 5.1.4. Behaviour [of the Properties Dialog (single selection)]
"The Logon name field is a static text field"
We need to offer a facility to change this name under NT.
I suggest doing from the "Account" or a new "Name" sub-property
sheet. This should be the only place where the SID is exposed.
Whatever mechanism is chosen, the same one should be used for
changing group names in the Group Proprerties dialog.
"The Last name field [...]. The First name field [...]."
How are last and first names parsed from full name. Should we
perhaps just offer a fullname field?
Also, on next page, "The Full name field [...] is set to a
concatenation of the Last and First Names". This may not
follow the same rules in other countries. Much easier to
simply leave as fullname.
Strike any text pertaining to an Initials field, and remove this
field from picture.
Section 5.1.5. Down-level Variation
"[...] LM 2.x and LM 1.x UAS databases [...]."
Only fullname.
JonN 2-Aug-91: Note for future reference: It is not permitted to
make an accounts operator (any operator??) a guest, and the
error message for ERROR_INVALID_PARAMETER should mention this.
Section 5.2. Multiple Selection Subclass
Needed. Should be undeleted.
"Multiple selection of users [...]. [...] two forms:
1) [...] inheritance model [...] 2) mutliple selection of users".
Use multiple selection of users. This is a model we know, and
that the API supports.
Section 5.4.3. Behaviour [of Account Information dialog"
Did we lose the pretty (sexy?) bitmaps next to the
Admin/User/Guest radiobuttons? We should reintroduce.
Do need operator rights in this release. These are needed
for downlevel and LM 2.2. Moreoever, if we used groups,
the UI would need to map to operator rights before calling
the mapping Net API, which, in turn, would map these back
to groups for NT administration. Hence, both the UI and the
API do mapping: unacceptable!
"The Domain password contraints [sic] are not enforced."
Does the UF_PASSWORD_NOTREQD flag relax all password constraints,
or will it enforce them only when a password is submitted?
"If use of this checkbox is to allow Guest accounts to not
have passwords, perhaps we can make this option more closely tied
to being a guest account."
Good point.
"Security ID [...]"
Should only be visible where logon name can be changed.
"What "clipping" rules should apply for displaying SIDs?"
How about a read-only SLE? (Available in Win 3.1.)
"The Logon script path entry field"
Still needed for down-level, no?
Section 5.4.6. Errors
"If the administrator chooses to change his own privilege level
and operator rights [...] If the user chooses OK, [changes are
made], the [...] dialog is cancelled, and the Set Focus dialog
appears. Cancelling that dialog terminates the application.
Is this really necessary? Big dev, test, and doc hit for little
gain.
How about instead continuing to run the application, displaying
errors as they appear?
Or, how about disallowing an admin to change his own account from
being an admin. That would also get around the fear mentioned
on the previous page: "Is there built-in prevention from getting
rid of the last Admin account?".
Section 5.5. Group Memberships
Should also be available for a multiple selection of users.
Section 5.5.3. Behaviour [of Group Memberships]
"Initial focus is in this control with the first item cursored
[...]"
May want to add note that a first item does indeed exist (because
of the required membership in a System group"
#ifdef INTERESTED_IN_USING_NICER_LANGUAGE
"There may be a selection in only (zero or) one of the [...]"
Change "only (zero or)" to "at most".
#endif
"(or null, of course, if no items are left in the list)"
(This text appears in two different places.) Should a focus
rectangle be shown? What the listboxes in Winnet do is disable
the listbox when there are no items in it. Can this behavior
be used here?
Section 5.6. Home Directory
Reintroduce.
"What is the downlevel solution?"
Needed, but can simplify dialog, but replacing listbox
with an SLE. Also, Volume button goes away.
Section 5.6.2. Behaviour
"The OK button [...] attempts to create or configure the
home directory: [...]"
Yeach.
Section 5.6.3. New User Defaults
"The `Home directory assigned' radio button is pressed initially."
I suggest setting `No homedir' instead.
Section 5.7.5. Errors [of Valid Logon Hours dialog]
"[...] OK information message box is displayed"
Is would be nice to be able to turn this off somehow.
Section 5.8. Candidate/Valid Logon Workstations
The newly proposed dialog is a nicer model. If this will
be the final dialog, it should not use a simple combo, but
rather an SLE, Add and Remove buttons, and a listbox.
Set design of this dialog to low priority right now.
We already have code for it, and have no time scheduled
to revisit. Suggestion: Roll back to old model and work out
details later, OR leave as is and come later.
Section 5.8.3. Behaviour
"Will we have a workstation browsing capability?"
Nope.
Section 5.8.5. Errors
If newly proposed dialog is used: Should also display error
if down-level and more than 8 workstations are mentioned.
#ifdef INTERESTED_IN_USING_NICER_LANGUAGE
"Each workstation appears a maximum of once is in the list."
Change to "[...] appears at most once [...]".
#endif
Section 6.1. Group Properties Dialog (Single)
As mentioned above, need facility to change group name under NT.
Section 6.1.3. Behaviour
"If this dialog is invoked for any of the three 'privilege' groups
[...]"
Make this check at OK-time instead, as discussed in email
between rustanl and davidtu.
Section 6.1.3.1. Errors
"Choosing Cancel is equivalent to hitting Cancel in the dialog
itself."
Bad idea. Return to dialog instead.
Section 6.2. The Multiple Selection Subclass
Nuke.
Use idea of showing membership intersection when writing
up Multiple Selection of Users, Group Membership dialog.