Search results for "2021" - Mailman-users

Re: Fwd: [Django] ERROR (EXTERNAL IP): Internal Server Error: /mailman3/hyperkitty/api/mailman/archive

by David Partain

Hi Mark, Thank you for your kind answer. While I've been running a mailman site for many years, I'm just getting going with mailman3 (and migrating my 1400 lists...) and I feel lost occasionally :) I wrote: > I have the same issue, and have changed the configuration in /etc/mailman3/mailman-web.py to: > > DATABASES = { > 'default': { > 'ENGINE': 'django.db.backends.mysql', > 'NAME': 'mailman3web', > 'USER': 'mailman3web', > 'PASSWORD': 'xxxxxxxxxxxxxxxxxx', > 'HOST': 'localhost', > 'PORT': '', > 'OPTIONS': { > 'init_command': "SET sql_mode='STRICT_TRANS_TABLES'", > 'charset': 'utf8mb4', > }, > } > } > > and restarted stuff, but I cannot tell that it has changed anything. You responded: > That should do it. I think the original message should have been saved > as a queue entry in Mailman's var/archives/hyperkitty/spool/ directory. That directory has all of the messages sent to that list: # ls /var/lib/mailman3/archives/hyperkitty/spool/ 1611827925.8030825+925c996b9b6020ee18e9a689ce23384855159f77.pck 1611827926.1923075+e728f3c29c1fe6eeeca641314cdba7007cb6e132.pck 1611827925.8917305+d16b7004bdbbef98ce40fb8ee70e492715d1607d.pck 1611827926.2623458+1aac13b50d8e7f32eb14d13e6559656aa8f3bd10.pck 1611827925.9594557+7ad2a910b5ee9142c88f0bf26c60c6df960d4262.pck 1611827926.3488555+04a540651c5f829751518433e1c54168ab63a38b.pck 1611827926.0404096+a5e745f51a9f7d541aeb770a89604be17019f3c5.pck 1611827926.4206145+de861eec6404d0c8f9f8bdb180e29bff2de7c52b.pck 1611827926.1167526+0aa63639a4ec102bf63522827637e75e6a2b092a.pck > If this is the case, it would have been retried and produced the same > error with each new post, and after you made the above change, it would > have been archived and the errors stopped. > Are you saying you are still seeing these errors? If so, it may be a > different error. What is the exact error message? We don't need all the > Django stuff, just the part equivalent to > Internal Server Error: /mailman3/hyperkitty/api/mailman/archive > OperationalError at /hyperkitty/api/mailman/archive > (1366, "Incorrect string value: '\xF0\x9F\xA4\xA3\xF0\x9F...' for > column mailman3web.hyperkitty_email.content at row 1") Yes, I'm still seeing the errors. When I send mail to a list with a cute emoji, I see the following in /var/log/mailman3/web/mailman-web.log: ERROR 2021-01-28 10:58:45,708 16923 django.request Internal Server Error: /mailman3/hyperkitty/api/mailman/archive (bunch of python errors omitted) DataError: (1366, u"Incorrect string value: '\\xF0\\x9F\\x98\\x8A\\x0A\\x0A...' for column 'content' at row 1") Also, a bunch of mail is sent to root, presumably one for every message that has previously failed, with the same error information, plus information about the POST method done. (If something there would be helpful, please let me know.) Finally, I'm doing all of this on Ubuntu, with the packages available in the distro, which means: mailman3 3.1.1-9 mailman3-doc 3.1.1-9 mailman3-full 3.1.1-9 mailman3-web 0+20170523-14 python-django-hyperkitty 1.1.4-4 python-django-mailman3 1.1.0-4 python-django-postorius 1.1.2-3 python-mailmanclient 3.1.1-5 python3-mailman-hyperkitty 1.1.0-4 Thanks very much for any help you can offer. Cheers, David

4 years, 5 months

Re: The future is here?

by Abhilash Raj

