Search results for "Postorius" - Mailman-users

can templates be html formatted?

by Stephen J. Turnbull

John Harrison via Mailman-users writes: > My goal here is to have as little friction as possible for > nontechies to join and participate in an email discussion list. So > that means > > - HTML Supporting HTML templates would be a lot of work, not only to design and implement, but it would also induce ongoing support requests. We have long resisted doing it for those reasons. > formatted hyperlinks in all emails including the welcome email > to subscribe, unsubscribe, see the archives, etc. Don't most modern email clients format email addresses as mailto: links and other URLs as links? I think for many of your members this is a cosmetic issue, not a "nothing to click" issue. The big problem with all those links is that the major clients have decided in their infinite wisdom that supporting RFC 2369 is not worth it. RFC 2369 provides for URLs to do all those functions, leaving it up to the client to format them nicely as buttons and menu items. This would be better because users would know where to look for them since they'd be formatted and located consistently (in each client, different clients would likely do things differently). > - no need for a password ever for anything they'd want to do. There is a plethora of "social authentication" (ie, use your Facebook, Google, Fedora, etc account to authenticate) available in Django. IIRC most of the more popular ones (eg, the ones just mentioned) are configured by default in the Mailman web applications. If not, that's easy to do. If you have a single-sign-on system for your website, it's simple to have the webserver pass those credentials to Postorius and HyperKitty. > - A simple click to subscribe, unsubscribe, see the archives. All > hyperlinks. One-click operations are frequently used to harrass people. There is a proposal for a standard way to support them more safely but it doesn't address the harassment problem completely. It's most attractive for marketing mailing lists. > I've been playing with the welcome template and it seems maybe this > can't do what I am looking for (html formatting). As with plain text, some clients will detect those and format HTML elements even though the mail is declared plain text. But this is really risky, and has become less and less common over the past few years. It would be possible to hack the sources to tell clients that the email is HTML, and then this would work. But I'm not interested in doing that, and definitely I'm not willing to support users of such a feature. > I'm wondering also why it's doing some sort of soft wrap with line > breaks which is breaking longer urls in the template. That's not Mailman, that's your client, I'm willing to bet. See the "Archived at:" URL from your post on Mailman Users copied below. There's a line break after "at:", but none in the URL which is 109 characters long. Also compare the URLs in the footer of the mail you'll receive through the list. If you see line breaks in any of these URLs, that's not Mailman. Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

3 weeks, 5 days

Re: Can "Pre Verified" set to yes by default?

by Mark Sapiro

On 12/19/22 00:21, Stephen J. Turnbull wrote: > > I don't know if there's a way to do this in settings.py, but I > suspect not. Maybe Mark knows a way. Well, I haven't tried this and I don't recommend it, but while the intent of settings.py is to assign values to various known attributes, it is a Python module which is imported and could contain any valid Python code including code to read, modify and rewrite .../site-packages/postorius/forms/list_forms.py. However, my recommendation is to maintain your local patches in a script that you can run following an update to apply them. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years

Re: Database deadlock when trying to delete a member.

by Abhilash Raj

