Search results for "Postorius" - Mailman-users

Re: Various patches for mm3 stable 3.3.1

by Mark Sapiro

On 9/30/20 6:57 AM, Ruth Ivimey-Cook wrote: > > 1. If I do not set up 'individual' or 'full' personalisation, all is > well and the default footer templates are expanded as expected. However > setting up personalisation causes template expansion to fail > completely, and messages get sent with a blank expansion. Your mailman-debug.patch makes changes to mailman/handlers/decorate.py including wrapping all the relevant code in a try:/except: that logs any exception. If you set the level for logging.error to debug, what do you get in the log? This issue doesn't occur in the unpatched code on my servers - personalized footers work fine - so I think the problem must be something in your patch. > 2. I would find the postorius UI much easier to cope with if the > default template was 'populated' into the UI wherever it was non-blank, > rather than the UI starting off as if no templates were defined at all. This is <https://gitlab.com/mailman/postorius/-/issues/366>. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 3 months

Re: Moderate mails from owner

by Henrik Rasmussen

Mark Sapiro wrote: > This can happen in a few ways., If this list was originally imported > from Mailman 2.1 by the 'mailman import21' command, there may be a > legacy accept_these_nonmembers attribute for the list. If so, and if a This makes sense. The list was in fact imported from Mailman 2.1. > You need to check the list's accept_these_nonmembers attribute and the > non-member address's moderation action. > > If you have recent Postorius, you can see nonmembers and their options > from the 'users' -> Non-members view. I currently have Postorius 1.2.2 so I don't have it yet. > mailman shell -l list.example.com The sender is in the list of accept_these_nonmembers, however the command memb.moderation_action = m.default_nonmember_action doesn't seem to remove it from accept_these_nonmembers. bash-4.3# mailman shell -l [LISTNAME].lists.example.com Welcome to the GNU Mailman shell The variable 'm' is the [LISTNAME].lists.example.com mailing list >>> m.accept_these_nonmembers ['listadmin(a)senderdep.example.com'] >>> memb = m.nonmembers.get_member('listadmin(a)senderdep.example.com') >>> memb.moderation_action <Action.accept: 3> >>> memb.moderation_action = m.default_nonmember_action >>> m.accept_these_nonmembers ['listadmin(a)senderdep.example.com'] -- Henrik

6 years, 8 months

Re: Struggle on upgrading mailman3-web to new version - Not Found: /mailman//

by Mark Sapiro

On 10/25/21 1:45 AM, Stefan Bauer wrote: > Dear Users, > > I recently upraded mailman3 from Ubuntu 18 to 20. After accessing the > web-interface via > > https://my.mailinglistserver.local/mailman3/postorius/lists/ > > I receive > > Not Found: /mailman//postorius/lists/ > [pid: 1346851|app: 0|req: 4/4] 10.254.253.12 () {70 vars in 1369 bytes} > [Mon Oct 25 10:39:59 2021] GET /mailman3/postorius/lists/ => generated 2821 > bytes in 12 msecs (HTTP/1.1 404) 5 headers in 155 bytes (1 switches on core > 1) > > Where does the wrong path come from (mailman vs. mailman3) See the thread at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… ... > <IfModule mod_proxy_uwsgi.c> > ProxyPass /mailman3/favicon.ico ! > ProxyPass /mailman3/static ! > ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ > </IfModule> Others have found that removing the trailing slash from ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ to make it ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost fixes the issue. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 2 months

Re: Problem with redirection when entering alias without a / at the end

by Mark Sapiro

On 3/19/21 2:55 PM, Jens Günther wrote: > > When I want to get to Mailman Starting Page now I need to Enter the > following URL: https://mailman.xyz.de/mailman3/ to be directly > redirected as expected to > https://mailman.xyz.de/mailman3/postorius/lists/ -> works. > > Problem: When leave out the slash at the end and I ONLY enter the > following URL: https://mailman.xyz.de/mailman3 -> then I'm wrongly > redirected to a page, taht does not exist: > https://mailman.xyz.de/mailman/postorius/lists/ -> 404 Huh? that is the same URL as the one above that you say works. Do you mean https://mailman.xyz.de/mailman/postorius/lists without the slash or what. > Where can I change this misbehaviour? In Apache-conf everything seems as > it'S in the docs, for the vHost I do not have any other custom settings. What is the exact content of your RedirectMatch or ReweriteRule or whatebver you are using? -- 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

