Search results for "Postorius" - Mailman-users

Re: Hipperkitty failing to archive messages in a list

by Mark Sapiro

On 1/5/22 4:01 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote: > > pip install --upgrade --force-reinstall --no-deps --no-cache-dir > django-mailman3 mailman mailman-hyperkitty mailmanclient postorius > django hyperkitty > > su -m mailman3 -c "python3 manage.py collectstatic" > su -m mailman3 -c "python3 manage.py migrate" > > In this last point I've received some warnings of this kind: > > *-*-*-*-*-*-* > > WARNINGS: > account.EmailAddress: (models.W042) Auto-created primary key used when > not defining a primary key type, by default 'django.db.models.AutoField'. > HINT: Configure the DEFAULT_AUTO_FIELD setting or the > AccountConfig.default_auto_field attribute to point to a subclass of > AutoField, e.g. 'django.db.models.BigAutoField'. > account.EmailConfirmation: (models.W042) Auto-created primary key used > when not defining a primary key type, by default > 'django.db.models.AutoField'. > > ... > > HINT: Configure the DEFAULT_AUTO_FIELD setting or the > SocialAccountConfig.default_auto_field attribute to point to a subclass > of AutoField, e.g. 'django.db.models.BigAutoField'. This is from Django >=3.2 can be fixed by adding DEFAULT_AUTO_FIELD = 'django.db.models.AutoField' to your settings. This has been done in HyperKitty's example_project/settings.py for the not yet released 1.3.6 version. These warnings are only warnings, they aren't fatal. ... > Running a 'su -m mailman3 -c "python3 manage.py makemigrations" shows > the same warning listed before and some new errors: > > *-*-*-*-*-*-* > > Migrations for 'postorius': > /usr/local/lib/python3.7/site-packages/postorius/migrations/0017_alter_emailtemplate_name.py > > - Alter field name on emailtemplate > Traceback (most recent call last): > File "manage.py", line 10, in <module> > execute_from_command_line(sys.argv) > File > "/usr/local/lib/python3.7/site-packages/django/core/management/__init__.py", > line 419, in execute_from_command_line > utility.execute() > File > "/usr/local/lib/python3.7/site-packages/django/core/management/__init__.py", > line 413, in execute > self.fetch_command(subcommand).run_from_argv(self.argv) > File > "/usr/local/lib/python3.7/site-packages/django/core/management/base.py", > line 354, in run_from_argv > self.execute(*args, **cmd_options) > File > "/usr/local/lib/python3.7/site-packages/django/core/management/base.py", > line 398, in execute > output = self.handle(*args, **options) > File > "/usr/local/lib/python3.7/site-packages/django/core/management/base.py", > line 89, in wrapped > res = handle_func(*args, **kwargs) > File > "/usr/local/lib/python3.7/site-packages/django/core/management/commands/makemigrations.py", > line 190, in handle > self.write_migration_files(changes) > File > "/usr/local/lib/python3.7/site-packages/django/core/management/commands/makemigrations.py", > line 228, in write_migration_files > with open(writer.path, "w", encoding='utf-8') as fh: > PermissionError: [Errno 13] Permission denied: > '/usr/local/lib/python3.7/site-packages/postorius/migrations/0017_alter_emailtemplate_name.py' > > > *-*-*-*-*-*-* > > The file > '/usr/local/lib/python3.7/site-packages/postorius/migrations/0017_alter_emailtemplate_name.py' > does not exist at all makemigrations is trying to create that migration and you don't have permission to create the file. I don't know why it's trying to do that. Postorius 1.3.6 has migrations through 0016_auto_20210810_2157.py and shouldn't need more. To you have modificationd to Postorius? > Despite the error, I did a 'su -m mailman3 -c "python3 manage.py > compress"' and the subsequent "django-admin compilemessages" in > > /usr/local/lib/python3.7/site-packages/postorius, ../hyperkitty and > ../django_mailman3 > > And the log continues showing the same error when trying archive a new > message. > > ERROR 2022-01-05 12:27:31,406 6988 hyperkitty.views.mailman The > MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. > ERROR 2022-01-05 12:27:31,418 6988 hyperkitty.views.mailman The > MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. > ERROR 2022-01-05 12:27:31,685 6988 hyperkitty.views.mailman The > MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. > ERROR 2022-01-05 12:27:32,045 6988 hyperkitty.views.mailman The > MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. > ERROR 2022-01-05 12:27:32,070 6988 hyperkitty.views.mailman The > MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. > ERROR 2022-01-05 12:27:32,093 6988 hyperkitty.views.mailman The > MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. These messages come from some HyperKitty version between commit b415d29d6cc59b3270c35b03ba3313dd03450271 Mon Jun 21 00:11:48 2021 -0700 and commit c6272f3ef8375865382d0741d3d371a0dc41508a Fri Oct 8 06:32:06 2021 +0000 They do not come from HyperKitty 1.3.5 but from something later than 1.3.4 which makes be think your mailman-hyperkitty version is not 1.2.0 either. I suggest you do pip install --upgrade hyperkitty mailman-hyperkitty and ensure it installs hyperkitty 1.3.5 and mailman-hyperkitty 1.2.0 -- 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