On Sat, Jan 9, 2021, at 9:49 AM, Stephen J. Turnbull wrote: > Hans-Martin Mosner writes: > > > I'm pretty comfortable with docker containers, mailman and postfix > > in somewhat unsual configurations, and would like to help out there > > (with limited time, though, but I can justify some on job work > > time). > > Cool! > > > What would be the most helpful contribution? I see that there are > > some pull requests that are not yet integrated, but didn't check > > whether they require additional QA to be integrated or are just > > backlogged. > > > Would you rather like assistance in integrating existing pull > > requests, QA work to make them integration-ready, or work on > > untackled issues to create more pull requests? :-) > > Abhilash is busy, so in case he doesn't answer quickly, I offer my > thoughts. But Abhilash he is the most important developer on the > containers. > > If you are considering formal membership in the core (ie, direct > commit privilege, with an informal expectation of review from "more > senior" core devs), integrating existing pull requests might be top > priority, to get practice in that. Otherwise, reviews and triage on > all container issues, and QA on existing pull requests, are probably top > priorities IMO. Thanks Steve for the quick response! I agree with Steve that most help would be with QA on existing issues and PRs. There aren’t many PRs pending, but some of them are pending because I am a bit weary of existing users breaking due to things like upgrading database versions etc. I don’t think there is a good way to handle those, other than just minor/major bumping versions of the release. I’ve been debating it in my head for a while whether it makes sense to bump a minor version for a ‘sample configuration’ (docker-compose.yaml file) bumping the version of a database. Perhaps caution in documentation to verify the side-effects to simply applying the configuration from the git repo is enough? There are a lot of tickets labelled ‘documentation’ that are rather low hanging fruits to be tackled easily. If you want to tackle something bigger, you help create a new compose configuration that adds a web server and MTA for a rather ‘complete setup’. I’ve just started labelling important issues with ‘priority p0’, so that might also be a good starting point. There aren’t many issues, but some tracker grooming/prioritization is needed too ;-) Abhilash > Steve > _______________________________________________ > 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, 5 months

localtime() cannot be applied to a naive datetime

by Freerk Bosscha

Since yesterday I get the following error-message when I go to the webinterface: ValueError at /admin/login/ localtime() cannot be applied to a naive datetime Request Method: GET Request URL: https://mailman.pgtrynwalden.nl/mailman3/admin/login/?next=/mailman3/admin/ Django Version: 2.2.28 Exception Type: ValueError Exception Value: localtime() cannot be applied to a naive datetime Exception Location: /usr/lib/python3/dist-packages/django/utils/timezone.py in localtime, line 207 Python Executable: /usr/bin/uwsgi-core Python Version: 3.9.2 Python Path: ['.', '', '/usr/lib/python39.zip', '/usr/lib/python3.9', '/usr/lib/python3.9/lib-dynload', '/usr/local/lib/python3.9/dist-packages', '/usr/lib/python3/dist-packages', '/usr/lib/python3.9/dist-packages'] Server time: vr, 1 Mrt 2024 11:52:50 +0100 Mailman info: mailman info GNU Mailman 3.3.3 (Tom Sawyer) Python 3.9.2 (default, Feb 28 2021, 17:03:44) [GCC 10.2.1 20210110] config file: /etc/mailman3/mailman.cfg db url: mysql+pymysql://mailman3:xxxxxxx If this issue was posted before, i'm sorry, i haven't found it: Any ideas how to solve this issue would be appreciated Environment: Request Method: GET Request URL: https://mailman.pgtrynwalden.nl/mailman3/admin/login/?next=/mailman3/admin/ Django Version: 2.2.28 Python Version: 3.9.2 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', 'django_mailman3.lib.auth.fedora') 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: File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py" in inner 35. response = get_response(request) File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in _get_response 145. response = self.process_exception_by_middleware(e, request) File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in _get_response 143. response = response.render() File "/usr/lib/python3/dist-packages/django/template/response.py" in render 106. self.content = self.rendered_content File "/usr/lib/python3/dist-packages/django/template/response.py" in rendered_content 83. content = template.render(context, self._request) File "/usr/lib/python3/dist-packages/django/template/backends/django.py" in render 61. return self.template.render(context) File "/usr/lib/python3/dist-packages/django/template/base.py" in render 169. with context.bind_template(self): File "/usr/lib/python3.9/contextlib.py" in __enter__ 117. return next(self.gen) File "/usr/lib/python3/dist-packages/django/template/context.py" in bind_template 246. updates.update(processor(self.request)) File "/usr/lib/python3/dist-packages/postorius/context_processors.py" in postorius 38. mailman_day=(timezone.localtime(timezone.now()).day == MAILMAN_DAY), File "/usr/lib/python3/dist-packages/django/utils/timezone.py" in localtime 207. raise ValueError("localtime() cannot be applied to a naive datetime") Exception Type: ValueError at /admin/login/ Exception Value: localtime() cannot be applied to a naive datetime

1 year, 4 months

Re: Delete Django profiles not signed up to a list

by Allan Hansen