Hi Simon, > On Mar 17, 2021, at 10:16 PM, Simon Coggins <s.coggins(a)cqu.edu.au> wrote: > > Hi, > > I’ve got a strange error. I migrated from mailman 2.1 to 3 using the migration guide on the website and things have been working fine. But I’m in the process of testing the new syncmembers command to replace some inhouse mailman API code we wrote. I’ve tracked my problem down to what appears to be a deadlock in the postgresql database. When trying to delete certain users the SQL query hangs and never returns. > > After doing some tracing and tracking it down to the database, I enabled DB logging of all queries and saw that the following query was never returning: > > DELETE FROM member WHERE member.id = 166814 > > If I try to run it manually I get the same issue, in psql it never returns. > mailman=# explain analyze DELETE FROM member WHERE member.id = 166814; > [… 60 seconds passes…] > ^CCancel request sent > ERROR: canceling statement due to user request > CONTEXT: while deleting tuple (2998,72) in relation "member" > I’m just wondering if there are any commands or scripts I can run to verify the database and it’s constraints to see if there is some error in the database data? Or where you’d recommend I go from here? It only impacts the user on this specific list. If I add this user to another list and remove them, everything works fine. Are you able to retrieve that Member object using API? This[1] the Python code which would try to delete a Member object and I am assuming is being called from syncmembers command. I am not entire sure about what would cause the database to hang, if there was some database constraint that failed, I would imagine some error to be returned. [1]: https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/model/member.p… One thing you can try is see if you can unsubscribe the user using the API or `mailman shell` command. You can unsubscribe from API by calling a `DELETE` method at http://localhost:9001/3.1/members/<member_id> This would give us some indication about whether there is some bug in the implementation of syncmembers command or if there is something else going on. > > This is on a test system so I can do various testing. I’m trying to find the root cause so that I can verify my production system isn’t impacted by the same thing. > > > Setup Details: > OS: Oracle Linux 7 (Redhat) > Installed using pip via virtualenv talking to a local pgsql database on the same box. > Data was migrated from a mailman 2.1 install into mailman3 using migration instructions on the website. > > PIP Modules versions: > django-mailman3 1.3.5 > mailman 3.3.3 > mailman-hyperkitty 1.1.0 > mailmanclient 3.3.2 > postorius 1.3.4 > psycopg2-binary 2.8.5 What is the version of sqlalchemy package? There is a new 1.4.0 version that came out recently and is incompatible with Core right now. There are backwards incompatible changes which might need some changes in Core to add support. > > RPM packages: > postgresql12-12.6-1PGDG.rhel7.x86_64 > postgresql12-server-12.6-1PGDG.rhel7.x86_64 > postgresql12-libs-12.6-1PGDG.rhel7.x86_64 > postgresql12-devel-12.6-1PGDG.rhel7.x86_64 > > > -Simon > > > _______________________________________________ > 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)

4 years, 9 months

Fwd: [Django] ERROR (EXTERNAL IP): Internal Server Error: /archives/search

by Johannes Rohr