Mailman Core 3.3.1 release

by Abhilash Raj

Hey Everyone, I am pleased to announce Mailman Core 3.3.1 is now out. This release includes support for bounce processing, which had been lacking in Mailman 3 until now. So, after upgrading to this release, you will notice bounce related notifications from Mailman 3 being sent out to list owners if the list has bounce processing enabled (which, most list do by default). Postorius changes for new bounce processing options are coming out soon, I would like the current head to bake in a little longer since it went through bootstrap 4 upgrade recently. Expect it to be out in about a month. If your users would really care about bounce processing being enabled and not being able to tune threshold and notification parameters in the web interface, you might want to wait for Postorius's next release before upgrading. It also exposes all the remaining attributes of MailingList via REST API, so Postorius can expose them in the Web Interface. This should finally make all attributes of a MailingList manageable via Web Interface, without having to access command line interface. There has also been a whole lot of bug fixes. A full list of changes can be found at: https://mailman.readthedocs.io/en/latest/src/mailman/docs/NEWS.html#id1 The release is available via PyPI: https://pypi.org/project/mailman/3.3.1/ To install this release via pip, you can run: $ pip install --upgrade mailman -- thanks, Abhilash Raj (maxking)

5 years, 10 months

Re: Timeout error on anonymous subscribe

by Gerald Vogt

On 23.10.24 00:09, Mark Sapiro wrote: > How are you creating the template? If you are creating it via Postorius, Yes, via Postorius created using the url https://lists.example.org/mailman3/lists/community.lists.example.com/templa… > what is your setting for POSTORIUS_TEMPLATE_BASE_URL and what does the I did not set POSTORIUS_TEMPLATE_BASE_URL in settings.py. > entry in the template table in the database look like? in mailman.template: mailman=# select * from template where id = 6; 6|list:user:action:subscribe|community.lists.example.com|http://localhost:8… in mailmanweb.template: mailmanweb=# select * from postorius_emailtemplate where id = 6; 6|list:user:action:subscribe|test1234||2024-09-09 13:52:22.377792+02|2024-10-14 15:11:43.029873+02|list|community.lists.example.com > POSTORIUS_TEMPLATE_BASE_URL should be the same URL you use to access > Postorius up to but not including the `/postorius/` or `/mailman3/` > part. I.e, for this list whose info page is at https:// > lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/, the > setting is > ``` > POSTORIUS_TEMPLATE_BASE_URL = 'https://lists.mailman3.org' > ``` For testing I have set POSTORIUS_TEMPLATE_BASE_URL = 'https://lists.example.org' to the URL of our main domain, however, if I test an anonymous subscribe through the list info page I still get the timeout error ``` HTTPConnectionPool(host='localhost', port=8000): Read timed out. (read timeout=5) ``` Logs still show the same behaviour: the request for the template comes into the server but is finished and logged after 5 seconds: 127.0.0.1 - - [23/Oct/2024:05:51:38 +0000] "GET /mailman3/api/templates/list/community.lists.example.com/list:user:action:subscribe HTTP/1.1" 200 8 "-" "python-requests/2.32.3" The tcpdump of the tcp conection also looks the same: the response is pushed with the termination of the connection. I can access http://localhost:8000/mailman3/api/templates/list/community.lists.example.c… with curl and immediately get the response. So it still looks to me as if the response is stuck in the tcp buffers of the connection and not pushed immediately, but only once the requestor times out after 5 seconds and closes the connection. Thanks, Gerald

1 year, 4 months

problem with postorius initial setup

by John Covici

