Search results for "Postorius" - Mailman-users

Re: Archiver "prototype" and disabling archiving at all

by Torge Riedel

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

6 years, 6 months

Re: Change the default value for the General Archive Policy

by Stephen J. Turnbull

Markus Grandpré writes: > many thanks for your reply. When I create a mailing list without an > archive, You cannot do that in Postorius. All of the "style" options provide for an archive. "Ordinary discussion" and "announce" have public archives, and the last option is "discussion with private archives". How are you doing this? > "Settings > Archiving > Archive policy" is always set to "Public > archives". I was wondering if it's possible to change the default > to "Do not archive this list" instead. The choices for setting are defined at line 386 (or so) of postorius/forms/list_forms.py: archive_policy_choices = ( ('public', _('Public archives')), ('private', _('Private archives')), ('never', _('Do not archive this list')), ) This is implemented as a line of radio buttons. There is no default for a *new* list, it's implied by the style choice. For an existing list you are shown the current setting -- there's no default to change to, you have to click on a button. If by "default" you mean "first in the list", you can patch the form in Postorius, but we're not going to change the order, since our primary audience is public discussion lists. In theory we could provide a mechanism to configure the order, but I think that's very unlikely to happen -- Mailman isn't and doesn't want to be Emacs. -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

3 months, 3 weeks

Re: mailing list aliases

by Abhilash Raj

On Fri, 2018-01-19 at 16:30 -0800, Mark Sapiro wrote: > On 01/19/2018 03:09 PM, Dmitry Makovey wrote: > > Not sure whether to mark this "SOLVED" yet - but when I manually updated > > postgres DB with the aliases I wanted - everything started to work as > > expected. > > > > so it does sound like a bug in mailman-core 3.3.0 . Shall I file it or > > was it already fixed in 3.3.1 (anouncement page didn't list that fix) > > > As far as I know, this is not a bug in core. It is > <https://gitlab.com/mailman/postorius/issues/58> however, this may in > fact be a bug in the REST API in which case I don't think it's fixed in > API 3.3.1 I guess we are all talking about the same thing, but just to mention, 3.1.1 is the latest release (instead of 3.3.1). > > > > 2. Related to #1 - we've migrated our mailing lists from foo(a)my.com to > > > foo(a)lists.my.com however we've preserved old addresses. But in new setup > > > mail sent in gets stopped for moderation with: "X-Mailman-Rule-Hits: > > > implicit-dest" . What's the best course of action here to get mailing > > > list respond to multiple email addresses? > > > acceptable_aliases is the way to address this, but as you note, it can't > be properly set via Postorius and possibly via REST. > > _______________________________________________ > Mailman-users mailing list > mailman-users(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ -- thanks, Abhilash Raj

7 years, 9 months

Re: moving list from mm3 -> mm3

by Mark Sapiro

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

1 year, 10 months

Re: Deactivate list without deleting it?

by Colin Watson

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

7 years, 9 months

Re: Another interesting error...

by Mark Sapiro

On 04/23/2018 01:31 PM, Darren Smith wrote: > So it appears that there was a message sent to one of our mailing lists > that was put into the held message queue. However, when attempting to go to > the message to do the moderation, the web page returns and Error 500. > > Looking in the mailman log, I found this: > > Apr 23 14:21:02 2018 (17878) REST request handler error: > Traceback (most recent call last): > File "/opt/mailman3/conda/lib/python3.6/wsgiref/handlers.py", line 137, > in run > self.result = application(self.environ, self.start_response) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/database/transac > tion.py", line 50, in wrapper > rtn = function(*args, **kws) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/wsgiapp.py" > , line 214, in __call__ > return super().__call__(environ, start_response) > File "/opt/mailman3/conda/lib/python3.6/site-packages/falcon/api.py", > line 227 , in __call__ > responder(req, resp, **params) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/post_modera > tion.py", line 167, in on_get > resource = self._make_collection(request) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/helpers.py" > , line 159, in _make_collection > for resource in collection] > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/helpers.py" > , line 159, in <listcomp> > for resource in collection] > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/post_modera > tion.py", line 157, in _resource_as_dict > resource = self._make_resource(request.id) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/post_modera > tion.py", line 100, in _make_resource > make_header(decode_header(resource['subject']))) > File "/opt/mailman3/conda/lib/python3.6/email/header.py", line 174, in > make_he ader > h.append(s, charset) > File "/opt/mailman3/conda/lib/python3.6/email/header.py", line 295, in > append > s = s.decode(input_charset, errors) > UnicodeDecodeError: 'gb2312' codec can't decode byte 0x87 in position 2: > illegal multibyte sequence > > It LOOKS as if there might be a character in the email somewhere - possibly > in the subject or sender fields? - that is somehow unexpected. It appears that the Subject: header is RFC 2047 encoded and there is an encoded word with charset gb2312 that contains an invalid encoding. The message is apparently defective, but this kind of defect shouldn't cause a 500 error. I can't tell for sure from the traceback if this is Postorius or some other application accessing the REST api. Is it Postorius or something else? > I am attempting to find the held message - can someone point me where I can > go to see the message so that I can see what might be causing the problem? It's in Mailman's database in the 'message' table. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 5 months