Hello everyone! below is a "permission denied" error I get when trying to perform a fulltext search. -------- Weitergeleitete Nachricht -------- Betreff: [Django] ERROR (EXTERNAL IP): Internal Server Error: /archives/search Datum: Mon, 23 Jan 2023 10:30:14 -0000 Von: johannes(a)rohr.org An: johannes(a)rohr.org Internal Server Error: /archives/search PermissionError at /archives/search [Errno 13] Permission denied: 'fulltext_index' Request Method: GET Request URL: http://lists.*****.org/archives/search?mlist=pinnwand%40lists.*****&q=medit… Django Version: 4.1.5 Python Executable: /opt/mailman/venv/bin/uwsgi Python Version: 3.10.6 Python Path: ['.', '', '/etc/mailman3', '/usr/lib/python310.zip', '/usr/lib/python3.10', '/usr/lib/python3.10/lib-dynload', '/opt/mailman/venv/lib/python3.10/site-packages'] Server time: Mon, 23 Jan 2023 11:30:14 +0100 Installed Applications: ['hyperkitty', 'postorius', 'django_mailman3', 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.messages', 'django.contrib.staticfiles', 'rest_framework', 'django_gravatar', 'compressor', 'haystack', 'django_extensions', 'django_q', 'allauth', 'allauth.account', 'allauth.socialaccount'] Installed Middleware: ('django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.middleware.locale.LocaleMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'django.middleware.security.SecurityMiddleware', 'django_mailman3.middleware.TimezoneMiddleware', 'postorius.middleware.PostoriusMiddleware') Traceback (most recent call last): File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/exception.py", line 55, in inner response = get_response(request) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/base.py", line 197, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/views/search.py", line 88, in search emails = paginate( File "/opt/mailman/venv/lib/python3.10/site-packages/django_mailman3/lib/paginator.py", line 71, in paginate objects = paginator.page(page_num) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/paginator.py", line 75, in page number = self.validate_number(number) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/paginator.py", line 53, in validate_number if number > self.num_pages: File "/opt/mailman/venv/lib/python3.10/site-packages/django/utils/functional.py", line 57, in __get__ res = instance.__dict__[self.name] = self.func(instance) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/paginator.py", line 102, in num_pages if self.count == 0 and not self.allow_empty_first_page: File "/opt/mailman/venv/lib/python3.10/site-packages/django/utils/functional.py", line 57, in __get__ res = instance.__dict__[self.name] = self.func(instance) File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/paginator.py", line 96, in count return c() File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/query.py", line 527, in count return len(self) File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/query.py", line 82, in __len__ self._result_count = self.query.get_count() File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/__init__.py", line 658, in get_count self.run() File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/__init__.py", line 593, in run results = self.backend.search(final_query, **search_kwargs) File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/__init__.py", line 32, in wrapper return func(obj, query_string, *args, **kwargs) File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/whoosh_backend.py", line 412, in search self.setup() File "/opt/mailman/venv/lib/python3.10/site-packages/haystack/backends/whoosh_backend.py", line 133, in setup os.makedirs(self.path) File "/usr/lib/python3.10/os.py", line 225, in makedirs mkdir(name, mode) Exception Type: PermissionError at /archives/search Exception Value: [Errno 13] Permission denied: 'fulltext_index' Raised during: hyperkitty.views.search.search I don't understand what the cause for the "permission denied" could be. The directory "fulltext_index" is owned by mailman:mailman Does anyone have a hint? I did some googling for the error, but to no avail, unfortunately. Thanks! Johannes

2 years, 10 months

Re: Add an extra option for "Delivery status" for users?

by Mark Sapiro

On 11/19/25 12:50 PM, Thomas Ward via Mailman-users wrote: > > We have a unique case where we have a user we want to disable for mail > receiving, etc. for the reason "Disabled by IT Security Team" but I > don't even know if it's possible to add a delivery status that is that > custom. At a minimum, you would need to add that choice to the DeliveryStatus(Enum) in mailman/interfaces/member.py and the choice and its description to the DELIVERY_STATUS_CHOICES tuples in postorius/forms/fields.py. I don't know offhand if that would be sufficient, or if more would be required. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 month

Re: spanish localization

by Guillermo Hernandez (Oldno7)

