Search results for "Postorius" - Mailman-users

Re: New messages are not archived - may be a path issue

by Mark Sapiro

On 10/20/23 05:31, Wikinaut wrote: > > The built-in template (mailman-hyperkitty.cfg) perhaps needs to be fixed as well (hyperkitty wrong, archive correct)? > # However, if your Mailman installation is accessed via HTTPS, the URL needs > # to match your SSL certificate (e.g. https://lists.example.com/hyperkitty) > # base_url: http://localhost/mailman3/hyperkitty/ > > this line perhaps needs to be changed to > # base_url: http://localhost/mailman3/archives/ I agree that this is confusing because some of our docs recommend that urls.py contain ``` path('postorius/', include('postorius.urls')), path('hyperkitty/', include('hyperkitty.urls')), ``` and docs recommend ``` path('mailman3/', include('postorius.urls')), path('archives/', include('hyperkitty.urls')), ``` I.e. following the first suggestion, you would access Postorius and HyperKitty via `https://www.example.com/postorius/` and `https://www.example.com/hyperkitty/` respectively, but with the second, the urls would be `https://www.example.com/mailman3/` and `https://www.example.com/archives/` respectively. I'm going to address this by adding ``` path('postorius/', include('postorius.urls')), path('hyperkitty/', include('hyperkitty.urls')), ``` to mailman_web's urls.py so the either urls will work. See https://gitlab.com/mailman/mailman-web/-/issues/24 -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 6 months

Re: hello， Discussion on how to subscribe to themailing list

by Stephen J. Turnbull

朱超 writes: > Yes, I know why 404 is reported，The url should be postorius not be > mailman3, In the stock configuration both "mailman3" and "postorius" invoke the same view, and I'm fairly sure several templates invoke "mailman3" rather than "postorius". I believe the logic was that casual users will recognize "mailman3" more readily than "postorius", and similarly for "archive(s)" vs. "hyperkitty". > https://www.example.com/postorius/lists/$list_id/confirm/?token=$token, > and it report success. I am curious why there is no similar > processing logic for unsubscribing in postorius。 I don't understand what you're suggesting. A subscribed user necessarily has a confirmed address, and if a web administration app is running, they can log in and with a couple of clicks unsubscribe. Unsubscribe by mail does involve a confirmation step. As explained before, the reply confirmation is surely available to core; if you want I believe you can craft email templates to use the web confirmation either as an option or the preferred method. > Can we optimize for this？ What do you mean by "optimize"? If you mean fewer steps for the user, I believe the FAQ explains how to create a one-click unsubscription URL (at least that was possible with Mailman 2). There is a mild denial of service possibility, of course, but it doesn't involve third parties and is usually recoverable since the unsubscribe generates an email to the "victim" who can check archives in the majority of cases and easily resubscribe. > If you use mailman-web (include postorius and django-mailman3 and > django-allauth and so on) to set the template information, the > template obtained by mailman-core is obtained by requesting > mailman-web, No, the templates used by core and by Postorius are stored in different databases. It's true that you can use Postorius to set core's templates, but they're still stored in core's database, not in Django. They *must* be, because core needs to be able to send email even if there is no web interface at all. I suppose you could arrange that one could be set by the other. If you want to define a protocol so that any application that speaks the REST API can do this, I suppose it could be added to Mailman. But we can't depend on web administration being installed at all, and we can't depend on it being Postorius. Steve

3 years, 3 months

Re: Hyperkitty Missing Theme/Style Sheets?

by Abhilash Raj

