Search results for "Postorius" - Mailman-users

Re: Mailman 3 install questions: HAYSTACK_CONNECTIONS

by Odhiambo Washington

On Sun, Jul 7, 2024 at 6:24 AM <heller(a)deepsoft.com> wrote: > I am using the debian 12 repo versions of mailman3, django, posterious, > hyperkitty, and xapian: > > sharky5% dpkg-query -l > python3-{django,django-mailman3,django-hyperkitty,django-postorius,xapian} > mailman3\* | grep '^ii' > ii mailman3 3.3.8-2~deb12u2 all Mailing list > management system > ii mailman3-doc 3.3.8-2~deb12u2 all Mailing list > management system documentation > ii mailman3-web 0+20200530-2.1 all Django > project integrating Mailman3 Postorius and HyperKitty > ii python3-django 3:3.2.19-1+deb12u1 all High-level > Python web development framework > ii python3-django-hyperkitty 1.3.7-1 all Web user > interface to access GNU Mailman3 archives > ii python3-django-mailman3 1.3.9-1 all Django > library to help interaction with Mailman3 (Python 3 version) > ii python3-django-postorius 1.3.8-3 all Web user > interface to access GNU Mailman3 > ii python3-xapian 1.4.22-1 amd64 Xapian > search engine interface for Python3 > > Before adding the HAYSTACK_CONNECTIONS options, I have this: > > sharky5% sudo mailman-web haystack_info --no-color --skip-checks > Number of handled 1 index(es). > - Model: Email by Index: <hyperkitty.search_indexes.EmailIndex object at > 0x7fd0de1b0470> > > When I add this to /etc/mailman3/maymail_web.py (adapted from the section > titled: > "Setting up Fulltext search (xapian)" on > https://docs.mailman3.org/en/latest/install/virtualenv.html#set-up-xapian > > HAYSTACK_CONNECTIONS = { > > 'default': { > > 'PATH': "/var/lib/mailman3/web/fulltext_index", > > 'ENGINE': 'xapian_backend.XapianEngine' > > }, > > } > > I get: > > File "/usr/lib/python3.11/importlib/__init__.py", line 126, in > import_module > return _bootstrap._gcd_import(name[level:], package, level) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > File "<frozen importlib._bootstrap>", line 1206, in _gcd_import > File "<frozen importlib._bootstrap>", line 1178, in _find_and_load > File "<frozen importlib._bootstrap>", line 1142, in > _find_and_load_unlocked > ModuleNotFoundError: No module named 'xapian_backend' > > So, do I use Xapian or not? Is something missing somewhere? Is this a > documentation bug or something else? > It cannot be a documentation bug since you are NOT using/following the documentation! The message is good enough. Where is your xapian_backend,py?? ``` wash@gw:~$ locate xapian_backend.py /opt/mailman/mm/venv/lib/python3.11/site-packages/xapian_backend.py wash@gw:~$ ``` I hope the above gives you a clue as to where it should be found. However, since you aren't following the documentation I am familiar with, and I am not a Python expert, my end-of-thinking capacity (/etc) is here :-) -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

2 years, 2 months

Re: Customizing Postorios web templates

by Stephen J. Turnbull

Stefan Bethke writes: > I understand. Would you be open to some documentation about the > general approach and a few pointers in the right direction? For > people who are not familiar with Django this is not very obvious. Yes, Without seeing your contribution, I think something like what I wrote with a more precise pointer to Django documentation on overriding templates would be optimal. But I would be open to suggestions. > And also, would you accept a change that enables replacing the icon > in the nav bar and (extending/replacing) the footer, by defining a > block each for these places with the current content as the > default? I would have to see the proposed change. As I said before, I am generally opposed to making it easier to replace our branding. Making the footer extensible while preserving our branding would be fine with me, but it seems to me that it would be hard to do that in a way that would satisfy most use cases and be reliably attractive. > My rationale is that I do not want to track changes to > postorius/base.html manually, Yeah, I understand that. Still I'm reluctant to approve it (espcially sight unseen), but I won't veto it, or any of the parts you've mentioned. So I recommend you consult Abhilash Raj <maxking(a)asynchronous.in>, who is the committer most recently active on Postorius as far as I know, specifically base.html. -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

7 months

mailman changeaddress -h weirdness

by Washington Odhiambo

ENV: Mailman Core Version = GNU Mailman 3.3.11b1 (Tom Sawyer) Mailman Core API Version = 3.1 Mailman Core Python Version = 3.11.2 (main, May 12 2026, 05:17:27) [GCC 12.2.0] A member requested to be subscribed to a list through the normal process (confirm and approve). I approved. Shortly after, I received an email they sent to one of the moderators requesting that their subscribed address be changed from the OLD to the NEW(ly subscribed) one. So I deleted the new address via Postorius. I went to the CLI and dis: ``` (venv) mailman@eu:~$ mailman changeaddress REDACTED(a)gmail.com kevin@ [REDACTED] Usage: mailman changeaddress [OPTIONS] OLD_ADDRESS NEW_ADDRESS Try 'mailman changeaddress -h' for help. Error: Address kevin@[REDACTED already exists; can't change. (venv) mailman@eu:~$ ``` Since I had deleted the newly subscribed member, this surprised me. I checked again and they were not found among members. Then I checked under non-members and found the new address there. I then deleted it again. Back to the CLI, Same error. Then I did: (venv) mailman@eu:~$ mailman findmember kevin@[REDACTED] (venv) mailman@eu:~$ That returned empty. I went into Django Admin US and searched for - and found the address still in there. I deleted it again. Back to the CLI to change the address, same error - the address still exists. I am stumped. Oh, and maybe we should have that changeaddress option in Postorius as well? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

2 weeks

Re: users, users and users (was Re: Re: Cannot request password reset: "The e-mail address is not assigned to any user account")

by Mark Sapiro

On 1/28/22 00:41, IOhannes m zmölnig wrote: > > i'm afraid i still do not fully understand which types of "users" there > are. > > > afaics, there are three different types: > - django users > this is what get's listed under > <https://lists.mailman3.org/admin/auth/user/> Correct. > - mailman accounts > this is what is created when you visit > <https://lists.mailman3.org/accounts/signup/> No. That creates a Django user, not a Mailman user. What you think of as a Mailman account is actually a Django account. > - email addresses > this is what is created when i subscribe to a list *without* having > an account. > e.g. via the "Subscribe" button on > <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/> Mailman core has users and addresses. A user has one or more associated addresses. When you subscribe to a list without having an account in that way, or via email to list-join or list-subscribe or by being mass subscribed by the list admin or by being imported by `mailman import21`, assuming you are previously unknown, this creates a Mailman user with an associated address and subscribes the user or address. Each user has a primary address and zero or more additional linked addresses. The user can be subscribed to a list as a user in which case, delivery if any is to the user's primary address, or can be subscribed as an address. > afaiu, (multiple) "email addresses" can be associated with a single > "mailman account" (but this is strictly optional). Yes, see above. > if an "email address" is first used to subscribe to a list without a > mailman account, and later a mailman account is created with that very > email address, they get automatically associated. > a single "email address" cannot be associated with more than one > "mailman accounts". Based on the above, your "mailman accounts" are actually Django accounts. With that in mind, the above is correct, but there is no real link between Mailman users and Django users. When you are logged in to the web UI you are logged in as a Django user, and Postorius and HyperKitty know that user's email address and can therefore know if it is a list member and know what address to subscribe or unsubscribe as requested. > i think i got this one right (as it seems pretty straightforward). > > what i don't fully grasp yet is the relation between "django users" and > "mailman accounts". As I have said, what you are calling a mailman account is a Django user and not a Mailman user. > intuitively, i would have thought that they are identical. They are, but they are not Mailman core users. > now mark wrote: > > a Django user, which is distinct from a Mailman user. The users you > > added via the web API are Mailman users, but in order to access their > > lists via the web UI they have to `sign up` to create a Django > > account. > > that seems to indicate, that a "django user" is a (strict) superset of a > "mailman account". No. A Django user is the same thing as what you call a mailman account. A Mailman core user is a separate thing entirely. > you (as admin) can create "mailman accounts" via the web API¹, but they > are only expanded to "mailman accounts" if you (as user) go through the > "Sign Up" process. No. An admin can create Mailman users via the Postorius UI. A Django superuser can also create Django users through the Django admin UI. > otoh, if you create an initial "django user" by signing up, you > automatically create a "mailman account". Because they are the same thing. When you go to the Sign-up link on a Postorius or Hyperkitty page you go to https://example.com/accounts/signup/, and that's Django, not Mailman. > so are the two distinct concepts that are just associated via some > common property (e.g. the email address), or is there some intrinsic > relationship between the two (e.g. parent-child inheritance relationship)? They are distinct. Django users have email addresses and Mailman users have email addresses and they can be associated in that way. There is no other link. > so my recent experiment (comparing the output of > <https://lists.example.com/admin/auth/user/> with that of `[u for u in > getUtility(IUserManager).users]`) indicates that they are indeed > distinct objects that *can* be associated with each other. > > could you please clarify this? I hope I have. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 7 months

Re: Mailman notify generating emails for request that aren't visible.

by Mark Sapiro

On 10/31/21 6:11 PM, Simon Coggins wrote: > Hi, > > We’re running mailman 3.3.4 (about to upgrade to 3.3.5 this week). I enabled mailman notify cron a few weeks ago to email out any pending requests for admins. I’ve now got multiple lists that keep emailing out the same outstanding holds but they can’t visible in the GUI. The requests are all duplicates as well. This is a redacted example email: > > -----Original Message----- > From: mailman-alerts(a)example.com<mailto:mailman-alerts@example.com> > Sent: Monday, 1 November 2021 8:10 AM > To: somelist-owner(a)lists.example.com<mailto:somelist-owner@lists.example.com> > Subject: The somelist(a)lists.example.com<mailto:somelist@lists.example.com> list has 4 moderation requests waiting. > > The somelist(a)lists.example.com<mailto:somelist@lists.example.com> list has 4 moderation requests waiting. > > Held Unsubscriptions: > User: john.smith(a)maildomain.com<mailto:john.smith@maildomain.com> > User: john.smith(a)maildomain.com<mailto:john.smith@maildomain.com> > User: john.smith(a)maildomain.com<mailto:john.smith@maildomain.com> > User: john.smith(a)maildomain.com<mailto:john.smith@maildomain.com> > > Please attend to this at your earliest convenience. Your lists are configured with Un-Subscription Policy moderate or confirm, then moderate so unsubs require Moderator approval. What Postorius version is this? Prior to 1.3.3, unsubsubscription requests were not visible in Postorius. In 1.3.3_+ they are available in the Subscription requests dropdown at https://example.com/mailman3/lists/listname.example.com/unsubscription_requ… although they may not be counted in the Subscription requests count badge. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 10 months

ModuleNotFoundError: No module named 'settings'

by Michela

Hello! I've just set up Mailman 3 with Hyperkitty and Postorius in venv via pip by using the guide at https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-inst… on Oracle Linux 8.3 with Python 3.6.8. The process seemed to go smoothly and without errors. The log file, /opt/mailman/web/logs/uwsgi-error.log, contains the following stack trace, however. Note the bit toward the bottom: "ModuleNotFoundError: No module named 'settings'" Traceback (most recent call last): File "/opt/mailman/venv/lib64/python3.6/site-packages/django/core/management/__init__.py", line 224, in fetch_command app_name = commands[subcommand] KeyError: 'qcluster' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/opt/mailman/venv/bin/mailman-web", line 8, in <module> sys.exit(main()) File "/opt/mailman/venv/lib64/python3.6/site-packages/mailman_web/manage.py", line 30, in main execute_from_command_line(sys.argv) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/core/management/__init__.py", line 401, in execute_from_command_line utility.execute() File "/opt/mailman/venv/lib64/python3.6/site-packages/django/core/management/__init__.py", line 395, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/core/management/__init__.py", line 231, in fetch_command settings.INSTALLED_APPS File "/opt/mailman/venv/lib64/python3.6/site-packages/django/conf/__init__.py", line 76, in __getattr__ self._setup(name) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/conf/__init__.py", line 63, in _setup self._wrapped = Settings(settings_module) File "/opt/mailman/venv/lib64/python3.6/site-packages/django/conf/__init__.py", line 142, in __init__ mod = importlib.import_module(self.SETTINGS_MODULE) File "/usr/lib64/python3.6/importlib/__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 994, in _gcd_import File "<frozen importlib._bootstrap>", line 971, in _find_and_load File "<frozen importlib._bootstrap>", line 953, in _find_and_load_unlocked ModuleNotFoundError: No module named 'settings' [uwsgi-daemons] throttling "/opt/mailman/venv/bin/mailman-web qcluster" for 245 seconds [uwsgi-daemons] respawning "/opt/mailman/venv/bin/mailman-web qcluster" (uid: 1002 gid: 1002) Mailman and mailman-web do start without errors when I run them via their systemd unit files and Postorius serves up pages (without styles and such, which I'll fix later). SELinux is disabled, at least while I work through this issue. I've gone over the configuration files, and everything appears to be in order as written in the installation instructions, but that's likely not the case. :) My configuration files outside of the Mailman virtual environment are in /etc/mailman/: (venv) [mailman@host ~]$ ls /etc/mailman3/ mailman.cfg __pycache__ settings.py uwsgi.ini When searching the web about this, I only found one result, on this very list, but it didn't have quite enough information for me to solve my issue. It might also not quite be the same problem: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… Might you be able to point me in the right direction on solving this issue? Please tell me if there is any more information I can provide to that end. Best, Michela