Mark, Will this be part of an upcoming update or micro update to Mailman? Yours, Allan Hansen P.O. Box 2423 Cypress, CA 90630 > On Mar 31, 2023, at 15:49, Mark Sapiro <mark(a)msapiro.net> wrote: > > On 3/31/23 14:17, Andrew Hodgson wrote: >> Hi. >> Has anyone managed to get this script running using the Mailman-Web setup in a venv? It was working when Settings.py was in the /opt/mailman/mm directory but since moving to Mailman-Web has it in /etc/mailman3. I have been trying to import Mailman-Web to get the Django environment running but every time I do this I get a not configured exception raised. > > > First, get the latest version of the script from https://www.msapiro.net/scripts/clean_users.py - not the one in this threat attached to https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > > Then, you need to change `/opt/mailman/mm` in three places to `/etc/mailman3` as in > ``` > --- /opt/mailman/mm/bin/clean_users.py 2021-05-08 20:03:31.657565251 -0700 > +++ clean_users.py 2023-03-31 15:48:31.772383287 -0700 > @@ -2,13 +2,13 @@ > import os > import sys > > -sys.path.insert(0, '/opt/mailman/mm') > +sys.path.insert(0, '/etc/mailman3') > # The above line is required. The next line doesn't hurt, but it doesn't work > # because the PYTHONPATH environment setting is processed by Python's setup > # and must be in the environment when Python starts to be effective. > -os.environ['PYTHONPATH'] = '/opt/mailman/mm' > +os.environ['PYTHONPATH'] = '/etc/mailman3' > os.environ['DJANGO_SETTINGS_MODULE'] = 'settings' > -os.environ['MAILMAN_CONFIG_FILE'] = '/opt/mailman/mm/mailman.cfg' > +os.environ['MAILMAN_CONFIG_FILE'] = '/etc/mailman3/mailman.cfg' > > import django > django.setup() > ``` > Also, look at this > ``` > # If we delete the Django user and there is a Mailman user with no memberships > # shall we delete the Mailman user too. > DELETE_MAILMAN_USER = False > # Shall we delete the Django user if there is a Mailman user with no > # memberships or only if there is no Mailman user. > DELETE_DJANGO_IF_MAILMAN = True > ``` > and consider whether you want to set `DELETE_MAILMAN_USER = True` to also delete the Mailman user if any, and/or set `DELETE_DJANGO_IF_MAILMAN = False` to not delete the django user if there is a Mailman user with no memberships. > > -- > 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 hansen(a)rc.org

2 years, 3 months

Ann: Postorius 1.3.6 is now out

by Abhilash Raj

Hey Everyone, I just tagged and released Postorius 1.3.6. This release includes both bug fixes and new features. Some of the notable features include - Ability to list and handle un-subscription requests to the list - Option to choose delivery mode and delivery_status directly when subscribing to a list - Addition of a user management interface, which allows updating a users password, manually verifying their email addresses, update user’s Display Name etc. - Expose a number of Bounce processing related options in List’s settings A full list of changes is available here https://docs.mailman3.org/projects/postorius/en/latest/news.html#news-1-3-6 You can install this release using pip $ pip install postorius django-mailman3 mailmanclient —upgrade Do note that this release requires Mailman Core 3.3.5, so you need to upgrade Core before upgrading Postorius. The release tarball is available on PyPI as usual: https://pypi.org/project/postorius/1.3.6/#files Please also ensure to run the post-install commands as per the upgrade documentation: https://docs.mailman3.org/en/latest/upgrade-3.2.html#post-upgrade Thanks to all the folks who helped with this release! Abhilash > Please also ensure to run the post-install commands as per the upgrade documentation[4] (commands _after_ pip install, needs a post-install heading/anchor in there :-). > On Sep 19, 2021, at 8:48 PM, Abhilash Raj <maxking(a)asynchronous.in> wrote: > > Hey Everyone, > > I am pleased to announce that Postorius 1.3.6b1 is now out. This is the first pre-release for 1.3.6, which is slated to release next week soon after Mailman Core 3.3.5 release. > > This release requires Mailman Core 3.3.5 release, so if you are trying out this release, please also upgrade Mailman Core to 3.3.5rc1 (which was just released today). > > This release includes several new features and bug fixes. A full list of changes is available here[1]. > > With this release, we have also improved on the localization of the interface, if you want to help out before the release of the stable 1.3.6, please see the instructions for translators here[2]. We use Weblate for translations, so if you are familiar with that, you can directly head over there[3]. > > Since this is a pre-release version, you can install this using pip via: > > $ pip install --upgrade --pre postorius django-mailman3 mailmanclient > > Please also ensure to run the post-install commands as per the upgrade documentation[4] (commands _after_ pip install, needs a post-install heading/anchor in there :-). > > A release tarball is available on PyPI: > > https://pypi.org/project/postorius/1.3.6b1/#files > > Finally, thanks to all the folks who helped with this release in any capacity and made it possible. > > [1]: https://docs.mailman3.org/projects/postorius/en/latest/news.html#news-1-3-6 > [2]: https://docs.mailman3.org/en/latest/translation.html > [3]: https://hosted.weblate.org/projects/gnu-mailman/postorius/ > [4]: https://docs.mailman3.org/en/latest/upgrade-3.2.html#virtualenv-install > > > thanks, > Abhilash -- thanks, Abhilash Raj (maxking)