Hi Andrew, On Wed, Nov 1, 2017, at 12:43 PM, Andrew Hodder wrote: > Well, that can't be true, I'm running DEBUG = False and Django is > certainly > trying to provide static files (as you'll see below): > > I found the issue in the nginx logs (it's connecting to both postorius > and > hyperkitty via uwsgi), it appears when I'm only viewing Hyperkitty's > pages, > I'm getting these type of errors (some changes inserted to hide my server > details): > > 2017/11/01 19:22:04 [error] 64082#0: *75 open() "/opt/mailman/postorius/ > example_project/static/CACHE/js/4ce1260ef558.js" failed (2: No such file > or > directory), client: 10.10.44.29, server: blah.blah.blah, request: "GET > /static/CACHE/js/4ce1260ef558.js HTTP/1.1", host: "blah.blah.blah", > referrer: "https://blah.blah.blah/hyperkitty/hyperkitty/list/ > mailinglist(a)domain.com/2017/10/" I see here that you are running Postorius and Hyperkitty a bit differently that presented in our docs. Settings inside example_project for each repositories are just examples, we use it for testing, and may not work best in production. We recommend that you instead use the mailman-suite[1] to run Postorius & Hyperkitty using a single Django installation. The process for doing so is documented here[2]. [1]: https://gitlab.com/mailman/mailman-suite [2]: http://docs.mailman3.org/en/latest/prodsetup.html#installing-web-ui > So it appears Hyperkitty is attempting to load static files from > postorius's side instead of it's own (I have postorius running under > https://domain.tld and hyperkitty running under > https://domain.tld/hyperkitty/ via nginx). I checked and confirmed the > variables in settings.py: > > STATIC_ROOT = os.path.join(BASE_DIR, 'static') > STATIC_URL = '/hyperkitty/static/' > STATICFILES_DIRS = ('/opt/mailman/hyperkitty/example_project/static/') > > And for good measure, here's the nginx config: > > ------------------------------ > > > > server { > listen 80; > server_name DOMAIN.TLD; > #Redirect to SSL > if ($scheme = http) { > return 301 https://$server_name$request_uri; > } > } > > server { > listen 443 ssl http2 default_server; > listen [::]:443 ssl http2 default_server; > server_name DOMAIN.TLD; > > ssl_certificate "/etc/pki/nginx/DOMAIN.TLD.crt"; > ssl_certificate_key "/etc/pki/nginx/private/DOMAIN.TLD.key"; > ssl_session_cache shared:SSL:1m; > ssl_session_timeout 10m; > ssl_ciphers HIGH:!aNULL:!MD5; > ssl_prefer_server_ciphers on; > > location / { > include uwsgi_params; > uwsgi_pass unix:/opt/mailman/postorius.sock; > } > > location ~ /hyperkitty(?<path_info>/.*|$) { > include uwsgi_params; > uwsgi_pass unix:/opt/mailman/hyperkitty.sock; > uwsgi_param PATH_INFO $path_info; > uwsgi_param SCRIPT_NAME /hyperkitty; > } > > #Make nginx aware of postorius static > location /static/ { > alias /opt/mailman/postorius/example_project/static/; > } > > #for hyperkitty static > location /hyperkitty/static/ { > alias /opt/mailman/hyperkitty/example_project/static/; > } I believe static files are all supposed be rooted at `/static` instead of `/hyperkitty/static`. > > error_page 404 /404.html; > location = /40x.html { > } > > error_page 500 502 503 504 /50x.html; > location = /50x.html { > } > } > > Any thoughts would be appreciated, I'm getting stumped on this one. I have never tried to run 'example_project' in production before, so I am not exactly sure about the reason. This seems overly complicated and I strongly recommend that you run Postorius and Hyperkitty from a single installation, unless you have a very good use case to run them separately. > > > Sincerely, > > Andrew Hodder > Systems Administrator > Support Operations, Afilias > E-mail: drew(a)afilias.info > Phone: +1 416.673.4164 > Fax: +1 416.646.1541 > > On Fri, Oct 27, 2017 at 11:01 AM, Simon Hanna <simon(a)hannaweb.eu> wrote: > > > > > On 10/27/2017 04:58 PM, Andrew Hodder wrote: > > > >> Sure thing: > >> > >> https://imgur.com/a/EXv3B > >> > >> Looks like your stylesheets aren't loaded. > > > > if you are running in production (with DEBUG=False) django won't serve > > static files > > You need to configure your webserver to do that. > > You need to make sure to load all the static files using > > `python manage.py collectstatic` > > to gather everything and put them in one directory that can then be served > > by your webserver > > > > > > > > _______________________________________________ > > Mailman-users mailing list > > mailman-users(a)mailman3.org > > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > > > _______________________________________________ > Mailman-users mailing list > mailman-users(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ -- Abhilash Raj maxking(a)asynchronous.in

8 years, 5 months

Rolling releases for Container Images and Funding Campaign for Mailman

by Simon Hanna

>>> These images are built using git-heads *only* if they are passing our >>> test suite and are re-generated weekly. You should be aware that while >>> all these components are tested with their individual test suites, their >>> combination might sometimes not be stable. This will get you >>> updates/bug-fixes much faster :) >> This contradicts what you said in my merge request for Postorius >> https://gitlab.com/mailman/postorius/merge_requests/232#note_43388756 >> >> You either use released versions, or make sure that the master branches >> are always compatible. You can't have both with the current development >> model. > Not exactly, I still believe all our git-heads should be compatible with > released (i.e. stable) versions of dependencies, regardless of the fact > that we maintain those dependencies. > > Also, there is at least one test per-project which tests with git-heads > of dependencies we maintain, so that we know if we make any incompatible > changes. > > I am not sure what in the current development model prevents us > to do both? > > The story for container images is different than testing with git-heads. > We need better integration testing for the entire suite to be stable in > conjunction, rather than independently. In fact, containers might be the > perfect way to actually do the integration testing. Scenario: Core changes something about rest that is backwards incompatible. The change is commited to master. Since your containers use the master branches, all future builds will fail until mailmanclient and postorius/hyperkitty. If you want to always have Postorius (and others) compatible with the latest release of master, development for Postorius will be a Pain, because you can't use the master branch of mailman for testing and quick changes. Also your containers and all integration tests that can be done with them will always fail. Until you fix Postorius and the other clients... So why not just have the master branches always compatible and make life easier for developers. I don't see a good reason why you want to do it the other way round... Any bug in core that affects Postorius will also just remain there until you release a new version of core. If you really really want to have it your way, there have to be more frequent releases. >>> - Improve the container images to work with new micro-services >>> architecture, >>> to achieve scaling and redundancy in services. >> The current bottleneck is the rest api from core. IMO bulk actions, >> filtering and sorting should be added there before trying to have >> multiple postorius/hyperkitty instances serving the same core... > I didn't say they will be served from the same core ;-) > > Yes, the Core's API can be further improved to be more efficient. But > that > doesn't prevent us from scaling. I understand there are issues around > multiple > instances of containers, but I have ideas to get around most of them. I just don't want that people that have issues with big installations get the answer: We know of that issue, please deploy Mailman on X containers/machines as a workaround

