Mark Sapiro wrote:
Consider the following instead.
Create a list named say posters with it's own extend.py with settings like ldap = LDAPMemberships(list) ldap.ldapsearch = "(role=list-poster)" # as an example ldap.ldapserver = ldap3.example.net list._memberadaptor = ldap etc.
Then all you need do is install the patch and put @posters in the original list's accept_these_nonmembers. You would also want to set the 'posters' list with attributes like
archive = No advertised = No default_member_moderation = Yes member_moderation_action = Discard generic_nonmember_action = Discard
so people wouldn't be aware of it and posts would not be accepted.
That way, the different LDAP functions would be defined for different "pseudo lists" and you wouldn't need any Mailman modifications other than installing a feature that's already implemented in current versions.
Okay, okay, you've beaten me down. :):):) I do see your point. It is an additional management issue I wanted to avoid with the unadvertised lists.
Will this @list method also work for the other parameters/options that have a list of email addresses (like owner, moderator, ban_list, ...) or just the *_these_nonmembers options?
It probably sounds silly to do but if those options also take the @list method, I can set up several of my lists so all the options (with email address lists) are based out of ldap and have our system for creating accounts out of our HR system build the ldap entries, resulting minimal list management (for me at least :):)) The ban_list would not be an ldap list but in theory it could.
If not, I guess I will have to live with it. :)
Thanks, Chris