3 years, 9 months

Re: Mailman backend maintenance task

by Abhilash Raj

> On Aug 24, 2021, at 8:33 AM, Stephen J. Turnbull <stephenjturnbull(a)gmail.com> wrote: > > Hi, Eugenio, > > I wrote this earlier but am in the middle of moving my office so my > mail has been intermittent. I have been following your discussion > with Abhilash, and he's definitely the expert, especially if you are > using the containers he creates and distributes. But there's some > information here he hasn't mentioned yet. > > Please consider the following discussion to be background that allows > you to understand some of the considerations. I've only run the > Mailman 3 suite with all three running constantly on the same host, so > I have no experience with this kind of issue. > > eugenio.jordan(a)esa.int writes: > >> Our customer is currently using PostGRESQL as backend, and we would >> like to perform some maintenance tasks, namely running vacuum full, >> or at least trying to rebuild hyperkitty_email primary key related >> index. We have been asked on the real impact of putting in place >> such initiative. Though the latter is related to archiving, I >> haven't found a way to stop just Hyperkitty or Django related >> processes other than stopping Mailman's core, hence preventing >> mails addressed to distribution lists from being delivered, could >> you please confirm if I am correct? > > Mailman core can certainly run without either Postorius or HyperKitty. > Controlling Mailman core (moderation, helping users) without Postorius > is annoying, but it can be done. If you stop the HyperKitty process, > what should happen, I believe, is that posts for archiving will > accumulate in the 'archive' queue until HyperKitty is available again. > > It's been a while since I studied this so I could be completely wrong, > but as I understand it HyperKitty and Postorius are not daemon > processes. Rather, they are WSGI applications, which means they are > subprocesses spawned by your webserver, and controlled by it. In > order to keep them from running, you would reconfigure the webserver > to not call those WSGI applications. How that is done is specific to > the webserver and the WSGI module. If you are running from Docker > containers, most likely, you can just stop their containers. Yeah, Postorius and Hyperkitty themselves aren’t daemons, but they run inside WSGI servers like uwsgi/gunicorn which are typically separate daemons than webserver like Nginx which sits in the front. However there are common webserver modules like mod_wsgi (for apache2) which will let you run without managing a separate WSGI server. So, it depends on the setup, you can either just stop the WSGI server or stop the web server. For, containers, the WSGI server (uwsgi) runs in the container and you can just stop the mailman-web container. -- thanks, Abhilash Raj (maxking)

3 years, 10 months

Ann: Mailman Core 3.3.5 is out

by Abhilash Raj