8 years, 5 months

Re: Please help: Mailaman3 -

by Abhilash Raj

On Tue, Sep 1, 2020, at 9:55 AM, Jane Anara via Mailman-users wrote: > Hello everyone, > > I hope my questions don't sound ridiculous. In my team, I have been > tasked with moving our mailman installations from version 1:2.1 to the > current version, mailman3. I followed the documentations online and > installed all the components, created a Django project and configured > settings.py and url.py. However, when I run the development server, I > receive the following on the body of Postorius main page: > > Page not found > This page either doesn't exist, or it moved somewhere else. > > Clicking on the "Lists" menu link, I receive the following: > > HTTP Error 404: <!DOCTYPE html> <html lang="en"> <head> <meta > charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> > <meta name="viewport" content="width=device-width, initial-scale=1"> > <title>example.com</title> <link rel="shortcut icon" > href="/static/postorius/img/favicon.ico"> <link rel="stylesheet" > href="/static/postorius/libs/bootstrap/css/bootstrap.min.css"> <link > rel="stylesheet" href="/static/django-mailman3/css/main.css"> <link > rel="stylesheet" href="/static/postorius/css/style.css"> <link > rel="stylesheet" > href="/static/postorius/libs/fonts/font-awesome/css/font-awesome.min.css" type="text/css" media="all" />    </head> <body> <nav > class="navbar navbar-expand-md navbar-light bg-light navbar-default"> > <div class="container"> <div class="navbar-header"> <button > type="button" class="navbar-toggler collapsed" data-toggle="collapse" > data-target="#header-nav" aria-expanded="false"> <span > class="sr-only">Toggle navigation</span> <span class="fa > fa-bars"></span> </button> <a class="navbar-brand" > href="/mailman3/lists/"><span><img > src="/static/postorius/img/mailman_logo_small_trans.png" alt="Mailman > logo"/> Postorius</span></a> </div> <div class="collapse > navbar-collapse" id="header-nav"> <ul class="nav navbar-nav mr-auto"> > <li class="nav-item"><a href="/mailman3/lists/" class="nav-link"> <span > class="fa fa-envelope"></span> Lists </a></li> <li class="nav-item"><a > href="/archives/" class="nav-link"> <span class="fa fa-comment"></span> > Archives </a></li> </ul> <ul class="nav navbar-nav navbar-right"> <li > class="nav-item"><a class="nav-link" > href="/accounts/login/?next=/3.1/lists"> <span class="fa > fa-sign-in"></span> Lo > gin </a></li> <li class="nav-item"><a class="nav-link" > href="/accounts/signup/?next=/3.1/lists"> <span class="fa > fa-user-plus"></span> Sign Up </a></li> </ul> </div> </div> </nav> <div > class="container" role="main"> <h1>Page not found</h1> <div > class="alert alert-danger">This page either doesn't exist, or it moved > somewhere else.</div> </div> <footer class="footer"> <div > class="container"> <p class="text-center"> <a > href="https://postorius.readthedocs.org">Postorius Documentation</a> > • <a href="http://list.org">GNU Mailman</a> • Postorius > Version 1.3.3 • Happy Mailman Day! </p> </div> </footer> <script > src="/static/postorius/libs/jquery/jquery-1.11.3.min.js"></script> > <script > src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.11.0/umd/popper.min.js" integrity="sha384-b/U6ypiBEHpOf/4+1nzFpr53nxSS+GLCkfwBdFNTxtclqqenISfwAzpKaMNFNmj4" crossorigin="anonymous"></script> <script src="/static/postorius/libs/bootstrap/js/bootstrap.min.js"></script> <script src="/static/d > jango-mailman3/js/main.js"></script> <script > src="/static/postorius/js/script.js"></script> </body> </html> > > > So far, the Postorious component is where there seem to be issues, all > other link or component produce no errors thus far. Please advice on > how I can troubleshoot this. I herein include the relevant sessions of > my settings.py file and url.py which I have tweaked with various > configurations to no avail. > > settings.py: > > # Application definition > > INSTALLED_APPS = [ > # Apps added for mailman components > 'hyperkitty', > 'postorius', > 'django_mailman3', > 'mailmanclient', > # Other useful apps > 'rest_framework', > 'django_gravatar', > 'compressor', > 'haystack', > 'django_extensions', > 'django_q', > 'allauth', > 'allauth.account', > 'allauth.socialaccount', > # end other useful apps > 'django.contrib.sites', > 'django.contrib.admin', > 'django.contrib.auth', > 'django.contrib.contenttypes', > 'django.contrib.sessions', > 'django.contrib.messages', > 'django.contrib.staticfiles', > ] > > url.py: > > urlpatterns = [ > #Django admin > path('admin/', admin.site.urls), > path('mailman3/', include('postorius.urls')), > path('archives/', include('hyperkitty.urls')), > path('', include('django_mailman3.urls')), > path('accounts/', include('allauth.urls')), > #path('postorius', include('postorius.urls')), > #path('lists/', list_index), > path('search/', include('haystack.urls')), > #url(r'^$', list_index), > ] > > Note that when I uncomment the lines relating to list_index or use > configurations similar to that on mailman-suit, I get: > > NameError: name 'list_index' is not defined. You need to use the view function with `reverse_lazy` to actually get the named `reverse_lazy` view. Did you try using the exact urls.py from mailman-suite project[1]? It has been tested to work locally and other place. [1]: https://gitlab.com/mailman/mailman-suite/-/blob/master/mailman-suite_projec… > > Looking forward to any help anyone can render. > > Thank you! > > Regards, > Jane. > _______________________________________________ > 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/ > -- thanks, Abhilash Raj (maxking)

