Feature Request: Make regular_*_lists and *_these_nonmembers recursive (and aware of each other).

[Robert Arlt Jr.]

It would be very useful if sibling lists could be nested. The same goes for non-member lists. It would also be nice if non-member lists could also include the members of sibling lists.

[Mark Sapiro (msapiro)]

I don't understand what you mean by "It would also be nice if non-member lists could also include the members of sibling lists". You can already put any @listname in *_these_nonmembers to include the members of listname. Is that what you mean? Or do you mean something else such as accept_these_nonmembers should automatically and implicitly include the members of any regular_include_lists?

[Robert Arlt Jr. (dukrat)]

Automatically and implicitly would seem to be a little strong. What I'm asking for is an option that allows regular_include_lists and/or lists that are members of lists to have their members count for *_these_nonmembers and in a recursive manner. For example:
listA:
     members: jack@...
     accept_these_nonmembers: @listB

listB:
     members: jill@...
     regular_include_lists or accept_these_nonmembers or members: @listC

with the result that listC can send to listA unmoderated.

[Mark Sapiro (msapiro)]

I understand the recursive request. Leaving that aside for a moment, it seems you already have the rest of your request. Your option is to just put @listname in accept_these_nonmembers for every list in regular_include_lists. So it seems that all you are really requesting is that @listname lists in *_these_nonmembers be processed recursively. Is that correct or am I missing something?

[Robert Arlt Jr. (dukrat)]

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.

[Mark Sapiro (msapiro)]

"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."

And wouldn't this be the case if @listC was in listB's accept_these_nonmembers and @listB was in listA's accept_these_nonmembers and accept_these_nonmembers were processed recursively?

As far as allowing members of a regular_include_lists list to post is concerned, this is already easily accomplished by simply adding the @LISTNAME to accept_these_nonmembers at the same time as you add the list posting address to regular_include_lists.

So it still seems to me that you can easily accomplish everything you ask if *these_nonmembers were processed recursively.

If this is not the case, please give an example of what would not be configurable in this way.

[Richard Wackerbarth (wacky)]

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
> <email address hidden>
> http://mail.python.org/mailman/listinfo/mailman-coders

[Barry Warsaw (barry)]

On Jul 05, 2012, at 01:58 PM, Richard Wackerbarth wrote:

>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'll note that with Mailman 3 and clever implementation of the IRoster
interface, various riffs on this should be doable. Most implementations of
IRoster are not physical objects persisted in the database, but instead
"virtual" objects such as queries. There's no reason I can think of that an
IRoster implementation couldn't perform cross-list queries, or even for that
matter cross-server queries, assuming the necessary communication channels
were available.

I've not actually tried to implement anything like this, but I can somewhat
visualize how this would work. I invite you to experiment with this.

Cheers,
-Barry

[Robert Arlt Jr. (dukrat)]

"And wouldn't this be the case if @listC was in listB's accept_these_nonmembers and @listB was in listA's accept_these_nonmembers and accept_these_nonmembers were processed recursively?"

Yes, but what if I only wanted listC to be able to send to listA and not listB (I personally don't want to do this, but I could see someone else wanting to).

"served by a common server instance"

Yes, that would be an expected requirement for this feature to work.

"I can visualize both use cases."

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).

"with Mailman 3... various riffs on this should be doable"

Thanks for letting me know, I will look into that.

[Mark Sapiro (msapiro)]

I wrote:
"And wouldn't this be the case if @listC was in listB's accept_these_nonmembers and @listB was in listA's accept_these_nonmembers and accept_these_nonmembers were processed recursively?"

Robert replied:
"Yes, but what if I only wanted listC to be able to send to listA and not listB (I personally don't want to do this, but I could see someone else wanting to)."

Well, if I wanted to do that, I would just put @listC in listA's accept_these_nonmembers, but I suppose you envision a case where listB and ListC are siblings and listB is in listA's accept_these_nonmembers and then listC members can post to listA because some "include siblings members as posters (recursively)" option is selected for listA, but they can't post to listB because that "include siblings" option is not selected for listB.

This seems so complicated and error prone that I don't think it could even be explained in a way that people could use it, but perhaps you can see some more straightforward way of setting this up. I also wonder if listC members can't post to listB, how does referencing listB (recursively) from listA give listC's members any posting rights on listA.

In any case, I don't see it ever being implemented in Mailman 2.1 which is virtually at the end of it's development life anyway. Perhaps something will be done for Mailman 3.

[Richard Wackerbarth (wacky)]

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.