Hi. I am trying to setup postorius, but I have run into a problem. I am using the example project, except I am using postgresql instead of sqlite3. I ran python manage.py migrate which was successful. On running the development server I get: Exception in thread django-main-thread: Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/django/utils/module_loading.py", line 20, in import_string return getattr(module, class_name) AttributeError: module 'postorius.middleware' has no attribute 'APICountingMiddleware' The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/django/core/servers/basehttp.py", line 45, in get_internal_wsgi_application return import_string(app_path) File "/usr/lib/python3.8/site-packages/django/utils/module_loading.py", line 17, in import_string module = import_module(module_path) File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1014, in _gcd_import File "<frozen importlib._bootstrap>", line 991, in _find_and_load File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 671, in _load_unlocked File "<frozen importlib._bootstrap_external>", line 783, in exec_module File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed File "/home/covici/mailman_django/example_project/wsgi.py", line 17, in <module> application = get_wsgi_application() File "/usr/lib/python3.8/site-packages/django/core/wsgi.py", line 13, in get_wsgi_application return WSGIHandler() File "/usr/lib/python3.8/site-packages/django/core/handlers/wsgi.py", line 127, in __init__ self.load_middleware() File "/usr/lib/python3.8/site-packages/django/core/handlers/base.py", line 40, in load_middleware middleware = import_string(middleware_path) File "/usr/lib/python3.8/site-packages/django/utils/module_loading.py", line 22, in import_string raise ImportError('Module "%s" does not define a "%s" attribute/class' % ( ImportError: Module "postorius.middleware" does not define a "APICountingMiddleware" attribute/class The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner self.run() File "/usr/lib/python3.8/threading.py", line 870, in run self._target(*self._args, **self._kwargs) File "/usr/lib/python3.8/site-packages/django/utils/autoreload.py", line 53, in wrapper fn(*args, **kwargs) File "/usr/lib/python3.8/site-packages/django/core/management/commands/runserver.py", line 138, in inner_run handler = self.get_handler(*args, **options) File "/usr/lib/python3.8/site-packages/django/contrib/staticfiles/management/commands/runserver.py", line 27, in get_handler handler = super().get_handler(*args, **options) File "/usr/lib/python3.8/site-packages/django/core/management/commands/runserver.py", line 65, in get_handler return get_internal_wsgi_application() File "/usr/lib/python3.8/site-packages/django/core/servers/basehttp.py", line 47, in get_internal_wsgi_application raise ImproperlyConfigured( django.core.exceptions.ImproperlyConfigured: WSGI application 'wsgi.application' could not be loaded; Error importing module. Thanks in advance for any suggestions. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una covici(a)ccs.covici.com

5 years

Re: Default values for lists in Mailman 3

by Mark Sapiro

On 9/19/24 05:46, Markus Grandpré wrote: > Dear list, > > I would like to activate the invitation setting for all lists as > default. In Mailman 2.1 I have done this in the file > </etc/mailman/mm_cfg.py>: > > > DEFAULT_SUBSCRIBE_OR_INVITE = Yes > > > How can I do this in Mailman 3? There is a draft merge request at https://gitlab.com/mailman/postorius/-/merge_requests/930 which implements a framework for setting Postorius defaults and creates a setting to set the default for pre-verified on the mass subscription page. Once merged, this can easily be extended to provide a default for Invitation. In the mean time, you can only do this by patching src/postorius/forms/list_forms.py like ``` --- a/src/postorius/forms/list_forms.py +++ b/src/postorius/forms/list_forms.py @@ -1283,7 +1283,7 @@ class ListMassSubscription(forms.Form): invitation = forms.BooleanField( label=_('Invitation'), - initial=False, + initial=True, required=False, help_text=_( 'If checked, the other checkboxes are ignored and the users will ' ``` > Can I also transfer other default values > like: > > ... > DEFAULT_SERVER_LANGUAGE = 'en' > DEFAULT_SEND_REMINDERS = 1 > DEFAULT_SUBSCRIBE_OR_INVITE = Yes > DEFAULT_PRIVATE_ROSTER = 2 > DEFAULT_ARCHIVE = Off > DEFAULT_ARCHIVE_PRIVATE = 1 > ... > > from the very same configuration file to Mailman 3? Is there a > documentation of the default values for lists in Mailman 3? This is done by creating a list style with the desired defaults. See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/styles/doc… for documentation of styles and see https://gitlab.com/mailman/example-mailman-plugin for an example of creating a plugin in Mailman core to make a persistent style. There is no specific doc for the list settings. You need to look at https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/styles/base.py for the various settings and https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/styles/default… to see which default classes are applied for various styles. -- 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

Re: Set Postorius interface locale

by Duane Raymond

Thanks - here is where that got ne so far... I have set the modest goal of changing a string on the list subscription page from the form label "Your name (optional)" to "Your name (and organisation)" What I did was 1) I edited /opt/mailman/mm/settings.py and changed the LANGUAGE_CODE from 'en-us' to 'en-gb' (or should I do it at /opt/mailman/mm/venv/lib/python3.7/site-packages/falcon/bench/dj/dj/settings.py or another location?) 2) Then I switched user using "su mailman" and started the venv environment (using: source /opt/mailman/mm/venv/bin/activate) 3) I edit the po file at /opt/mailman/mm/venv/lib/python3.7/site-packages/postorius/locale/ and specifically I am testing it on editing en_GB/LC_MESSAGES/django.po - is this the correct location? 4) I run: mm/venv/lib/python3.7/site-packages/falcon/bench/dj/manage.py compilemessages - is this the correct one to run? After this, nothing changed on the list page yet. 5) After that I changed directory into "/opt/mailman/mm/static" and run python ./mm/venv/lib/python3.7/site-packages/falcon/bench/dj/manage.py collectstatic - but this produces an error about ROOT_STATIC not being set ...and I didn't want to fiddle too much in case I overwrote the current functioning site ;-) Is the collectstatic static necessary after running compilemessages? Am I using the right files to run it? Am I editing them in the right location? Cheers, Duane