On 13/2/21 9:04, Stephen J. Turnbull wrote: > Victoriano Giralt writes: > > > Thanks Stephen for reminding me that sometimes I write what looks like > > proper English on the surface, but the meaning of it comes from the > > deep corners of my mind in some long forgotten dialect :-) > > Your English is fine, it was just my lack of imagination: on February > 12, I couldn't conceive of February 3 being even a little "old"! But... here is a thing that I can not understand: If the source (the .po file) is from november 7th, it doesn't matter how many times you recompile it: the result will be the same. I did what Mark recommended. Before that: /usr/local/lib/python3.7/site-packages/mailman/messages/es/LC_MESSAGES # ls -la total 192 drwxr-xr-x 2 root wheel 512 Feb 8 12:00 . drwxr-xr-x 3 root wheel 512 Feb 8 12:00 .. -rw-r--r-- 1 root wheel 80700 Feb 3 02:47 mailman.mo -rw-r--r-- 1 root wheel 102963 Nov 7 01:50 mailman.po Then... /usr/local/lib/python3.7/site-packages/mailman/messages/es/LC_MESSAGES # msgfmt -o mailman.mo mailman.po And that is: the same .mo file just with different date /usr/local/lib/python3.7/site-packages/mailman/messages/es/LC_MESSAGES # ls -la total 192 drwxr-xr-x 2 root wheel 512 Feb 13 11:09 . drwxr-xr-x 3 root wheel 512 Feb 13 11:09 .. -rw-r--r-- 1 root wheel 80700 Feb 13 11:09 mailman.mo -rw-r--r-- 1 root wheel 102963 Nov 7 01:50 mailman.po I'm not trying to diminish the effort and the excelent work that are indeed making all of you. I appreciate that so much. But is evident to me that something fails in the translation path chain of upgrades. If you access the postorius web to manage subscriptions you can see a full mixed language words. It's not a life or death item... but it has not to be that way as the terms, as far as I know, are 100% translated (at least in spanish). And the subscriptors complain. If that is not a thing that the release manager can do, well... We are stucked, isn't it? I don think it has to be a matter of "automate production of pip'able packages containing only new translations": a new version has just released and the localization languages, at least spanish, were not merged into it for the last Weblate updates. I will wait untill the next update, this thread is closed to me. Thanks, again, for all your good work. > > More important, as long as the .mo file is more recent than the .po > file, that's the best the release manager can do. I haven't been > involved in the release process, so I can't swear to it personally, > but if Mark says that new translations generate a merge request > automatically, and we make sure that the translations are merged > before release, I believe him. That's optimal as far I am concerned. > > Perhaps some enterprising soul would be willing to automate production > of pip'able packages containing only new translations, but without > that, I don't see how to beat our current procedures. (I wouldn't > want to use such a thing, though, I'd be too afraid that one day all > the translations would be replaced with Dril tweets!) > _______________________________________________ > 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/ >

4 years, 10 months

Re: Confirm on mass subscription

by Mark Sapiro

On 7/5/17 1:48 PM, David Krantz wrote: > > Is there a way of requiring all mass subscribed users to confirm their > email adress? I have an use case where we have a current mail list but > when moving it to mailman I for different reasons would like to > confirm all subscribers. Some very shallow testing suggests that if I > just add them using mass subscribe, they will not have to confirm at > all. > > I have yet to upgrade to 3.1 but I will do so in due time. In MM 2.1, you just send the users invitations rather than subscribing them. In MM3/Postorius, this does not seem to be an option at present. -- 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: Turn off social logins?

by Torge Riedel

Am 12.02.19 um 17:11 schrieb Stephen J. Turnbull: > Note: I've changed the order of sentences from Torge's post to fit my > responses. > > Torge Riedel writes: > > > I do agree, same here on my side. Lot's of my users are very > > "sensitive" to social media and don't want see them here. > > This is the first I've heard of this. Obviously it's fairly > widespread; *please* speak up if anyone have similar issues that we > haven't addressed. AFAIK all of the currently active Mailman > developers believe that social auth is a GoodThang[tm], so we're > unlikely to DTRT as you see it without your help. Well most of my users are 60+ so social media is some kind of a thing from hell for them ;-) I don't want to blame it, but to ensure acceptance in my scenario it is required to hide them somehow. > > > I need to migrate from mailman2 to mailman3 and was wondering why > > social accounts are enabled by default > > By default Mailman 3 is social media: you have a profile, you can be > searched in the indicies of the archives, and so on. The large auth > providers provide more secure authentication, and a lot of convenience > for users who have such accounts already. They also take some > administrative burden off the list and site managers when people lose > their passwords and forget what their subscription address is, and > similar scenarios. Clearly, these are not universally-valued > features, but I think that they justify the current defaults. Yes, this was a bit unprecise. For my feeling it is better to enable one after another, but it is ok for me to do it the other way. > > > and are difficult to disable. > > They're easy enough to disable (easy to recognize and just add a hash > character in front), since you have to edit settings_local.py to > install anyway. If you're using a packaged version and the package > configuration utility doesn't handle it, there's nothing we can do > about it. The distro will have to deal with that. > > It should be better documented, I imagine (haven't checked yet). > > > I propose something like an additional setting listing the enabled > > social accounts. > > Do you mean in the Postorius administration interface? If so, do you > want it by-site, by-domain, or by-list? ("You" is everybody who wants > to disable social auth, not just Torge!) > > If you mean in settings_local.py, I suggested something similar > earlier. It's not obvious it would be easy to do (sometimes these > things are order-dependent, though that's bad practice). Having the configuration in the UI would be the best solution. So not everything needs to be done by me. A first approach is the mentioned setting, which can be set to an empty value to overwrite the default. Without the risk to break something else. Just to repeat. > > > And if the admin is setting this to an empty value in the > > settings_local.py everything is disabled > > Because the settings are a Python module, this is the way > settings_local.py works anyway. That's why Mark suggested editing > INSTALLED_APPS. > > Thanks so far for going into the discussion.