Re: Protocol version

by David Krantz

Hi, I decided to investigate this a bit more... I find the following in mailman.log (I have removed the dates and my domain names but otherwise it is unchanged. I find it strange that postorius calls the 3.0 api version to get versions and otherwise uses the 3.1 version. This probably is the explanation for it displaying API version 3.0 when it actually uses 3.1. GET /3.1/domains HTTP/1.1" 200 1658 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains/example.com HTTP/1.1" 200 216 "-" "GNU Mailman REST client v3.3.0" POST /3.0/lists/find HTTP/1.1" 200 19177 "-" "GNU Mailman REST client v3.3.0" GET /3.0/system/versions HTTP/1.1" 200 286 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains HTTP/1.1" 200 1658 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains/lists.example.com HTTP/1.1" 200 230 "-" "GNU Mailman REST client v3.3.0" POST /3.0/lists/find HTTP/1.1" 200 19177 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains HTTP/1.1" 200 1658 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains/example.com HTTP/1.1" 200 216 "-" "GNU Mailman REST client v3.3.0" POST /3.0/lists/find HTTP/1.1" 200 19177 "-" "GNU Mailman REST client v3.3.0" GET /3.0/system/versions HTTP/1.1" 200 286 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains HTTP/1.1" 200 1658 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains/lists.example.com HTTP/1.1" 200 230 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains/example.com HTTP/1.1" 200 216 "-" "GNU Mailman REST client v3.3.0" GET /3.1/users/0039b9f69d624016bbedfddebc11f1e4/addresses HTTP/1.1" 200 467 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains/example.com/owners HTTP/1.1" 200 396 "-" "GNU Mailman REST client v3.3.0" GET /3.0/system/versions HTTP/1.1" 200 286 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains HTTP/1.1" 200 1658 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains/lists.example.com HTTP/1.1" 200 230 "-" "GNU Mailman REST client v3.3.0" GET /3.1/domains/example.com HTTP/1.1" 200 216 "-" "GNU Mailman REST client v3.3.0" POST /3.0/lists/find HTTP/1.1" 200 19177 "-" "GNU Mailman REST client v3.3.0" Thanks // David On Fri, Mar 6, 2020 at 9:42 PM David Krantz <gazorg(a)gmail.com> wrote: > > Hi. > > I have the following displayed when I look at the "System Information" > in Postorius: > > Mailman Core Version GNU Mailman 3.3.0 (La Villa Strangiato) > Mailman Core API Version 3.0 > Mailman Core Python Version 3.7.6 (default, Dec 19 2019, 23:49:42) > [GCC 5.4.0 20160609] > > What surprises me is the protocol version. I have tried to set the > protocol version to 3.1 in mailman core (which should be the latest > according to the documentation) and restarting both core and web but > that gives no effect. Normally I have not had any protocol version > defined. Everything seems to work just fine but something is strange, > either the documentation, my setup or mailman/postorius. > > // David

5 years, 6 months

Re: How to remove a nonmember from a list

by skenny＠scss.tcd.ie

Abhilash Raj wrote: > Could be, I am not sure which operation is it stuck at. Can you check logs to see > where is it breaking? Sure. I'm doing all this under Docker; below is what I see in /opt/mailman-web-data/logs/mailmanweb.log when I try to delete a nonmember via the web interface. Thediagnostics appear 30 seconds after I click on 'delete': ERROR 2020-04-09 20:35:51,482 19 postorius.middleware Mailman REST API not available Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 672, in urlopen chunked=chunked, File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 421, in _make_request six.raise_from(e, None) File "<string>", line 3, in raise_from File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 416, in _make_request httplib_response = conn.getresponse() File "/usr/lib/python3.6/http/client.py", line 1346, in getresponse response.begin() File "/usr/lib/python3.6/http/client.py", line 307, in begin version, status, reason = self._read_status() File "/usr/lib/python3.6/http/client.py", line 276, in _read_status raise RemoteDisconnected("Remote end closed connection without" http.client.RemoteDisconnected: Remote end closed connection without response During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/requests/adapters.py", line 449, in send timeout=timeout File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 720, in urlopen method, url, error=e, _pool=self, _stacktrace=sys.exc_info()[2] File "/usr/lib/python3.6/site-packages/urllib3/util/retry.py", line 400, in increment raise six.reraise(type(error), error, _stacktrace) File "/usr/lib/python3.6/site-packages/urllib3/packages/six.py", line 734, in reraise raise value.with_traceback(tb) File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 672, in urlopen chunked=chunked, File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 421, in _make_request six.raise_from(e, None) File "<string>", line 3, in raise_from File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 416, in _make_request httplib_response = conn.getresponse() File "/usr/lib/python3.6/http/client.py", line 1346, in getresponse response.begin() File "/usr/lib/python3.6/http/client.py", line 307, in begin version, status, reason = self._read_status() File "/usr/lib/python3.6/http/client.py", line 276, in _read_status raise RemoteDisconnected("Remote end closed connection without" urllib3.exceptions.ProtocolError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response',)) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/mailmanclient/restbase/connection.py", line 96, in call headers=headers) File "/usr/lib/python3.6/site-packages/requests/api.py", line 60, in request return session.request(method=method, url=url, **kwargs) File "/usr/lib/python3.6/site-packages/requests/sessions.py", line 533, in request resp = self.send(prep, **send_kwargs) File "/usr/lib/python3.6/site-packages/requests/sessions.py", line 646, in send r = adapter.send(request, **kwargs) File "/usr/lib/python3.6/site-packages/requests/adapters.py", line 498, in send raise ConnectionError(err, request=request) requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response',)) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/django/core/handlers/base.py", line 113, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python3.6/site-packages/django/contrib/auth/decorators.py", line 21, in _wrapped_view return view_func(request, *args, **kwargs) File "/usr/lib/python3.6/site-packages/postorius/auth/decorators.py", line 38, in wrapper return fn(*args, **kwargs) File "/usr/lib/python3.6/site-packages/postorius/views/list.py", line 943, in remove_role roster = getattr(the_list, '{}s'.format(role)) File "/usr/lib/python3.6/site-packages/mailmanclient/restobjects/mailinglist.py", line 86, in nonmembers response, content = self._connection.call(url, data) File "/usr/lib/python3.6/site-packages/mailmanclient/restbase/connection.py", line 119, in call raise MailmanConnectionError('Could not connect to Mailman API') mailmanclient.restbase.connection.MailmanConnectionError: Could not connect to Mailman API ERROR 2020-04-09 20:35:51,509 19 django.request Service Unavailable: /postorius/lists/scss-sysadmins.lists.scss.tcd.ie/remove/nonmember/skenny(a)scss.tcd.ie ERROR 2020-04-09 20:35:51,509 19 django.request Service Unavailable: /postorius/lists/scss-sysadmins.lists.scss.tcd.ie/remove/nonmember/skenny(a)scss.tcd.ie The file /opt/mailman-web-data/logs/uwsgi.log contains just one line: [pid: 19|app: 0|req: 82/96] 172.19.199.5 () {46 vars in 1233 bytes} [Thu Apr 9 20:35:20 2020] GET /postorius/lists/scss-sysadmins.lists.scss.tcd.ie/remove/nonmember/skenny(a)scss.tcd.ie => generated 5583 bytes in 31411 msecs (HTTP/1.0 503) 5 headers in 180 bytes (1 switches on core 0) > Can you try doing the same with the REST API, just to verify if it is the Core which > has the issue or it is the web frontend. Using the REST API, I can successfully remove a named nonmember from the list. But I see the same pause-then-fail behaviour when I try to simply list all the nonmembers. My snippet of code can happily produce a listing of the members, but it gets stuck trying to list nonmembers, and then 30 seconds later it crashes out with exactly the same error messages as when I tried to delete a user in the web interface (see above). My piece of code appears below (II invoke it like this: docker exec -it mailman-core bash -c 'python3 /opt/mailman/local/probe.py scss-sysadmins(a)lists.scss.tcd.ie'). from mailmanclient import Client from mailmanclient import MailingList import sys my_list = str(sys.argv[1]) client = Client('http://172.19.199.2:8001/3.0', 'restadmin', 'restpass') this_list = client.get_list(my_list) print("\n\nMembers:\n-------------------------------------------------") for i in this_list.members: print(i) print("\nNonmembers:\n-------------------------------------------------") for i in this_list.nonmembers: print(i) Thanks again Stephen

