summaryrefslogtreecommitdiff
path: root/Mailman/Commands/cmd_confirm.py
Commit message (Collapse)AuthorAgeFilesLines
* Update copyright years.bwarsaw2007-01-191-1/+1
|
* Port cleaning changes forward from 2.1-maint branch.bwarsaw2005-12-301-1/+2
|
* Improving banned subscription logic to cover all invites, subscribes, ↵msapiro2005-12-031-1/+7
| | | | address changes and confirmations of same.
* back porting from 2.1.6tkikuchi2005-08-281-0/+3
|
* FSF office has moved. chdcking in for MAIN branch.tkikuchi2005-08-271-1/+1
|
* Typo. Requires new i18n translations.bwarsaw2003-04-061-1/+1
|
* process(): Catch HostileSubscriptionError and return an error message.bwarsaw2003-03-161-0/+4
| | | | Closes SF bug # 703941 by Stuart Bishop, who also suggested the basic fix.
* copyright yearsbwarsaw2003-03-101-1/+1
|
* Typo fix in documentation. Closes SF patch #700538, Small typo intwouters2003-03-101-1/+1
| | | | | | Mailman/cmd_confirm.py (but doesn't really use it :) 2.1 backport candidate.
* process(): Set the `respond' flag to false ifbwarsaw2002-11-211-10/+17
| | | | | | | - this is a subscription being confirmed and send_welcome_msg is true - this is an unsub being confirmed and send_goodbye_msg is true We don't need redundant responses.
* process(): Fix for confusing "you were subscribed and yourbwarsaw2002-07-091-3/+11
| | | | | | | | | | | | | confirmation string was invalid" messages. The problem was if the responder left the confirmation string in the Subject: and also copied it to the body, the second processing of the confirmation would find no cookie. So now we always stop after processing the first confirmation command (yes, that means no other commands in the message will be processed, which is fine). We also trim the unprocessed commands in the results to not include identical confirmation strings -- otherwise they'll see their confirmation as unprocessed.
* Oops, I guess I forgot to commit this change.bwarsaw2002-05-041-2/+3
| | | | | process(): Catch NotAMemberError instead of MMNoSuchUserError. Also, slight rewrite of the result message.
* New architecture for email commands. Instead of the monolithic (andbwarsaw2002-05-021-0/+68
unmaintainable) MailCommandHandler.py file, we've now got a framework where each command is implemented in a separate file. This means it's both more extensible and more flexible: - you can easily add new commands for things I haven't thought of <wink>, and the `help' command will automatically adjust - you can disable commands entirely by removing the appropriate file - you can disable, change, or add commands on a per-list (or even per-message or per-sender) basis CommandRunner.py is the module that calls into this framework. Each command is implemented as a cmd_<command>.py file. The `set' command is the most complicated. The help text is currently implemented as module docstrings (for most commands), so the i18n catalogs must be updated. Also the help.txt files will be updated.