5 years, 7 months

Re: Starting new thread in Postorius -> disappears

by Mark Sapiro

On 11/21/2017 01:53 AM, Thor Atle Rustad wrote: > I have had this working before, so I guess it's a simple setup error. > > When I send a message from the Postorius interface, it is neither sent out > or stored. I briefly see this message: "Your reply has been sent and is > being processed.", and then nothing happens. I assume you mean HyperKitty. Postorius has no facility for posting messages to a list. > I have installed maxking's docker-mailman and copied my old setup with > basic stuff like passwords and such. The only new thing is that I'm now > running in userspace by putting in /etc/subuid and subguid: When you post from HyperKitty, HyperKitty creates a django.core.mail.EmailMessage() instance and calls it's send() method which causes Django to send the message to the list address. It then has to be received and processed by Mailman the same as any email post before it will appear in the archive. Are you running with DEBUG = True. If so, Hyperkitty won't send the mail. If DEBUG = False and normal posting is working, perhaps there is some Postfix issue in delivery of the message from Django to Mailman. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 5 months

Re: Changes in Django admin interface are not syncing to postorius gui /database

by Mark Sapiro

On 11/11/24 04:17, Ulf R. wrote: > Now remains one question: We have a (internal) Active Directory (AD) Authentication for Mailman3. > So everyone who wants to work as an owner nor moderator must be an AD-User. > In hyperkitty I am able to assign these list rights directly to AD-Loginnames. > With the logic above I have to assign these rights in postorius too by assining the mail address of the users AD-Account? (I see no AD-Data here). You are conflating Postorius, which is simply a web management UI for Mailman core, with Mailman core itself. I suppose it's not really important, but when you think of access rights in Postorius, these are actually in mailman core. > Or would it works to assing the mail address of the users AD-Account first an then the allocation will automaticly synced to hyperkitty - maybe using the mail address as key? > What would be the best practice for owner/moderator user management? Just ensure that list owners and moderators are using the email address of their AD-Account. This will propagate to HyperKitty. You shouldn't need to manipulate HyperKitty access rights directly at all. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 5 months