6 years, 10 months

Problems after Upgrade

by Jeff

Hello, I tried to upgrade to the latest mailman3 version using the following command: pip install -U mailman postorius django-mailman3 hyperkitty mailman-web mailmanclient There didn’t appear to be any problems with this step and I’ve since run it again a few times and only see that the requirements have been satisfied. When first running the command: mailman-web migrate I received several errors dealing with search_text in the package compressor (at least that’s as best as I remember, I wasn’t taking notes). I fixed these manually by changing it to search_str. Eventually "mailman-web migrate” started working and has subsequently worked. When I run the command: mailman-web compress I get the following error: traceback (most recent call last): File "bin/mailman-web", line 8, in <module> sys.exit(main()) File "/usr/local/mailman3/lib64/python3.8/site-packages/mailman_web/manage.py", line 37, in main execute_from_command_line(sys.argv) File "/usr/local/mailman3/lib64/python3.8/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line utility.execute() File "/usr/local/mailman3/lib64/python3.8/site-packages/django/core/management/__init__.py", line 440, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/usr/local/mailman3/lib64/python3.8/site-packages/django/core/management/__init__.py", line 279, in fetch_command klass = load_command_class(app_name, subcommand) File "/usr/local/mailman3/lib64/python3.8/site-packages/django/core/management/__init__.py", line 49, in load_command_class return module.Command() File "/usr/local/mailman3/lib64/python3.8/site-packages/django/core/management/base.py", line 274, in __init__ raise TypeError("requires_system_checks must be a list or tuple.") TypeError: requires_system_checks must be a list or tuple. I have not been able to fix this and would appreciate any assistance. When I run the command: bin/mailman-web collectstatic It asks me yes or no continue and when I enter “yes” it displays the following which I assume means it worked: 372 static files copied to '/usr/local/mailman3/web/static', 38 unmodified Starting mailman3 seems to work by the status message shows the following: systemctl status -l mailman3 ... Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: return function(args[0], config.db.store, *args[1:], **kws) Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: File "/usr/local/mailman3/lib64/python3.8/site-packages/mailman/model/bounce.py", line 259, in send_warnings_and_remove Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: self._send_warnings() Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: File "/usr/local/mailman3/lib64/python3.8/site-packages/mailman/database/transaction.py", line 85, in wrapper Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: return function(args[0], config.db.store, *args[1:], **kws) Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: File "/usr/local/mailman3/lib64/python3.8/site-packages/mailman/model/bounce.py", line 310, in _send_warnings Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: member.address, Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: File "/usr/local/mailman3/lib64/python3.8/site-packages/mailman/model/member.py", line 121, in address Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: return (self._user.preferred_address Oct 30 14:51:03 mailhost.steele.com mailman[3521451]: AttributeError: 'NoneType' object has no attribute 'preferred_address' lines 13-35/35 (END) I have been receiving admin requests to approve messages. But, I can’t approve them because of the following issue: Starting mailman-web seems to work as expected with no errors. However, when I try to login to the web interface, I get a HTML page with the following error: init__() got an unexpected keyword argument 'providing_args' Request Method: GET Request URL: http://lists.crestwood-dc.org/accounts/login/?next=/mailman3/lists/crestwoo… Django Version: 4.1.2 Exception Type: TypeError Exception Value: __init__() got an unexpected keyword argument 'providing_args' Exception Location: /usr/local/mailman3/lib64/python3.8/site-packages/compressor/signals.py, line 4, in <module> Raised during: allauth.account.views.LoginView Python Executable: /usr/local/mailman3/bin/uwsgi Python Version: 3.8.13 As a result, I cannot login and approve posts. I would greatly appreciate any assistance with these issue. Thanks much!