Hey Everyone, I just tagged and uploaded Mailman Core 3.3.5 release. This release includes both bug fixes and some new features. A full list of changes is available here: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.… You can install this version using pip: $ pip install mailman==3.3.5 The release tarball is available on PyPI as well: https://pypi.org/project/mailman/3.3.5/#files Thanks to everyone who made this release possible! Abhilash > On Sep 19, 2021, at 11:02 AM, Abhilash Raj <maxking(a)asynchronous.in> wrote: > > Hey Everyone, > > I just tagged and released Mailman Core 3.3.5rc1 release. > > This is identical to 3.3.5b1 in code, the only changes that have been made are in utility scripts and testing configuration. > > You can install this version using: > > $ pip install --pre mailman==3.3.5rc1 > > If you want to download a release tarball, you can do so from here: > > https://pypi.org/project/mailman/3.3.5rc1/#files > > This is the first (and only) planned release candidate for 3.3.5 release. The stable release is planned for next week. > > thanks, > Abhilash > > > On 9/7/21 12:39 AM, Abhilash Raj wrote: >> Hello Everyone, >> I am pleased to announce that Mailman Core 3.3.5b1 is now out. It is a pre-release for 3.3.5, which is slated to come out in 3 weeks from now. >> I am planning for a 2 week beta period, after which I'll release the first RC and then stable a week after. Right now I am not planning to release a second beta version, but if there are several changes in Core in the next week or so, then I might. >> This release includes a lot of bug fixes and some new features. It also includes a security enhancement that improves the authentication of REST API by adding resistance to some timing channel attacks. >> A full list of changes in this version can be found here[1]. >> [1]: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.… We have also made improvements in the i18n workflow and now the email templates are updated from the translated messages in the .po files that we get from Weblate. Documentation for translators is available here[2] if you want to help translate Mailman into your native language. >> [2]: https://docs.mailman3.org/en/latest/translation.html >> This is a pre-release version, if you want to test it with your setup, you can install it using: >> $ pip install --pre mailman==3.3.5b1 >> If you want to download a release tarball, you can do so from here: >> https://pypi.org/project/mailman/3.3.5b1/#files >> This release received a lot of contributions from community, which I am really happy about! I'd like to thank everyone who made this release possible! > > > -- > thanks, > Abhilash Raj (maxking) -- thanks, Abhilash Raj (maxking)

3 years, 9 months

Re: at the finish line of mailman3 docker, but can't sign in.

by Abhilash Raj

On Fri, Jul 30, 2021, at 1:04 PM, bob B wrote: > is this the info you need for the container version > > [root@..... docker-mailman]# docker ps > CONTAINER ID IMAGE COMMAND > CREATED STATUS PORTS > NAMES > 30af82ac9315 maxking/mailman-web:0.3 "docker-entrypoint.s…" 2 > hours ago Up 2 hours 127.0.0.1:8000->8000/tcp, > 127.0.0.1:8080->8080/tcp mailman-web > cd01a99cf908 maxking/mailman-core:0.3 "docker-entrypoint.s…" 2 > hours ago Up 2 hours 127.0.0.1:8001->8001/tcp, > 127.0.0.1:8024->8024/tcp mailman-core > 77fe89ced9e8 postgres:9.6-alpine "docker-entrypoint.s…" 2 > hours ago Up 2 hours 5432/tcp > dockermailman_database_1 > > > for smtp host > ------------ > cat /opt/mailman/web/settings_local.py > #allowed_hosts = ['127.0.0.1', 'localhost','HOST.DOMAIN.org'] > #ALLOWED_HOSTS = ['127.0.0.1', 'localhost','HOST.DOMAIN.org'] > ALLOWED_HOSTS = ['*'] > DEBUG = True > EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend' > EMAIL_HOST = 'smtp.example.com' > EMAIL_PORT = 25 > --------------------------- > cat /opt/mailman/core/mailman-extra.cfg > # mailman-extra.cfg > > [mta] > incoming: mailman.mta.postfix.LMTP > outgoing: mailman.mta.deliver.deliver > # mailman-core hostname or IP from the Postfix server > lmtp_host: localhost > lmtp_port: 8024 > # Postfix server's hostname or IP from mailman-core > smtp_host: smtp.example.com > smtp_port: 25 > configuration: /etc/postfix-mailman.cfg > [mailman] > # This address is the "site owner" address. Certain messages which must be > # delivered to a human, but which can't be delivered to a list owner (e.g. a > # bounce from a list owner), will be sent to this address. It should point to > # a human. > site_owner: my_real_email_is_in_the_file.com > __________________________________ > > My docker most machine /etc/postfix/main.cf has > > transport_maps = > regexp:/opt/mailman/core/var/data/postfix_lmtp > local_recipient_maps = > regexp:/opt/mailman/core/var/data/postfix_lmtp > relay_domains = > regexp:/opt/mailman/core/var/data/postfix_domains > > > # Support the default VERP delimiter. > recipient_delimiter = + > unknown_local_recipient_reject_code = 550 > owner_request_special = no > > ------------------------------ > > > > is that correct? I leave them set to smtp.example.com because the will > send out via the docker host machine, and so i ONLY have my actual > outbound server listed in /etc/postfix/main.cf on the docker host > machine, or do i need to replace smtp.example.com with our outbound > server? You should replace smtp.example.com in both mailman-extra.cfg and settings_local.py with whatever the IP address of the MTA (which I assume is running on the host, so it'd be the "gateway" address from the container's network) so Mailman components can talk to Postfix to deliver email. There is some gaps in the documentation because of the latest changes that have been made in the repo and the documentation and docker-compose files aren't versioned properly :( I've opened a bug report to update the compose and versions https://github.com/maxking/docker-mailman/issues/481 -- thanks, Abhilash Raj (maxking)