mailman.cfg (use_https: yes) fails

by Wolfgang Bock

Hello, I configuered 3 domains in postorius https://[mydomain]/mailman3/postorius/domains/ ... also shown here: https://[mydomain]/mailman3/admin/sites/site/ (django) I installed mailman3 with debian command apt-get install mailman3-full. The package mailman3-full is described as follows: Paket: mailman3-full (3.2.1-1) (for debian-buster, W.B.) ... Betreuer: * Debian Mailman Team <mailto:pkg-mailman-hackers@lists.alioth.debian.org> (QS-Seite <https://qa.debian.org/developer.php?login=pkg-mailman-hackers%40lists.aliot…>, E-Mail-Archiv <https://lists.alioth.debian.org/pipermail/pkg-mailman-hackers/>) * Pierre-Elliott Bécue <mailto:peb@debian.org> (QS-Seite <https://qa.debian.org/developer.php?login=peb%40debian.org>) * Jonas Meurer <mailto:jonas@freesources.org> (QS-Seite <https://qa.debian.org/developer.php?login=jonas%40freesources.org>) Full Mailman3 mailing list management suite (metapackage) This is GNU Mailman, a mailing list management system. This metapackage depends on all components of the full Mailman3 suite: * mailman3: The core Mailman3 delivery engine * mailman3-web: Django project integrating Mailman3 postorius and hyperkitty * python3-mailman-hyperkitty: Mailman3 server plugin for Hyperkitty archiver ..... That's the output of # mailman info GNU Mailman 3.2.1 (La Villa Strangiato) Python 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.3.0] config file: /etc/mailman3/mailman.cfg db url: mysql+pymysql://[-secret-][mydomain]/mailman3?charset=utf8&use_unicode=1 devmode: DISABLED REST root url: http://localhost:8001/3.1/ REST credentials: restadmin:[-secret-] I dont know what version of mailman client is included in the package. Should I wait until an update includes a higher Version of the mailman-client? In this context I faced a strange behavior: In the database mailman3web in table django_site are listed several domains, either in the django-domain-management site https://[mydomain]/mailman3/admin/sites/site/ id domain name 1 example.com Example.com 2 [mydomain-1] [mydomain_name_1] 3 [mydomain-2] [mydomain_name_2] 4 [mydomain-3] [mydomain_name_3] In case I delete line 1 with the id 1, in the database or in the django-web-site, postorius fails to work. After re-inserting this line, postorius works again. Regards Wolfgang Am 16.11.2019 um 01:02 schrieb Mark Sapiro: > On 11/15/19 3:45 AM, Wolfgang Bock via Mailman-users wrote: >> That doesn't solve the problem. I changed that in mailman-web.py >> (MAILMAN_REST_API_URL = https://localhost:8001) and after that in >> mailman.cfg (use_https: yes). But got the same errormessage on postorius >> website. > > You posted this log excerpt: > > Nov 14 23:20:41 2019 (28590) 127.0.0.1 - - "GET > /3.0/lists?advertised=true&count=0&page=1 HTTP/1.1" 200 90 > Nov 14 23:20:41 2019 (28590) 127.0.0.1 - - "GET > /3.0/lists?advertised=true&count=10&page=1 HTTP/1.1" 200 606 > Nov 14 23:20:41 2019 (28590) 127.0.0.1 - - "GET /3.1/domains HTTP/1.1" > 200 1438 > Nov 14 23:20:41 2019 (28590) 127.0.0.1 - - code 400, message Bad > HTTP/0.9 request type > > > The first 3 GETs are a normal sequence of GETs from Postorius when you > go to the Mailing Lists view. That should be followed by a GET like "GET > /3.1/domains/domain.tld HTTP/1.1" where domain.tld is a configured > domain. Do you have any domains configured?/0.9'? > > I'm not sure what the issue is. You have an older version of > mailmanclient < 3.2.3a1 which uses httplib2 rather than requests. > https://pypi.org/project/httplib2/ says: > > HTTP and HTTPS > HTTPS support is only available if the socket module was compiled > with SSL support. > > but I don't think this can be the issue because the first 3 GETs work. > > You might try upgrading mailmanclient to 3.3.0. I don't know if that > will help, but it may. >

