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