mailman-web migrate fails with sqlite3.IntegrityError: UNIQUE constraint failed: account_emailaddress.email

by Stefan Bauer

Dear Users, trying to update mailman3 to lastest version, we fail during mailman-web migrate with: Operations to perform: Apply all migrations: account, admin, auth, contenttypes, django_mailman3, django_q, hyperkitty, postorius, sessions, sites, socialaccount Running migrations: Applying account.0006_emailaddress_lower...Traceback (most recent call last): File "/opt/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py", line 89, in _execute return self.cursor.execute(sql, params) File "/opt/mailman/venv/lib/python3.10/site-packages/django/db/backends/sqlite3/base.py", line 328, in execute return super().execute(query, params) sqlite3.IntegrityError: UNIQUE constraint failed: account_emailaddress.email We found a workaround to fake the migration with migrate --fake Operations to perform: Apply all migrations: account, admin, auth, contenttypes, django_mailman3, django_q, hyperkitty, postorius, sessions, sites, socialaccount Running migrations: Applying account.0006_emailaddress_lower... FAKED Applying account.0007_emailaddress_idx_email... FAKED Applying account.0008_emailaddress_unique_primary_email_fixup... FAKED Applying account.0009_emailaddress_unique_primary_email... FAKED Applying django_q.0015_alter_schedule_schedule_type... FAKED Applying django_q.0016_schedule_intended_date_kwarg... FAKED Applying django_q.0017_task_cluster_alter... FAKED Applying django_q.0018_task_success_index... FAKED Applying postorius.0019_alter_emailtemplate_data... FAKED And mailman 3 is still processing mails. I'm unsure if i should recover from snapshot or keep it going? Could this be some duplicate users with same mail-address? I have at least spotted one user and delete him. thank you. Stefan

10 months, 3 weeks

Re: mailman3 postorius cannot retrieve template

by Mark Dadgar

On Nov 4, 2021, at 3:05 PM, Andreas Barth <aba(a)ayous.org> wrote: > * Quanah Gibson-Mount (quanah(a)symas.com) [211104 22:59]: >> >> >> --On Thursday, November 4, 2021 8:25 AM -0700 Mark Sapiro >> <mark(a)msapiro.net> wrote: >> >>> On 11/4/21 5:04 AM, Wolfgang Bock via Mailman-users wrote: >>>> >>>> My conclusion: >>>> I ask you to consider these experiences in an update for the mailman3 >>>> packages in debian bullseye. It would save time, questions and nerves. >>> >>> >>> Issues with Debian packaging should be directed to Debian. >> >> Or as previously discussed, the debian packages should be avoided entirely. > > I strongly disagree with that statement. > > Distribution packages have their own up- and downsides. Of course, how > they are done is to be discussed with the distribution, so: if > something is wrong with a debian package, please follow the > instructions on bugs.debian.org on reporting bugs. > > However, they have the advantage that they're integrated with the > distribution. They have the disadvantage that they're stable for some > time - that is why it's called a stable release. If they have all the > features someone wants, they usually work fine (and my first > mm3-installation was the default debian package). If one looks for > bleeding edge, of course that's not what one can expect from a > distribution package - but that's also a feature. You left out the fact that the distro edition of mailman3 has very poor support because Debian doesn’t know how to do it and the setup is different enough from vanilla that this community has a hard time supporting it as well. You can certainly try to run it, but I’m willing to bet that you’ll regret it. Having tried it myself, I can’t in good conscience recommend it to anyone. The bottom line is that, IMHO, distro works great for fairly mature projects. MM3 isn’t that yet. YMMV, my $0.02, you get what you pay for, etc. - Mark ----- mark(a)pdc-racing.net | 408-348-2878

4 years, 2 months

Re: Footer from templates not working - DB issue?

by Hans Mayer