6 years, 5 months

Re: Postorius: Show only own lists

by Thor Atle Rustad

2018-01-23 14:37 GMT+01:00 Simon Hanna <simon(a)hannaweb.eu>: > On 01/23/2018 12:10 PM, Thor Atle Rustad wrote: > >> Imagine an installation with 500+ mailing lists and almost as many local >> admins that are supposed to maintain their own local lists with a few >> local >> members. As site admin, I see all 500+ lists, but I was expecting *local* >> admins to see only the lists they maintain. I have set all lists to >> "advertised = False", so they are hidden from ordinary view. Is there a >> way >> to show only relevant lists to local admins? >> > Are we talking about Postorius or Hyperkitty? > There is no way for users that do not have the django superuser permission, > to see unadvertised lists in the Postorius list index. I just > doublechecked the source. > There is an issue about list filtering/search for the index page. > I believe I wrote Postorius in the subject line, but it may not be so obvious. So yes, in Posterius I would like to hide the lists from email harvesters, while relatively "untrusted" admins should have access to basic operations on the one list he/she "owns" (and without having to browse through 50 pages of mailing lists). Somehow I don't think 500 superusers in our system is a good idea!

8 years, 3 months

Slow performance when listing members on Postorius

by Alan So

We are about to upgrade to Mailman core 3.3.9 and Postorius 1.3.10. We notice that for setup with large number of members, the performance is much slower when listing members on web (Postorius). Further troubleshooting show that there are quite a number of API calls which do not appear in Mailman core 3.3.5 and Postorius 1.3.6 when we list members. [17/Apr/2024:14:12:22 +0800] "GET /3.1/members/33a6266d0a04472c8d5d6c78869a964c/preferences HTTP/1.1" 200 156 "-" "GNU Mailman REST client v3.3.5" [17/Apr/2024:14:12:22 +0800] "GET /3.1/members/7a18b7cb90a34ac98881a3f01b5488d1/preferences HTTP/1.1" 200 156 "-" "GNU Mailman REST client v3.3.5" [17/Apr/2024:14:12:22 +0800] "GET /3.1/members/61c6c3e2aaf443babd3bd191519b0424/preferences HTTP/1.1" 200 156 "-" "GNU Mailman REST client v3.3.5" [17/Apr/2024:14:12:22 +0800] "GET /3.1/members/8dd681165b8c436fac6793cae1ed2c27/preferences HTTP/1.1" 200 156 "-" "GNU Mailman REST client v3.3.5" Further tests showing that each database query using "_member_id" in table member can take as much as 0.3 to 0.5 seconds for some large installations. The default 25 members per page mean that it will take at least 7.5 to 12.5 seconds. Changing to 200 members per page will take even longer time. We wonder whether "_member_id" should be indexed just like most other id in the database mailman_core in order to solve the issue. Or are there any other workarounds? +----------------------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +----------------------+--------------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | _member_id | char(32) | YES | | NULL | | | role | int(11) | YES | MUL | NULL | | | list_id | varchar(255) | YES | MUL | NULL | | | moderation_action | int(11) | YES | | NULL | | | address_id | int(11) | YES | MUL | NULL | | | preferences_id | int(11) | YES | MUL | NULL | | | user_id | int(11) | YES | MUL | NULL | | | bounce_score | int(11) | YES | | NULL | | | last_bounce_received | datetime | YES | | NULL | | | last_warning_sent | datetime | YES | | NULL | | | total_warnings_sent | int(11) | YES | | NULL | | +----------------------+--------------+------+-----+---------+----------------+

2 years

Mailman-users search results for query "Postorius"