5 years, 4 months

Re: Archiver "prototype" and disabling archiving at all

by Torge Riedel

Am 28.03.19 um 17:45 schrieb Abhilash Raj: > On Thu, Mar 28, 2019, at 9:18 AM, Torge Riedel wrote: >> Am 24.03.19 um 16:49 schrieb Mark Sapiro: >>> On 3/24/19 5:40 AM, Torge Riedel wrote: >>>> in the settings of a mailing list I can choose two archivers: >>>> "Hyperkitty" and "prototype". What is this archive "prototype" and how >>>> can I disable/remove/deinstall it? And how can I disable archiving at >>>> all, so no archiver can be chosen in the settings. >>> The prototype archiver stores messages individually in >>> var/archives/prototype/LIST_NAME/. >>> >>> You can disable the prototype archiver by putting >>> >>> [archiver.prototype] >>> enable: no >>> >>> in your mailman.cfg. To disable all archiving, just remove all the >>> [archiver.*] sections from your mailman.cfg or set them to 'enable: no' >>> >>> >> Hi Mark, >> >> thanks. This disabled the archivers, but there is still the "Archives" >> link on top of the page. Is it possible to remove it? Cause there is >> nothing to see there. I tried commenting "'hyperkitty'," in >> INSTALLED_APPS, but then I got a 500. > INSTALLED_APPS = ( > 'postorius', > 'django_mailman3', > # Uncomment the next line to enable the admin: > 'django.contrib.admin', > # Uncomment the next line to enable admin documentation: > # 'django.contrib.admindocs', > 'django.contrib.auth', > 'django.contrib.contenttypes', > 'django.contrib.sessions', > 'django.contrib.sites', > 'django.contrib.messages', > 'django.contrib.staticfiles', > 'django_gravatar', > 'allauth', > 'allauth.account', > 'allauth.socialaccount', > ) > > > This is how it should look like if you want to remove Hyperkitty. There > are a few other settings you should remove. > > https://gitlab.com/mailman/postorius/blob/master/example_project/settings.py > > This is a Postorius only configuration for reference. > > >> _______________________________________________ >> Mailman-users mailing list -- mailman-users(a)mailman3.org >> To unsubscribe send an email to mailman-users-leave(a)mailman3.org >> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >> Hi, I gave it a try, but I was not able to disable hyperkitty. I compared the settings in the link you gave and I see a lot of differences. Some of them I am not sure why they are missing in other example settings. Currently I would say, I will keep the archive link there until it is more clear for me how to set things up. Since archiving is disabled, there will be no data in the archive. That is okay for the moment. Regards Torge

7 years, 5 months

Re: Accept these non-members

by Stephen J. Turnbull

Lars Bjørndal writes: > All addresses, both addresses that I know has sent messages to the > list and others, are marked as MemberRole.nonmember> Action.defer Post from these nonmembers go through normal checks (spam, for example) before being distributed. > When I view non-members in postorius, I get some differences: > > Some ar marked: Regular List default, and others Regular Default > processing. "List default" means "this user has not made a choice, so Mailman will check what is 'normal' for the list in the list's configuration". In detail, Postorius is intended to allow users and list administrators to *modify* configurations. At delivery time, these configurations "cascade", typically in this way: - if this subscription has a setting, apply it, and return; if not - if the address this subscription delivers to has a setting, apply it, and return; if not - if the user who owns that address has a setting, apply it, and return; if not - if the list that is subscribed to has a setting, apply it, and return; - otherwise, use the fallback setting from the source code. In Postorius, the "no setting" option is displayed in such a way that the person considering changing the setting knows what the next level of the cascade is. "List default" means "this user has not made a choice, so Mailman will check what is 'normal' for the list in the list's configuration". "Default processing" is a regular option, that can be applied to this post. It means "check if the user is allowed to post at all, then check for reasons (eg, spam) why this post might not be OK". Usually "list normal" is also "Default processing", but it might be "Hold for moderator", for example. On the other hand, Mark's script will return the option that will be applied using the logic of the cascade. > The list is imported from Mm 2.1 a long time ago. I don't know if > that matters. I don't think it does. > Hm, this is a mystery to me. Is there othere places I can search > for addresses that are aloud to send to the list? I don't understand what you want. The "mailman shell interaction" that Mark posted earlier gives you exactly the list of members who can post to the specified list. If some are "trusted users" who don't go through the spam checker, etc, they are displayed with Action.accept. Other posters are displayed with Action.defer. But both will automatically be distributed as long as they appear to be legit posts (not spam, etc). Steve -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

6 months, 2 weeks

Re: moving list from mm3 -> mm3

by Mark Sapiro

On 12/8/23 08:01, Jens Günther wrote: > > This is a nice collection of the configuration of a certain list. Does > anybody know how I would get this data back to the newly created list in > the second working mm3-instance? Shouldn't it be possible via POST > command? I thought of something like: > > curl -u restadmin:restpass -d @short.domain -H "Content-Type: > application/json" localhost:8001/3.1/lists/&short.&domain/config > > But it returns {"title": "405 Method Not Allowed"} and I don't know > where to look in the docs, since it shows almost always a way through > mailman shell. You need a PUT command, not POST. Try the above with `-X PUT`. > ## Members, moderators, owners > > To export all members I normally run within mm-core-container as user > mailman the following command: > > mailman members &short.&domain > &short.txt > > To fill them back in, it can be done in Postorius (or is there a way > through API?). You can use Postorius -> Mass operations -> Mass subscribe to add the members, but you can't do that for owners and moderators. Also you lose information about the members such as Delivery status, Delivery mode and other user settings. > What I would love to know is how to get out Owners of the corresponding > lists and reimport them in the new one (which will be the same at the > end :-D but different instance). You can use the --role option with `mailman members` to get owners and moderators, but short of a custom script, you have to add them manually. > ## registered users > > This part is somehow tricky, since I have no clue how to do it. Some of > the mailinglist-admins don't want to bother their list-owners again with > registering newly on the other system. Is there a way to export all > users (I think I found them in the DB in the table auth_users, somehow > in combination with account_emailaddress) and get them over to the new > instance (actually I just need part of them, but that's another question > that I might solve lateron on my own). > > Maybe the answer is already here: > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… > -> but can somebody help to get this working (import/export)? That is not the answer. Those are Mailman core users, not Django (web login) users. You need to get the relevant entries from the auth_users and account_emailaddress tables and add them to the new DB. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 9 months

Re: Deactivate list without deleting it?

by Colin Watson

On Tue, Jan 16, 2018 at 10:59:28AM +0900, Stephen J. Turnbull wrote: > Colin Watson writes: > > > Ideally, I'd like mailing lists to have a "deactivated" state in > > addition to full deletion. In this state, the list would appear > > nonexistent for most purposes: incoming email would be rejected, > > Postorius would deny its existence, etc. > > [...] > > > Has there been any discussion of this in the past, or any advice as to > > implementation strategy? > > I don't recall anybody discussing this. Your use case is your use > case, but I think if we were going to implement this I'd probably want > "partial" deactivation where the archives remain available but no mail > is delivered, can't subscribe, etc. I'm also not sure I'd want > Postorius to deny it ever existed. That seems rather unfriendly > (again, I don't understand your use case, so that is not a comment on > your requirements). I possibly should have explained our situation in a little more detail. The way we have things set up with Mailman 2.1 is that any team in Launchpad (teams are basically just a collection of people, with varying policies on who can join them etc.) can have a mailing list if its administrators want one, and they enable it in the Launchpad web UI. If you want to subscribe to one of these lists, you join the team in question and you press the "Subscribe to mailing list" button. Launchpad runs the show and tells Mailman exactly what to do. So in fact we have all of Mailman's user interface disabled except for the list archives, and Postorius wouldn't come into it in our case - I probably shouldn't have confused things by bringing it up hypothetically. We'd probably want to do roughly the same kind of thing with Mailman 3, at least to start with, though we may well want to make some of HyperKitty's advanced features work with single-sign-on integration. I haven't looked into that in any detail yet. I can definitely see that both "preserve archives" vs. "hide archives" are potentially useful things to do. > It seems to me that dump, delete, and restore may be the best approach > for the HyperKitty side because HyperKitty maintains all that state. > Of course this could be done inside the database. Also, perhaps you > can (ab)use the ArchivePolicy enum by adding an "inactive" element, > but core has no way to enforce those on the archiver (which can be a > third party host like mail-archive.com) and I'm not sure HyperKitty > ever consults core about that once the archive is created. I'd been thinking more of a new enum in HyperKitty for the visibility state, since it does seem like quite an archiver-specific thing. (Dump/delete/restore would of course be possible, but it's somewhat cumbersome to do externally and it seems like an odd way to go about things internally given the ability to change the DB schema.) I agree that not all archiver implementations can support this. > I'm not sure what you mean about IArchiver; as far as I can see that > interface is sort of half-duplex: it provides the information core > needs *about* the archiver to do core's side of archiving, not for > core to communicate *with* the archiver. In fact all of the concrete > code is callbacks provided by the archiver, and once a message is > archived the core forgets about it. So this isn't "just" an > extension; it's a fundamental redesign of IArchiver. Well, IArchiver.archive_message sends a message from core to the archiver. I'd been thinking of something like IArchiver.set_list_visibility(mlist, visibility) which would send a message from core to the archiver to instruct it to show/hide the archives. It doesn't seem too out of line, though I'm not wedded to it either. I suppose that one alternative could be that we handle this in a Launchpad-specific add-on to HyperKitty, since at a minimum we'll need some of our own code there to deal with sign-in for private lists. So the same bit of custom code that determines whether a list's archives are private could hide them from everyone except their owner, or even deny their existence entirely. It sounds like maybe we'd be better off pursuing that? > I'm not sure that's not a good thing, but we do need to think about > it. ISTM we're gradually converging back on the monolithic approach > to MLM, with the distribution, administration, and archiving quite > tightly interwoven, and I'm not sure I like that. OTOH, we do get a > lot of requests for ever more bundling. Given our requirements, the decreased coupling in Mailman 3 is a very good thing, and I'm definitely not looking for more bundling. I hope I've clarified that above. Thanks, -- Colin Watson [cjwatson(a)ubuntu.com]

8 years, 8 months

Mailman-users search results for query "Postorius"