Mailman 3 July 2012 - Mailman-Developers

Re: [Mailman-Developers] [Bug 1020683] Feature Request: Make regular_*_lists and *_these_nonmembers recursive (and aware of each other).
by Richard Wackerbarth 06 Jul '12

06 Jul '12

On Jul 5, 2012, at 2:48 PM, Robert Arlt Jr. wrote: > I can as well. In my view of the issue I believe that allowing everyone > on listB to submit is the better option as I can easily make a list > composed of those allowed to send unmoderated to listB, call it listB2 > and add listB2 to listB then use listB2 as the list allowed to send to > listA (all of this assuming recursion is implemented). But that would be confusing to the members of listB. They would have to realize that they are not really a member of listB, but that they are actually a member of listB2. So, if you are going to do that, and perhaps for any inclusion that is transparent on message delivery, an attempt to change delivery preferences on listA should take the user to the listB2 preferences. However, if the delivery of listA is done by publishing a copy of the message on listB, then, for the purpose of preferences, the listB user should not be considered a member of listA.

1 0

Re: [Mailman-Developers] [Bug 1020683] Feature Request: Make regular_*_lists and *_these_nonmembers recursive (and aware of each other).
by Richard Wackerbarth 06 Jul '12

06 Jul '12

Robert, Although I recognize your goal, it isn't as easy as simply providing transitive membership. First, I presume that you are willing to restrict yourself to the case where lists listA, listB, and listC are served by the same instance of MM. On the distribution side, that restriction certainly is not necessary for list inclusion, but, in general, there is no mechanism for listA to learn the members of listC unless they are served by a common server instance. Even so, the issue is whether, or not, everyone who receives listB should be allowed to submit to listA (without moderation). Or perhaps you would only want those who can make unmoderated submissions to listB to have that transitive permission. I can visualize both use cases. Richard On Jul 5, 2012, at 12:53 PM, Robert Arlt Jr. wrote: > I think making it recursive would be sufficient. > > However, it isn't really that I want *_these_nonmembers to be recursive > to *_these_nonmembers as I may want different sets of lists to be able > to send to a particular list. I guess it might be better if I just > explained what I really want, which is the ability to add @listC to the > members of listB such that listA, which has accept_these_nonmembers set > to @listB, can be sent to unmoderated by members of listC. In > otherwords making the @listname format usable as a list member such that > *_these_nonmembers and sibling lists can transverse them. > > Neither of the solutions you have talked about are exactly that, but > could be used instead to obtain the same goal. Basically what I am > trying to do is minimize the number of lists that would have to be > changed if a new lists is created that should have rights to send to a > number of lists. > > Perhaps I should have split this into two feature requests, the > recursion request is by far more of a useful feature. The other feature > would add on only a minimal amount of capability. > > -- > You received this bug notification because you are a member of Mailman > Coders, which is subscribed to GNU Mailman. > https://bugs.launchpad.net/bugs/1020683 > > Title: > Feature Request: Make regular_*_lists and *_these_nonmembers recursive > (and aware of each other). > > To manage notifications about this bug go to: > https://bugs.launchpad.net/mailman/+bug/1020683/+subscriptions > _______________________________________________ > Mailman-coders mailing list > Mailman-coders(a)python.org > http://mail.python.org/mailman/listinfo/mailman-coders

2 1

Re: [Mailman-Developers] mailman3 instance for preview + exploration
by Florian Fuchs 05 Jul '12

05 Jul '12

Hi Jeff, thank you, that's great! The "Connection refused" error is caused by Postorius failing to connect to Mailman's rest api. Can you check if Mailman is currently running? Cheers, Florian Am 04.07.12 01:32, schrieb Jeff Breidenbach: > Hello mailman-developers, > > I suspect that there are folks who would like to see what Mailman 3 > and particularly Postorius without going through the effort of > software installation. Jeff Marshall was kind enough to set up a test > instance that people can look at and play with. This is a temporary > setup so don't use for anything real. Also try not to spam anyone as > we'll take it down at the first sign of trouble. I hope this helps > with the development process. > > Cheers, > Jeff > > === > > http://mailman3.jab.org:8000/ > > username: public-admin > pw: tryitout > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers(a)python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/f%40state-of-mind… > > Security Policy: http://wiki.list.org/x/QIA9 >

2 2

Re: [Mailman-Developers] mailman3 instance for preview + exploration
by Barry Warsaw 04 Jul '12

04 Jul '12

On Jul 03, 2012, at 10:15 PM, Jeff Breidenbach wrote: >That sure didn't take very long... If the core crashed, please take a look at the error log and file bugs! Thanks, -Barry

1 0

Twisted NNTP
by Alexander Sulfrian 04 Jul '12

04 Jul '12

Hi, I working for gsoc creating NNTP access to the mailing list archives for Mailman 3. Therefor I tried Twisted NNTP, during the last days. I noticed, that it is not standard conform in any way. For example: it missing required commands and returns wrong error codes on unknown sub commands. I will try to fix it. But while I modify it, I could port it to asyncore/async_chat. Would it be preferred? anyncore is bundled with core python and so the new implementation would be runnable without depending on Twisted. But if patching the Twisted implementation, other projects using it could gain profit, too. So what is your position? Thanks, Alex

