On Tuesday 11 March 2003 01:15, Kurt Bigler wrote: > 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 agree. Most of the time. But sometimes you run across redundant documentation like that of the vpopmail project. Some parts of the documentation have changed along with the program, and some are now defunct, but the user has no idea which to believe. :) I doubt this will happen to my little logindomainlist patch though, so I'll try to give a few different "focus" headings. Each focusing on a particular aspect of the functionality. > 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... Ok. I hear ya. > > >> 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... Yeah. I should have mentioned this before, but I genuinely think that your question was more accurate than my answer. Explaining things in terms of "the login domain" seems to make more sense to me now. Perhaps I should simply emphasize WHEN the "user" can change "the login domain" by moving the drop down, and when they can't (when the * and @ symbols are used). > > 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? Hmmm... yes. It appears to be that you can type in a full email address when the drop down is empty. I actually had to test this manually since my patch doesn't actually modify the code that actually processes the 'logindomain' form variable, and I wasn't sure if you could do this before I modified the logindomainlist functionality or not. > > 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. I don't really see this tripping anyone up. Actually, something I'm thinking about implementing in the next patch is a way to generate a textfield, and a defaulted textfield (with the login domain already filled in). And maybe even a disabled, defaulted textfield (with the login domain already filled in). I wouldn't use the functionality myself, but I plan to submit this same patch to the qmailadmin folks in the near future, and qmailadmin currently uses an empty text field for the login domain. Some of those folks might want to see a text field included in this kind of functionality. Perhaps the '-' modifier could specify a text field? The text field should accept wild cards too, I should think. How does that sound? > > -Kurt > > > Thanks, > > > > Jesse > > > >> Thats all! > >> > >> -Kurt -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net We are actively looking for companies that do a lot of long distance faxing and want to cut their long distance bill by up to 50%. Contact [EMAIL PROTECTED] for more info.
