windows-nt-4.0/private/net/ui/admin/user/doc/uissues.txt

/**********************************************************************/
/**			  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.