3 years, 1 month

Re: Exception with processing subscription confirmation email

by Mark Sapiro

On 4/29/21 7:56 AM, Eric Broens wrote: > Hi, > > A new user tried to subscribe to a mailinglist, received the confirmation > mail, and replied to it. > > The subscriber is however not subscribed and remains listed in the "pending > confirmation" list. > > The following exception appears in the error.log. > > Does anyone knows how to resolve this? In the past we didn't experience any > issues and no changes but security updates have been installed. > > Apr 29 16:15:55 2021 (1581) deque: do_confirm_verify > > Traceback (most recent call last): > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/workflow.py", > line 69, in __next__ > > return step() > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/subscriptions.p > y", line 356, in _step_send_confirmation > > raise StopIteration > > StopIteration Tracebacks like the above are normal and probably shouldn't be logged at all. > Apr 29 16:16:28 2021 (1490) Uncaught runner exception: Expecting ':' > delimiter: line 1 column 256 (char 255) > > Apr 29 16:16:28 2021 (1490) Traceback (most recent call last): > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > line 173, in _one_iteration > > self._process_one_file(msg, msgdata) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > line 266, in _process_one_file > > keepqueued = self._dispose(mlist, msg, msgdata) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/runners/command.py" > , line 208, in _dispose > > mlist, msg, msgdata, parts, results) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/commands/eml_confir > m.py", line 54, in process > > mlist).confirm(token) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/subscriptions.p > y", line 578, in confirm > > workflow.restore() > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/workflow.py", > line 146, in restore > > data = json.loads(state.data) > > File "/usr/lib64/python3.6/json/__init__.py", line 354, in loads > > return _default_decoder.decode(s) > > File "/usr/lib64/python3.6/json/decoder.py", line 339, in decode > > obj, end = self.raw_decode(s, idx=_w(s, 0).end()) > > File "/usr/lib64/python3.6/json/decoder.py", line 355, in raw_decode > > obj, end = self.scan_once(s, idx) > > json.decoder.JSONDecodeError: Expecting ':' delimiter: line 1 column 256 > (char 255) > > Apr 29 16:16:28 2021 (1490) SHUNTING: > 1619705788.5856323+57a1a759275c59b732cfa8e2985f76cfcc27dda5 This one is the issue. There was some problem with the user's confirmation reply. View the shunted message with the command ``` mailman qfile path/to/var/queue/shunt/1619705788.5856323+57a1a759275c59b732cfa8e2985f76cfcc27dda5.pck ``` although that probably won't show anything wrong as it appears that the issue is with the saved workflow. You can get the token from the shunted message and then look at the database with something like ``` SELECT data FROM workflowstate WHERE token = '<the token>' ``` but I suspect the issue is because the database is MySQL or MariaDB, your Mailman core is older than 3.3.3 and your database server mode is such that data too long for column results in truncation, and the data in this case is truncated to 255 bytes. In Mailman 3.3.3, this column was changed from VARCHAR(255) to VARCHAR(510) for MySQL. As far as subscribing the user is concerned, you can in Postorius view the subscriptions waiting user confirmation and delete this one and then `mass subscribe` the user. -- 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

Mailman-users search results for query "Postorius"