3 years, 11 months

Re: Send MySQL data to mailman list for distribution

by Ruth Ivimey-Cook

Hi, Your request is not particularly clear -- telling us what the end goal is would help -- but I think the answer is neither the mailman menu nor the phpmyadmin can do what you want. That is assuming that you want to send some tabular information to people via email, where the recipients are managed via mailman. Consider the parts of your process: 1) some data source, which you have not mentioned. 2) something that stores data from the source into MySQL tables. 3) something that creates html page text from the MySQL tables, that can be delivered by an http server. 4) something that creates an email message from the data in the MySQL tables. 5) something that sends the email message to an MTA (such as exim, postfix, etc). 6) something that stores and manages the email recipients to whom the data is sent (= Mailman + postorius etc). I think you must have something that manages (1), (2), and (3), as you mention that you have a web page that works. This solution likely uses php and nginx. [ Note that a web page never sends an email. It is possible for (eg) PHP programs to send an email, and it can be the case that a php program that is generating html for a web page can also generate an email message and send it, but that is to conflate two quite different processes unnecessarily. ] You still need (4) and (5), which mailman cannot help with but for which libraries like PHPMailer, and programs like exim, can help. The message to your recipients will be sent in (5) to mailman using an email address to mailman core which is set up as a posting non-member of the list, so it doesn't also get copies of mails sent. Hope this helps, Ruth On 01/06/2021 21:46, Zden Pos via Mailman-users wrote: > I'm trying to connect existing MySQL data to the Mailman distribution list. > Actually, a message is sent from the web page. It remains on this page and is also stored in the MySQL table on the provider server. This is working fine. > I have also existing Mailman distribution list generated from the cPanel on the provider server as well. This list is working fine when used for a direct mailing. > > I need to link the MySQL table to the Mailman distribution list. When the message is posted on the web page and stored in the MySQL table, it is also to be sent to members as per the Mailman distribution list. I don't know where to configure it. In the phpMyAdmn page of the MySQL or in the Malman menu ? > > Thank you for your help > _______________________________________________ > 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/ -- Software Manager & Engineer Tel: 01223 414180 Blog: http://www.ivimey.org/blog LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/

4 years, 1 month

Re: User management page [was: Changing subscription address]

by Abhilash Raj

> On Mar 22, 2021, at 7:56 AM, Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > > Abhilash Raj writes: > >> Typo :( Page in Postorius is what I meant to say. > > :D No problemo, mon, I just did it too -> > >> Is that necessarily required? Every user in Django has a corresponding >> user in Core, but the converse isn’t true and I am not sure if that is even >> required. > > I meant "accessed from Postorius or HyperKitty." :-) > >> You will be able to see: >> - Does the user have a Django account? >> - All Subscriptions for the User >> - All addresses of the User >> >> You will be able to perform following actions: >> - Add or remove a user’s address >> - Verify or un-verify an address >> - Set any address as primary for the user >> - Update display name of the user >> - Update address on any of the subscriptions > > I don't think we *need* a Django account for what I'm thinking of. I > do think that creating the account on User access from Postorius might > make the implementation logic simpler. > >> What I am on fence about: >> - Provide a full blown preferences menu to the admin for that user. This >> will also make the UI extremely complex to see and implement. > > Wait to decide on that until I have a mockup or maybe a full MR. > >> But, when you have an account in Django with a different email >> (email2) and a different Mailman user (user2) and you add a second >> email (email1) to your account and are able to prove ownership by >> verifying the address, Django will ask Core to add that second address >> (email1) to your Mailman user (user2) and absorb “user1”. This >> process is already implemented. > > Good. > >> However, if two Django accounts are created for “user1” and “user2” >> then situation becomes more tricky and currently we don’t have a >> way to resolve that short of delete one of the accounts and add the >> addresses to other account. > > Delete "that" and add its attributes to "this" is what I had in mind. We could automate the absorb other account and copy all settings and subscriptions over in a user based workflow. I don’t see a lot of unknowns in implementing that. You have to manually do it today, and deleting account will delete subscriptions so when you add them to your other account you have to resubscribe. So, the path could really use some changes. I think I have a ticket open in P to allow deleting P account but not delete the Mailman User and subscriptions, which would make this manual process much better. -- thanks, Abhilash Raj (maxking)

4 years, 3 months

Mailman-users search results for query "2021"