Re: [Mailman-Developers] [Bug 1020683] Feature Request: Make regular_*_lists and *_these_nonmembers recursive (and aware of each other).
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@python.org http://mail.python.org/mailman/listinfo/mailman-coders
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
participants (2)
-
Barry Warsaw -
Richard Wackerbarth