5 years

Question after upgrade to mm 3.2.3 and latest postorius

by Stephen J. Turnbull

David Krantz writes: > I have just upgraded to mailman 3.2.3. My installation is from the git > sources and I use two different venv:s, one for the web part as I did > not want to compile the web server plugin to a newer python version > than 3.5, I see elsewhere that this is mod_wsgi. I forget exactly what my story was, but I did recompile on Linux and it was straightforward. Of course there are a million reasons why you might not want to do that. I just wanted to take this chance to report that for 3.6 and 3.7 this was very straightforward, in case anybody else is thinking about doing it.

6 years, 7 months

Mailman, etc. upgrade woes and persistent bugs

by Stephen J. Turnbull

hansen(a)rc.org writes: > I just had my Mailman suite upgraded. When it got started, I > starting receiving messages that hundreds of subscribers to the > lists had been disables, including several of the list > moderators. I'm sorry to hear about this. > This version started supporting bounce processing, but > how in the world was this upgrade allowed to act on bounces that > were being collected PRIOR to enabling bounce processing?? Well, if bounce processing were occurring as designed, there would be very few bounces in the queue. So it's a difficult thing to anticipate until it happens. And curiously I haven't heard of this before. I mean, if it were going to happen, I would expect that it would have happened at the very busy lists at python.org. So maybe you have an unusually large number of bounces? Not saying it couldn't have been anticipated that *somebody* would have that situation, but we'd have to be extremely lucky, or have a dedicated "red team" looking for ways the feature can break, to find it before installing it. I'm sorry it happened, but AFAICS it's "one of those things". Technically, it appears that the model for bounce information is initialized based on the time of processing, rather than the (alleged) time of injection or the (presumably trustworthy) time of receipt by the local MTA. I don't have time to check further on if that's modified later, but "not modified" explains what you saw very well. I guess you must have had many hundreds of bounce messages in the queue. Probably the simplest way to deal with this is to clear the bounce queue while upgrading, or at least offer the option. Losing a few hours' worth of bounce messages (if they're being processed normally) isn't going to hurt anything. It would also be simple to provide a report of who bounced and the most recent bounce, if desired. > I then looked at several of the disabled accounts, but the > subscription info page in Postorius had no information about > whether an account was enabled or disabled. Why is this not > displayed???. It is for me when I've authenticated, both for lists where I'm owner and for lists where I'm just a subscriber. (However, the lists where I'm subscriber are on python.org where Mark is the site admin, and may be a little ahead of released versions.) > The members can't see if their account is enabled. I guess they are email-only members, and have not authenticated to Postorius? I don't think we will allow unauthenticated access to user info in Postorius in a distributed version. If you really need it, the fastest route would be to find a contractor to customize Mailman for that -- custom versions are not a priority for us. > Is this another example of the disconnect between Mailman and > Postorius? Hard to say. If it's not the users' failure to authenticate, I would guess this is most likely due to a skew in the upgrade process where the versions of Mailman core and Postorius were mismatched, but as I wrote above, I can see this in the user's setting page for both my "owned" lists and for my "just a subscriber lists". It would be inconvenient in your situation because list admins have to visit the user's options page to see and modify it, but I *can* see it. > Further, even after the upgrade, the moderators still cannot access > the list memberships even though all the lists are set to allow > that. This is a known bug being worked on. I'm sorry it was not fixed in time for your upgrade. > As a result of these bugs, after consulting with Brian, who helped > with the upgrade, I spent many hours re-enabling the several > hundred accounts that had been disabled. I had to go through each > email notification to find the address of a disabled account, then > find the list, then the member, in Postorius, and finally enable > the account (at which time Postorius DID show the enabled status). I'm quite sure that this situation could have been addressed quickly and efficiently with a Python script, or in an interactive session with mailmanclient. That doesn't help you now, but in the future feel free to ask us to help with that. We generally are able to respond within a few hours. It's probably not as fast as doing it by hand, but there's the consideration of your time spent. Or if there are Python programmers hanging around, a little fiddling with the mailmanclient command line will probably allow them to figure out what's what, enough to do this. > Please, can the next upgrade include these very basic > fixes/enhancements, which I requested a long time ago: > a. The ability of moderators to see the list membership (a bug). It's in the queue. I can't say when it will be released. > b. The ability of members to change their addresses for all lists > they are subscribed to. What exactly do you want here? I can think of a number of ways to implement that, depending on whether the old address is to be deactivated from the lists, unsubscribed from the lists, or deleted from the Mailman and/or Postorius Users. There may be other variables to consider, as well; I haven't thought about this. AFAICS this is not a trivial feature, and I'd really like to hear from people who want "something like" this about exactly what they want and their use cases. Or we'll release an insufficiently designed feature that causes somebody hundreds of problems.... > c. That when members go to look at their subscription info, they > can actually see the settings. As far as I know, they already can if they have authenticated. If that's not true in your installation(s), we'll need to find out why, because it works for me. Enabling access without authentication is a potentially dangerous change that I currently believe shouldn't happen at all in a Mailman distribution, and will certainly take time to design. If your requirements include unauthenticated access, I would not hold my breath, let alone expect it in the near future. Regards, Steve