Hi Mark, many thanks for this hint. I updated table "template" and replaced "localhost" with the real name and it worked. // Hans -- On 25.09.22 19:28, Mark Sapiro wrote: > On 9/25/22 05:26, mailman--- via Mailman-users wrote: >> Dear All, >> I have a similar issue. Also on Debian 11. Also installed as Debian >> PKG. It's version GNU Mailman 3.3.3 (Tom Sawyer) >> I am using sqlite3. When I do the SQL-query I get an URI which is in >> multiple reasons wrong >> http://localhost/mailman3/postorius/api/templates/list/....../list:member:r… >> > > The initial part of that URL is set from the Django setting > `POSTORIUS_TEMPLATE_BASE_URL`. If that is set to > `http://localhost/mailman3/`, it should probably be just > `http://localhost/`. > > >> OK - the hostname could be changed but the path is not existing at all. >> There is no file "list:member:regular:footer" on the complete >> filesystem. > > It's not a file. It refers to an entry in the postorius_emailtemplate > table in the database which is retrieved via the Postorius API. >

3 years, 3 months

Re: Problem with redirection when entering alias without a / at the end

by Mark Sapiro

On 3/19/21 3:12 PM, Jens Günther wrote: > > > -> the first one works and leeds to > https://mailman.xyz.de/mailman3/postorius/lists > -> the second one redirects to > https://mailman.xyz.de/mailman/postorius/lists > -> which does not exist, since Apache-alias is only for mailman3 Sorry, I missed that it was mailman vs mailman3. > > I only use the apache-conf given in the documentation: > > <code> > Alias /mailman3/favicon.ico > /var/lib/mailman3/web/static/postorius/img/favicon.ico > Alias /mailman3/static /var/lib/mailman3/web/static > > <Directory "/var/lib/mailman3/web/static"> > Require all granted > </Directory> > > <IfModule mod_proxy_uwsgi.c> > ProxyPass /mailman3/favicon.ico ! > ProxyPass /mailman3/static ! > ProxyPass /mailman3 > unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ > </IfModule> > </code> I don't use uwsgi so I can't advise on its configuration, but do you have USE_X_FORWARDED_HOST = True SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https') in your Django settings? -- 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

Error while mass operation, no progress display while mass operation is running

by Markus Grandpré

Dear List, At the University of Konstanz we have mailing list administrators who frequently add and remove up to 10000 (and sometimes more) list members. I have therefore tested the “Mass subscription” and “Mass removal” operations and found that both the “Remove ALL members” operation and the “Mass subscription” operation report an internal server error on the website, but continue to run in the background until all new members have been successfully added or deleted. Unfortunately, I have not found any error message in the log files. I also tested that mass operations “Remove listed users” and “Remove Selected” ran successfully and without any errors. Regardless of whether a mass operation process runs without errors or continues to run despite an error, I find it hard that Postorius does not display the progress of such a mass operation in order to monitor the process, as mass operations with more than 1000 members are very time-consuming. Perhaps this could be changed in a future version of Postorius? Best Markus -- Markus Grandpré Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung, Lehre und Infrastruktur, Tel: ++49 7531 88 4342

11 months, 2 weeks

Re: Auto discard after max_days_to_hold not working.

by Hitashi mancho

Thank you so much, Mark and Stephen, for the quick action and response. Waiting for the next release. On Tue, Apr 29, 2025 at 10:52 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 4/28/25 10:55, Mark Sapiro wrote: > > > > `mailman import21` will import the setting, but per the above comment, > > it doesn't yet work. The setting exists and is exposed in REST, but it > > appears it is not actually implemented. > > > This is now implemented for the next release. See > https://gitlab.com/mailman/mailman/-/issues/1215 and > https://gitlab.com/mailman/mailman/-/merge_requests/1346 for Mailman > core and https://gitlab.com/mailman/postorius/-/issues/628 and > https://gitlab.com/mailman/postorius/-/merge_requests/1001 for Postorius. > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > > _______________________________________________ > 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/ > Archived at: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > This message sent to huhamails(a)gmail.com >

8 months, 3 weeks

Mailman-users search results for query "Postorius"