4 4

Re: [Mailman-Developers] mailman3 instance for preview + exploration
by Patrick Ben Koetter 04 Jul '12

04 Jul '12

* Jeff Breidenbach <jeff(a)jab.org>: > Hello mailman-developers, > > I suspect that there are folks who would like to see what Mailman 3 > and particularly Postorius without going through the effort of > software installation. Jeff Marshall was kind enough to set up a test > instance that people can look at and play with. This is a temporary > setup so don't use for anything real. Also try not to spam anyone as > we'll take it down at the first sign of trouble. I hope this helps > with the development process. > > Cheers, > Jeff > > === > > http://mailman3.jab.org:8000/ [Errno 111] Connection refused -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht München Partnerschaftsregister PR 563

2 1

Re: [Mailman-Developers] mailman3 instance for preview + exploration
by Barry Warsaw 04 Jul '12

04 Jul '12

On Jul 03, 2012, at 04:32 PM, Jeff Breidenbach wrote: >I suspect that there are folks who would like to see what Mailman 3 >and particularly Postorius without going through the effort of >software installation. Jeff Marshall was kind enough to set up a test >instance that people can look at and play with. This is a temporary >setup so don't use for anything real. Also try not to spam anyone as >we'll take it down at the first sign of trouble. I hope this helps >with the development process. Fantastic, thanks Jeffs! BTW, you can prevent spam by enabling devmode. In the core's mailman.cfg file, add this: [devmode] enabled: yes # Season to taste. All mail gets sent here. recipient: devnull(a)example.com And of course, restart. Cheers, -Barry

1 0

mailman3 instance for preview + exploration
by Jeff Breidenbach 04 Jul '12

04 Jul '12

Hello mailman-developers, I suspect that there are folks who would like to see what Mailman 3 and particularly Postorius without going through the effort of software installation. Jeff Marshall was kind enough to set up a test instance that people can look at and play with. This is a temporary setup so don't use for anything real. Also try not to spam anyone as we'll take it down at the first sign of trouble. I hope this helps with the development process. Cheers, Jeff === http://mailman3.jab.org:8000/ username: public-admin pw: tryitout

1 0

Re: [Mailman-Developers] Questions in regard to the database operations
by Danci Emanuel 04 Jul '12

04 Jul '12

Hi Barry! I was thinking about these two ways too, but I did not know how much of these options has been implemented so far. In regard to the Postorius option, has this already been implemented (is there a box where the user can insert additional email addresses)? I am asking this because so far I have worked with the rudimentary version (the test server set up using the 5-minute guide) and I did not get the chance yet to check that too. Thanks, Emanuel

2 1

Adding a new list attribute
by Danci Emanuel 02 Jul '12

02 Jul '12

Hi again! As I said in an earlier post, I am a GSoC student, working for the Systers organization, on integrating the dynamic sublists feature ( http://systers.org/systers-dev/doku.php/good_to_know?s%5B%5D=postgresql ) with Mailman 3.0, and I am facing a small problem. What I wanna do is to adapt the UI and the back-end so they contain the options needed in order to enable/disable this feature for a list (at creation or after it has already been created). I want to get this right, so it would work as good as possible, so this is what I have done and the error I get: Firstly, in the class "ListNew" from "forms.py" I added a new ChoiceField, named "dlists_enabled" (the naming and the text from the labels are temporary until I get the feature to completely work) dlists_enabled = forms.ChoiceField( widget = forms.RadioSelect(), label = _("Enable dlists for this list?"), error_messages = { 'required': _("Please choose an option."), }, required = True, choices = ( (True, _("Enable dlists for this list")), (False, _("Do not enable dlists for this list")) )) This is working properly because if I print the result of "form.cleaned_data['dlists_enabled']" from "views.py", in a file, it correctly prints the option chosen by the list owner (True or False). I also added to "views.py" in the "list_new" function the following line (In the try block where list_setting are saved): list_settings["dlists_enabled"] = form.cleaned_data['dlists_enabled'] Secondly, I tried to modify the list attributes by adding the following: dlists_enabled = Attribute("""Is the Dynamic sublist feature enabled?""") - "IMailingList" interface (/interfaces/mailinglist.py) dlists_enabled = Bool() - "MailingList" class (/model/mailinglist.py) dlists_enabled = GetterSetter(as_boolean) - to the ATTRIBUTES dict from /rest/configuration.py mlist.dlists_enabled = True - in the "apply" method from "DefaultStyle" class (/styles/default.py) Obviously I did something wrong, or I did not add all the necessary changes because when I try to create a new lists that has the dlists feature enabled, I get the HTTP Error 400: HTTP Error 400: Unknown attribute: dlists_enabled Thanks in advance for your feedback! Emanuel

2 1