5 years, 1 month

Re: list footer questions

by Mark Sapiro

On 5/8/20 12:52 PM, Mohsen Masoudfar wrote: > Hi, > > This seems to me like basic simple questions, I have tried FAQ and other resources, with not much success. > > I have two questions: > > 1. When I send an email to a list, in gmail and yahoo I see the following text with the links at the end of the email body: > _______________________________________________ > Testlist_dmark1 mailing list - listname(a)domain.tlb<mailto:testlist_dmark1@newlistserv.aaas.org> > To unsubscribe send an email to listname-leave(a)domain.tlb > > In<mailto:listname-leave@domain.tlb%0b%0bIn> outlook this is added as an attachment in the form of a TEXT file, when you open it, you see the same text. > Question: Is there a way to change this, that it looks in outlook the same way as it appears in gmail/yahoo? There are a few things going on here. First, the actual footer is _______________________________________________ Testlist_dmark1 mailing list - listname(a)domain.tlb To unsubscribe send an email to listname-leave(a)domain.tlb The <mailto:...> links are added by the Mail client displaying the mail. > In outlook this is added as an attachment in the form of a TEXT file, when you open it, you see the same text. > Question: Is there a way to change this, that it looks in outlook the same way as it appears in gmail/yahoo? > > I know MS does it own stuff sometime and we have no impact on that, but I was thinking maybe we might change the footer in a way that outlooks sees that as part of email body. Yes, this is an outlook thing, but you do have some control. See the FAQ article at <https://wiki.list.org/x/4030707> for a more detailed explanation, but the issue is that after any content filtering has been applied, the message is still multipart so Mailman adds the footer as a separate MIME text/plain part at the end of the message. You can avoid this by doing heavy content filtering on the messages. Namely, accept only multipart, text/plain and text/html, collapse alternatives and convert html to plain text. Note that some of this involves updating the list's pass_types which is not exposed in Postorius before 1.3.3 which is not yet released. > 2. How may I change the format and the text in footer? > I was expecting it under list > setting, in postorius, but I could not find it. It's the top level Templates tab in Postorius (just left of Settings). It was added in Postorius 1.2.1. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 10 months

Re: I did something stupid. Can i back out of it?

by Mark Sapiro

On 2/19/22 14:06, William Oliver wrote: > > So.. as an aside, it was a bit of a hassle to copy and paste all the > usernames from the "Users" list in Postorius to the "Mass subscribe." > The only way I could see to do it was copy and paste them one at a > time. Postorius Users -> Members view has a CSV Export button. That exports a CSV with all the member addresses. It's actually just a flat list as it only has one column. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years

Mailman-users search results for query "Postorius"