on 3/10/03 8:56 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > ----- Original Message ----- > From: "Kurt Bigler" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Monday, March 10, 2003 7:35 PM > Subject: Re: [sqwebmail] Re: logindomainlist patch > > >> on 3/10/03 12:33 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: >> >>> On Monday 10 March 2003 15:27, Kurt Bigler wrote:
[snip] >> Well, I looked, and all I found were a couple of points for the >> documentation. I only checked briefly, but I don't think these two points >> have made it into the doc, at least not completely. I think the same >> concepts apply, although the surrounding details have changed. >> >> >> >> on 3/1/03 7:46 PM, Kurt Bigler <[EMAIL PROTECTED]> wrote: >> >>> As I recall, this "original" functionality can result in 4 ways: >>> (1) no logindomainlist file >>> (2) no match found in the logindomainlist file >>> (3) matching entry has first field empty >>> (4) matching entry enables popup list, and the blank entry is chosen >>> >>> (Possible notes there for the documentation.) > > I think this list is a little loose in it's wording. Absolutely, the above wasn't meant to be documentation - just notes. > Here's my take: > > Currently, the logindomainlist functionality can be totally disabled > in the following ways: > > (1) no logindomainlist file > (2) no match found in the logindomainlist file > (3) matching entry has first field empty, and an * or @ is in the third field > > And this item: > > ( ) matching entry has first field empty, and third field is not an * or @ > > Will create a popup list that will default to the empty option. > > > But, you tell me, Kurt (and list, if you're reading), does the documentation > explain these points well enough already? Or do I need to make some changes? I just did another read-through (still fairly quick due to lack of time right now) and correct me if I'm wrong but I didn't see that the current documentation addresses these points explicitly, except for item (3) and then it is not quite explicit - I think the * or @ in the 3rd field has to be taken from context. To me, redundancy in documentation is good as long as it doesn't get too long as result. I like to hear things from several points of view when I am learning - you never know which one will make something click. The point of view I am suggesting here is to focus the "no default" situation, or whatever you want to call it, and point out the various ways that can come about (and whether their are any differences between them - see below). It gives another overview of the whole picture, but with a particular focus. > If so... where? And to what effect? I'll refer to what I previously sent you (apparently off-list?) in a message called "doc comments". These comments are referring to your original "logindomainlist.txt" documentation. ***** > However, right at that point when you said "This is useful because" I was > wanting to see an explanation for what non-default really means. Maybe... > > The non-default condition is needed to leave the domain unspecified. > When the domain is unspecified the user may type a domain after their > user name. > In addition an unspecified domain is likely to be used for local > "system account" users. > > Note that when a popup list is used, if the empty item is selected, > this creates the same effect - the domain may be typed, or else > the system domain is being accessed. > > > > The wording is not final, but some of it is ok, I think. And I'm not sure if > I'm correct on that last point about the meaninf of the blank popup item. > > After that (or further down?) is where the search order issue could be > addressed. ***** So in reference to that, after the 3rd paragraph in what I wrote (above), you could in that context add something like: ***** Thus the non-default condition can arise for 4 different reasons: (1) no logindomainlist file (2) no match found in the logindomainlist file (3) matching entry has first field empty, and an * or @ is in the thirdfield (4) the user choses (explicitly or not) the blank item from the popup Item (4) can result because the popup defaulted to the empty item, and the user did not alter it. The popup will default to the empty item when the matching entry has first field empty, and third field is not an * or @. ***** The last bit is a little too techie, but you get the idea. I suggest listing the 4 situations. Leaving out the 4th and exlaining as you suggested omitted the possibility that the user could also CHOOSE the blank item (when it is not the default). The blank item is always present, right? It always has been for me. People might wonder what the blank item even means, and administrators may want to explain this if it is possibly needed. It is good to let them know whether this allows them to enter their domain explicitly - this is the reasons for the next point... > > >> >> >> >> and... >> >> >> >> on 3/3/03 10:36 PM, Kurt Bigler <[EMAIL PROTECTED]> wrote: >> >>> on 3/3/03 6:42 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: >>> >>>>> Is the term "default domain" really correct, or is it confusing? >>>>> Clearly with the popup it is correct. >>>>> But without the popup is it a default or is it just the login domain? >>>> >>>> It's a HARD default. You can't choose anything else. It's a default from >>>> the >>>> perspective of the logindomainlist file, but not necessarily the user. I >>>> may note this distinction in my docs. >>> >>> Good to know. I think that's fine. A short note in the doc will do it. > > Do you really think it's unclear what the different modifiers do? (with regard > to > the generation of a hidden field or a drop down menu) If it is, then I'd be > happy > to revise if you could point out the fuzzy parts. My point here is that you explained to me what "HARD default" means. The doc doesn't currently cover this. I'm not 100% sure when the hard default kicks in, but here is what I think... Some context was lost from our original discussion - I actually filled a little more of it in above - stuff that was snipped. I think you were saying the hard default only kicks in when there is no popup. When there is a popup and the user choses the empty item, only then are they free to type in their domain in the userid field. Did I get that right? If so, then item (4) in the list above is different from items (1) through (3). Enough feedback for one round though. Maybe enough for you to throw back another proposal that needs only tiny tweaks, if any? Leaving the doc for one comment on the features/implementation: The above thoughts about the blank item in the popup makes me think that some admins might prefer having a way to OMIT the blank item from the popup, in case it is not useful, or in case the admin does not want to allow access to other domains from that page. Just a thought for the record. Nothing that needs to be acted on, until/unless it turns out to actually matter to someone. -Kurt > > Thanks, > > Jesse > >> >> >> >> >> Thats all! >> >> -Kurt >> >> >> > >
