| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
was in (which was largely my fault from before).
Before:
1) web_subscribe_requires_confirmation was showing in the
admin cgi, but not working.
2) all subscribes that required admin approval were going
through the confirmation process.
3) the code implementing the confirmation process was
distributed between the subscribe cgi and
MailCommandHandler, duplicated in places and disrupting
the previous interface to list.AddMember.
4) the open_subscribe variable was confusing because
it didn't pay any attention to confirmations.
Now, things are organized a little differently, but in a much cleaner
way. there is one variable that deals with subscription policy, called
"subscribe_policy". It's setting determines what happens with both
the web based and the mail based subscriptions. there are 4 options:
0 - open subscribe policy
1 - confirmation required
2 - admin approval required
3 - confirmation and then admin approval required
there is a site configuration variable in Defaults.py called
ALLOW_OPEN_SUBSCRIBE, which determines whether or not an open
subscribe policy is an option. If it's not, the admin cgi interface
does not present it as an option.
I have restored a slightly modified version of the
prior-to-confirmations interface for list.AddMember, where all you
have to code is:
try:
list.AddMember(email, digest, password)
except Errors.MMBadEmail:
except Errors.MMAlreadySubscribed:
[ ... all those other good things it used to check ...]
except Errors.MMSubscribeNeedsConfirmation:
# the confirmation has already been sent.
# so just report accordingly to whatever the ap is.
In addition, I have moved the code for processing a confirmation
request to MailList.py so that it can be used in both a confirmation
cgi (which does not yet exist, but will) and the mailcmd script.
it's interface is:
try:
list.ProcessConfirmation(cookie)
except Errors.MMBadConfirmation:
# the cookie doesn't correspond to anything
except Errors.MMNeedApproval:
# the list is set to approve+confirm subscribe_policy.
A listing of the changes to the files follows:
Mailman/Defaults.in: added ALLOW_OPEN_SUBSCRIBE,DEFAULT_SUBSCRIBE_POLICY
deleted DEFAULT_OPEN_SUBSCRIBE, changed
DATA_FILE_VERSION to 5
Mailman/Errors.py: added MMBadConfirmation and
MMSubscribeNeedsConfirmation
Mailman/MailCommandHandler.py: moved the confirmation code to
MailList.py and use the new (old)
list.AddMember interface
MailMan/MailList.py: added .ProcessConfirmation(cookie), changed
AddMember to fit new (old) interface.
deleted config info for open_subscribe
and replaced with config info for
subscribe_policy that acts according to
mm_cfg.ALLOW_OPEN_SUBSCRIBE. Also made
list.ApprovedAddMember's "noack"
argument just "ack" for simplicities
sake and made it default to None
instead of 0 so that if the ack
variable isn't passed, it sets it to
the value of the lists
.send_welcome_msg setting.
Mailman/versions.py: added handling for new data file format,
replacing open_subscribe with a reasonable value
for subscribe_policy based on a combination of
what open_subscribe is and what
mm_cfg.ALLOW_OPEN_SUBSCRIBE is set to.
Mailman/Cgi/admin.py: made the cgi handle the output and processing of
subscribe_policy based on the setting of
mm_cfg.ALLOW_OPEN_SUBSCRIBE.
removed erroneous processing of whether or not
to send an ack with mass subscription based on
new interface to list.ApprovedAddMember (this
processing is to be replaced with a good idea
from john -- making mass subscribe have it's own
option of whether or not to send welcome
messages).
Mailman/Cgi/subscribe.py: made backgrounds white, and made it use the
MailList.AddMember interface described
above.
Mailman/Makefile.in: looks like this part of that distclean patch from
NAGY didn't make it in yet (rm'ing mm_cfg.py as well
as Defaults.py)
scott
|
| |
|
|
|
| |
address, the script would throw a NameError
scott
|
| |
|
|
|
|
|
|
|
| |
main() - reorganized the order of activities around the confirmation
request notice, so that validation of the addr and posting on the
confirmation queue, etc, are successfully done before sending the
notice. Otherwise, we were getting confirmation requests sent when,
eg, the person was already a member of the list - but the subscription
wasn't in the confirmation queue, 'cause it was invalid...
|
| |
|
|
|
| |
log file, in addition to the already logged subscription finalizations
and deletions.
|
| |
|
|
|
| |
message in the new log file, "mischief" indicating the error and, if
available, the identity of the host where it originated.
|
| |
|
|
|
|
|
|
| |
don't accidently get the built-in list function. Second, import and
run main() of the passed in `which' script, which seems currently to
be only options.py.
Q: How did this ever work???
|
| |
|
|
| |
verify.txt.
|
| |
|
|
|
|
| |
already-subscribed members.
(Wrapped a couple of long lines.)
|
| |
|
|
|
|
| |
the verify.txt message, causing the subscribe script to bomb. I've
corrected the field and refined the message a bit, to put in the
origin phrase only if it's been discerned.
|
| |
|
|
|
|
|
| |
the Mailman package (using the semi-bogus, but quickly implemented
from ... import style).
main()-ify, but needed a few bogus global decls
|
|
|
handle logging to an error file, and no longer import paths. Also,
any checks for __main__ have been removed.
|