5 years, 6 months

Re: Template path

by Mark Sapiro

On 9/17/20 9:33 AM, Seth Seeger wrote: > Hello everyone, > > I’m running Mailman from Docker containers, without much customization. (Postorius 1.3.3, Core 3.3.1, API 3.1, Python 3.8.5). I’ve created a list:user:notice:welcome template, and when I try to confirm a subscription, I get an error. > > I followed previous emails on this list which told me to set POSTORIUS_TEMPLATE_BASE_URL in /opt/mailman/web/settings_local.py, but that doesn’t seem to make any difference. (I set it to a different value and the error message didn’t change. I also tried setting it in /opt/mailman/core/settings_local.py to no effect. After each change, I restarted mailman-web and mailman-core containers.) How did you create the template? In Postorius or by manually creating a file somewhere? If by creating a file, POSTORIUS_TEMPLATE_BASE_URL is not relevant, but ensure that the file is findable and readable by Mailman. > From within mailman-web and mailman-core containers, I can reach “mailman-web:8000”. > > In the webpage, I see: Mailman REST API not available. Please start Mailman core. The REST APT is normally exposed on port 8001, not 8000 (See `port` in `mailman conf -s webservice`. What is your setting for MAILMAN_REST_API_URL? does the port match? > In /opt/mailman/core/var/logs/mailman.log, I get: > > [17/Sep/2020:16:23:29 +0000] "GET /3.1/lists/xxx.example.com HTTP/1.1" 200 416 "-" "GNU Mailman REST client v3.3.1" It appears you are connecting to the REST API, but ... ... > urllib3.exceptions.ReadTimeoutError: HTTPConnectionPool(host='mailman-web', port=8000): Read timed out. (read timeout=5) Something appears to be trying to connect to REST on port 8000 -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 1 month

Re: Default values for lists in Mailman 3

by Mark Sapiro

On 9/30/24 02:17, Markus Grandpré wrote: > Dear Mark, dear list, > > in Menu "Mass Operations / Mass Subscription" I have set the default > value for checkbox "Invitation" in file > </usr/lib/python3/dist-packages/postorius/forms/list_forms.py> (on > Debian 12) as you had suggested: > > > invitation = forms.BooleanField( > label=_('Invitation'), > initial=True, > required=False, > help_text=_( > 'If checked, the other checkboxes are ignored and the users > will ' > 'be sent an invitation to join the list and will be > subscribed ' > 'upon acceptance thereof.' > ), > widget=forms.CheckboxInput(), > ) This is correct. > However, administrators of mailing lists on our Mailman3 demo system > report that the invitation is still sent, even if they have deactivated > the sending of the invitation via the “Invitation” checkbox. If the admin is unchecking the Invitation box but not checking the Pre Verified box, the user will still be sent an address confirmation request. Perhaps the admins are mistaking this for an invitation. It the desire is to immediately subscribe the user with no further interaction, in addition to the Invitation box being unchecked, all three of the Pre confirm, Pre approved and Pre verified boxes must be checked. You may wish to set the Pre Verified default to checked in a manner similar to the above, or with Postorius >=1.3.14 (not yet released) you will be able to add ``` POSTORIUS_DEFAULTS = { 'mass_subscription_pre_verify': True } ``` to your Django settings to accomplish this. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year

Mailman-users search results for query "Postorius"