[ mailman-Patches-1193846 ] pass emailhost to mlist.Create

[SourceForge.net]

Patches item #1193846, was opened at 2005-05-02 10:57
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1193846&group_id=103

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: command line scripts
Group: Mailman 2.1
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Jorge Jimenez (tribus)
Assigned to: Nobody/Anonymous (nobody)
Summary: pass emailhost to mlist.Create

Initial Comment:
As bin/newlist has emailhost option, then make
mlist.Create call with lang and host_name parameters to
take care of it.

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2008-06-09 14:10

Message:
Logged In: YES 
user_id=12800
Originator: NO

I don't think this should be done in newlist.  I've always regretted
putting too much logic into the bin scripts because very often the code
wants to be used elsewhere too.  But anything in a script is basically
unavailable to other parts of Mailman.  +1 for working up a new bug/patch
for validating urlhost and emailhost.

----------------------------------------------------------------------

Comment By: Mark Sapiro (msapiro)
Date: 2008-06-09 13:59

Message:
Logged In: YES 
user_id=1123998
Originator: NO

I see what you're saying, but if this is to be addressed, I think it
should be done in newlist itself, possibly as you suggest via a modified
MailList.CheckValues().

I don't think it should be done by passing host_name to MailList.Create()
because if that is done, the exception thrown by Create() is
Errors.BadListNameError and it is reported by newlist as 'Illegal list
name'.  The problem here is if I specify say a listname of 'list' and an
unqualified email host name of 'host' to newlist, newlist reports 'Illegal
list name: list at host' which is confusing to the user who doesn't realize
that the problem is 'host' needs to be qualified.

In summary, I think this patch should remain closed and perhaps a new bug
should be opened for 'newlist doesn't validate urlhost and emailhost
arguments'.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2008-06-09 13:16

Message:
Logged In: YES 
user_id=11375
Originator: NO

Here's why I think the emailhost portion is still relevant, though not
very important. MailList.Create does:

        postingaddr = '%s@%s' % (name, emailhost)
        try:
            Utils.ValidateEmail(postingaddr)
        except Errors.MMBadEmailError:
            raise Errors.BadListNameError, postingaddr

Setting the emailhost after calling .Create() side-steps this check,
and it doesn't look like bin/newlist does anything like this check, nor
does it call MailList.CheckValues().  Perhaps the above check should be put
into .CheckValues(), and newlist changed to do mlist.CheckValues().

----------------------------------------------------------------------

Comment By: Mark Sapiro (msapiro)
Date: 2008-06-09 11:52

Message:
Logged In: YES 
user_id=1123998
Originator: NO

Nothing in this patch is currently relevant. The 'lang' part of it was
fixed in Mailman 2.1.10, and host_name and web_page_url have been set
appropriately by newlist since 2.1.6 although they are not passed to
mlist.Create but set after.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2008-06-09 09:26

Message:
Logged In: YES 
user_id=11375
Originator: NO

This patch is slightly out-of-date -- mlist.Create now takes a langs
parameter instead of 
just 'lang' -- but adding the host_name is still relevant.  mlist.Create
checks the validity of postingaddr based upon the emailhost, so setting it
after-the-fact is sidestepping that check.

I'll try to apply and test this patch, but won't do it not in time for
2.1.11.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1193846&group_id=103