Search results for "Postorius" - Mailman-users

Re: Core, Hyperkitty and Postorius releases

by Mark Sapiro

On 5/13/21 2:27 PM, Odhiambo Washington wrote: > On Wed, Feb 3, 2021 at 5:00 AM Abhilash Raj <maxking(a)asynchronous.in> wrote: > >> Hey Everyone, >> >> I am pleased to announce new stable releases for Mailman Core, Postorius, >> Hyperkitty. >> >> These include both new features and bug fixes. Complete change log for >> each components: >> >> Mailman Core 3.3.3: >> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.… > > > May I ask if this is a typo? > I am asking because Mailman Core 3.3.4 was announced on Marc 22nd. > So is this new one version 3.3.3 or 3.3.5? The text you are quoting is from the Feb 2 announcement <https://mail.python.org/archives/list/mailman-announce@python.org/message/N…> of the release of Mailman core 3.3.3. Mailman 3.3.4 was released and announced at https://mail.python.org/archives/list/mailman-announce@python.org/message/H… on March 21 and is the current release. There is no "new one". -- 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: template head/footer questions.

by Mark Sapiro

On 4/8/22 11:04, bob B via Mailman-users wrote: > I migrated from mailman 2 to mailman3 and had head/footer questions. > > In the mailman 3 GUI see the templates section, so where do those files get edited/stored? in the postorius_emailtemplate table in the database. > I added a footer to a list via the GUI, but I do not see it in: > /var/templates/lists/[listNAME]/en Because when you set a template in Postorius it makes an entry in the template table in the database with a URI pointing to its own API to retrieve the template. > I see some directories corresponding to list names in /var/templates/lists/ But I do not have a directory for all my lists and for the footer one I just added. > > Bottom line, > > I assume I should not edit or create any files in /var/templates/lists/ and just use the GUI? That's up to you. The default search path for templates in the absence of a template table entry (or even with one with a mailman:/// URI) includes the var/templates/lists/list_id directory. is this directory leftover from migrating from mailman 2 to 3? No I have a list admin who has made some head and footer files and wants me to put them in /var/templates/lists/[listNAME]/en/.... but I think that may not be the best option. Again, it's up to you. If you have Postorius and want list admins to be able to create, modify, break, etc. templates without involving you, then Postorius is a good option, but it isn't in all cases. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 2 months

Re: Mailman, etc. upgrade woes and persistent bugs

by Mark Sapiro

On 2/11/21 10:22 PM, hansen(a)rc.org wrote: > 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. 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?? I'm sorry about that. It's too late now, but the avoidance is discussed at <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…>. > I got many angry emails, messages and phone calls asking what was going on, as they were bona fide list members. I was very surprised myself. > > 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???. The members can't see if their account is enabled. Is this another example of the disconnect between Mailman and Postorius? If the user has a Django account, she can see all that info at (e.g. for this list) <https://lists.mailman3.org/mailman3/accounts/subscriptions/> She gets there from `Mailman settings` in the dropdown under her user name. She can also get there via the `Manage Subscription` button on the list's Info page. That takes her to `List-based preferences` for the list. Any setting not selected there is inherited from the Address-based preferences or Global Mailman preferences > Further, even after the upgrade, the moderators still cannot access the list memberships even though all the lists are set to allow that. I would have asked the moderators to do this if this access bug had been fixed, but they can't get there. You've already reported this at <https://gitlab.com/mailman/postorius/-/issues/462>, and it's been previously reported at <https://gitlab.com/mailman/postorius/-/issues/369>. > 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 sorry you had to go through this. The potential issue and the avoidances should be better documented. Unfortunately, they aren't. > 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). As I note above, this is a known issue. We are a small project with very feew core developers, all of whom are volunteers. There is a merge request at <https://gitlab.com/mailman/postorius/-/merge_requests/423> which purports to fix <https://gitlab.com/mailman/postorius/-/issues/369>, but as you can see from the comment thread, it is not complete and the author has apparently disappeared. If you would like to take it over and address the deficiencies, we would welcome that. > b. The ability of members to change their addresses for all lists they are subscribed to. Users can add addresses to their account and can then change their subscribed address at (again, e.g. for this list) <https://lists.mailman3.org/mailman3/accounts/list-options/mailman-users.mai…> (Get there via the `Manage Subscription` button on the list's Info page.) If one is subscribed to lists via their `primary` address, one can go to `E-mail Addresses` in their account settings and make a new address `primary` and that will change all their subscriptions. > and further, now: > > c. That when members go to look at their subscription info, they can actually see the settings. They can if they go to `Mailman settings` in the dropdown or the `Manage Subscription` button on the list's Info page and look at all the tabs. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 4 months

"Something went wrong | Mailman REST API not available. Please restart Mailman core.

by Hirayama, Pat

Greetings, Some of my lists have started displaying this behavior — when you try to access the list page(s), you get a page with this message: Something went wrong Mailman REST API not available. Please restart Mailman core. My mailman-core docker container is running, as are mailman-django-uwsgi, mailman-nginx and mailman-postfix. Restarting the containers doesn't change this behavior. Google suggests restarting mailman core. Or that we might not be using the correct account name, password or port. The weird thing is that it is not all lists. Most of them seem to be fine. Which suggests to me that the issue is with a few lists, but not systemwide, so I think my settings in mailman.cfg, settings.py, settings_local.py are likely correct. For the problem lists, I see this in the log: ERROR 2025-10-29 18:38:56,784 7 postorius Mailman REST API not available ERROR 2025-10-29 18:38:56,790 7 django.request Service Unavailable: /postorius/lists/obfuscated.name.lists.fhcrc.org/ ERROR 2025-10-29 18:38:56,790 7 django.request Service Unavailable: /postorius/lists/obfuscated.name.lists.fhcrc.org/ So, Postorius can't communicate with the API, I guess? I look at settings_local.py: MAILMAN_REST_API_URL = 'http://mailman-core:8001' I believe 8001 is the default, and since I haven't specified one in the [webservice] section of mailman.cfg, I'm assuming 8001 is correct (plus, it works for other lists). There are a few messages waiting for moderator approval — otherwise, I'd probably try just deleting the list and recreating it. Anyone have any suggestions on what else I should look at? Thanks! -p Pat Hirayama Pronouns: he/him/his Systems Engineer IT | Systems Engineering - Infrastructure Fred Hutch Cancer Center O 206.667.4856 phirayam(a)fredhutch.org<mailto:phirayam@fredhutch.org>

7 months, 3 weeks

Re: customized welcome message

by Nils

Forget the previous message. Thank you very much for your help, Mark. I looked at the configuration files once more, and changing POSTORIUS_TEMPLATE_BASE_URL in mailman-web.py fixed the issue for me. Kind regards On 12/7/23 23:09, Nils wrote: > On 12/7/23 22:40, Mark Sapiro wrote: >> How and to what did you set the URL for the template? What does the >> database query >> >> SELECT uri FROM template WHERE name = 'list:user:notice:welcome'; >> >> show? > http://localhost/postorius/api/templates/list/testliste.lists.DOMAIN.TLD > > This value can't work. Now it makes sense that it gets redirected and > the use of localhost also explains why it didn't show in any of the > virtual hosts log files that I was checking until it was redirected. > > However, I didn't set that value. I edited the template at > postorius/lists/testliste.lists.DOMAIN.TLD/templates and there I can > just select a template type and then I get one textarea input field > for the content. > The value in the database is set automatically, when I create a > template in postorius (and is also automatically removed when I delete > a template there). I can't edit this value without manually changing > it in the database. > >> This is very old. Current Postorius is 1.3.10. 1.2.4 is from February >> 2019. The Debian/Ubuntu packages are out of date. We recommend >> installing via the doc at >> https://docs.mailman3.org/en/latest/install/virtualenv.html > > The server will be updated from Ubuntu 20.04 (focal) to 22.04 (jammy) > very soon. The Debian/Ubuntu packages sure have their downsides but > once they work, they update automatically and require very little > maintenance.

2 years, 6 months

Re: mm3 installation question

by Odhiambo Washington

On Wed, Mar 6, 2024 at 3:13 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 3/5/24 1:52 PM, advorkin(a)cs.princeton.edu wrote: > > > > I went with the apache/uswgi configuration. The site is up and running, > but if I click Postorius, it gets redirected to > https://mysite.com/postorius/lists and I get not found error message. > > > > The same goes for Lists and Archives. > > Compare your urls.py to > < > https://gitlab.com/mailman/mailman-web/-/blob/master/mailman_web/urls.py?re…>. > > Some of the `path` settings are probably not in the same order as in > that file. The > > ``` > path('mailman3/', include('postorius.urls')), > path('archives/', include('hyperkitty.urls')), > ``` > settings should come after the > ``` > path('postorius/', include('postorius.urls')), > path('hyperkitty/', include('hyperkitty.urls')), > ``` > settings (unfortunately, mailman-web 0.0.8 has these in the wrong > order). Or you can just delete the 'postorius/' and 'hyperkitty/' ones > or you can add > ``` > ProxyPass "/postorius" "http://127.0.0.1:8000/postorius" > ProxyPass "/hyperkitty" "http://127.0.0.1:8000/hyperkitty" > ``` > to your Apache config. > The odd thing is that the HOWTO that he followed never involves the manipulation of any urls.py at all - it's not even mentioned at any point. So obviously the issue is caused by something else and I suspect something within Apache needs to be re-evaluated in the guide. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

2 years, 3 months

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

by Stefan Bauer

So i fixed it by myself, just think about it again. ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ Note the trailing slash at the end. After removing it, the webinterface is up again. But i have no idea, why this is NOW a problem and was not in the past. Maybe something has changed in the way, apache is handling this now. Anyway, problem solved for me. Am Mo., 25. Okt. 2021 um 10:45 Uhr schrieb Stefan Bauer <cubewerk(a)gmail.com >: > Dear Users, > > I recently upraded mailman3 from Ubuntu 18 to 20. After accessing the > web-interface via > > https://my.mailinglistserver.local/mailman3/postorius/lists/ > > I receive > > Not Found: /mailman//postorius/lists/ > [pid: 1346851|app: 0|req: 4/4] 10.254.253.12 () {70 vars in 1369 bytes} > [Mon Oct 25 10:39:59 2021] GET /mailman3/postorius/lists/ => generated 2821 > bytes in 12 msecs (HTTP/1.1 404) 5 headers in 155 bytes (1 switches on core > 1) > > Where does the wrong path come from (mailman vs. mailman3) > > After enabling Debug, i see in the browser the following: > > > Page not found (404) > Request Method: GET > Request URL: https://my.mailinglistserver.local/mailman//postorius/lists/ > > Using the URLconf defined in urls, Django tried these URL patterns, in > this order: > > ^$ > ^postorius/ > ^hyperkitty/ > ^user-profile/delete$ [name='mm_user_account_delete'] > ^user-profile/$ [name='mm_user_profile'] > ^accounts/ > ^admin/ > > The current path, /postorius/lists/, didn't match any of these. > > You're seeing this error because you have DEBUG = True in your Django > settings file. Change that to False, and Django will display a standard 404 > page. > > My apache configuration is very simply: > > # more /etc/apache2/conf-enabled/mailman3.conf > Alias /mailman3/favicon.ico > /var/lib/mailman3/web/static/postorius/img/favicon.ico > Alias /mailman3/static /var/lib/mailman3/web/static > > <Directory "/var/lib/mailman3/web/static"> > Require all granted > </Directory> > > <IfModule mod_proxy_uwsgi.c> > ProxyPass /mailman3/favicon.ico ! > ProxyPass /mailman3/static ! > ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ > </IfModule> > > I dont see where the path gets traversed in the wrong way. Any help is > greatly appreciated. > > thank you. > > Stefan >

4 years, 7 months

Re: List nonmembers

by Abhilash Raj

On Mon, Jul 8, 2019, at 8:40 PM, Stephen J. Turnbull wrote: > Andrew Bernard writes: > > > Under Users for a list, there is a category for List > > nonmembers. What does this term mean? [It's rather curious > > philosophically when you think about it, because I would have > > thought that the category [all humans - list members] fits that > > category term.] > > I don't recall the exact definition of "list member", but I can't > resist explaining the "philosophy". :-) > > In the mail system as a whole, what we can confirm is a mailable > mailbox. That corresponds to an *address* in Mailman. But users > (typically humans) often have multiple addresses, that they would like > to configure together (eg, single signon, same setting for not-me-too, > etc). Thus we have a *user* concept, which requires a agent to log in > and establish a *user* and attach addresses to it. I don't remember > the exact details, but both *users* and *addresses* can exist > independently of the other, though they are normally linked. Finally, > a *subscription* is a link between an *address* and a *mailing list*. > > ISTR that merging *users* in the database is kind of annoying, so > instead of automatically creating a *user* to back every known > *address* (eg, when banned or moderated), the *address* is allowed to > participate in the list as a banned or moderated address without being > related to a *user*. There may be other cases where an *address* > lacks a *user*. > > I'm pretty sure there are ways in Postorius to create a *user* that > has no *addresses*, although I've not tried, and I don't know if such > Postorius users would be reflected in the core database. That's not True anymore, signing in to Postorius/Hyperkitty requires you to have an email address and that address is propagated to Core (unless, Core is down, which wouldn't block the sign-up process and would result in a Postorius only user) synchronously using sign-up and sign-in hooks in Django. > > 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)

6 years, 11 months

Re: mailman import21 passwords

by Sam Darwin

> There is no guarantee that any Mailman Core installation into which a MM 2.1 list is imported actually also supports Django users for Postorius and/or HyperKitty. There is no guarantee that a mailman-core installation also includes Postorius and/or HyperKitty. However we can imagine that the vast majority do utilize all those components. If you've installed mailman3, you are probably installing Postorius and HyperKitty. To account for the fact that it's not 100% guaranteed, the import script could require a flag such as --django-accounts. Or it could even be another script entirely. So, the step wouldn't be automatic, but at least it would be an option. > inherently not secure The passwords were good enough for mailman2. If a mailman2 instance has been in production for 20 years and users aren't complaining about security, maybe it's not a show stopper. The point is to make the upgrade seamless. That means... being able to say that everyone gets to keep their user account and password. To be able to easily tell the users "Your account is still the same. Just log in. Change your password when you like." In the current context, passwords are associated with django accounts rather than mailman-core accounts. So this is about creating django users. > creating a django user is "expensive". "poor performance" I didn't follow what that means. What is expensive? What is poor performance? Creating new django accounts en masse would be a one-time operation. It doesn't matter if it's slow, or expensive, since it only happens once. And it would be optional. With the --django-accounts flag. Or another separate script. Then you can tell users "Your account is the same as before. A transparent upgrade. Just log in".

1 year, 9 months

Re: New releases

by Danil Smirnov

Hi Abhilash, Thank you for the releases! I've updated my installation and I'm confused by this Postorius announcement: > Settings page is also slightly different with all the sections on the > vertical menu on left instead of horizontal tabs. I have Postorius verson 1.3.3 but I still see horizontal tabs not vertical menus. Could you elaborate more on this? Best regards, Danil Smirnov On Tue, 2 Jun 2020 at 22:21, Abhilash Raj <maxking(a)asynchronous.in> wrote: > Hi Everyone, > > I am pleased to announce new stable releases for: > > - Postorius: 1.3.3 > Changelog: > https://docs.mailman3.org/projects/postorius/en/latest/news.html#id1 > Download: https://pypi.org/project/postorius/1.3.3/ > - Hyperkitty: 1.3.3 > Changelog: https://hyperkitty.readthedocs.io/en/latest/news.html#id1 > Download: https://pypi.org/project/HyperKitty/1.3.3rc1/ > - Mailmanclient: 3.3.1 > Changelog: > https://docs.mailman3.org/projects/mailmanclient/en/latest/src/mailmanclien… > Download: https://pypi.org/project/mailmanclient/3.3.1/ > - Django-mailman3: 1.3.3 > Changelog: > https://gitlab.com/mailman/django-mailman3/-/blob/master/README.rst > Download: https://pypi.org/project/django-mailman3/1.3.3 > > Python 3.6+ and Django 2.0+ is supported for all of them. Django 3.0 > support for Hyperkitty requires manually upgrading a dependency > (django-haystack>=3.0b2, once a stable version of this has been released, > it shouldn't require manually upgrading). > > There are tons of bug-fixes across the board and some new features. > > Biggest visible change is switch to Bootstrap 4, which has been long > pending for us. Bootstrap 4 completely changes the CSS grid model using the > new Flexbox. There might be some small changes or breakages when using on > mobile. Please report such issues to us via Gitlab! > > Some other notable changes are in Postorius, which includes many more list > settings exposed include content filtering settings, bounce processing > (which was added in the previous release of Mailman Core) settings and some > other ones. Settings page is also slightly different with all the sections > on the vertical menu on left instead of horizontal tabs. You can now also > specify a reason when rejecting held messages. > > There was also a gnarly bug, which caused the name of some members to be > the string "None". For the longest time, I couldn't figure out the reason > for it, but it ended up being a simple fix in mailmanclient's json > serialization of display_name, which would result in Python's None value > being passed as string "None" to Mailman's API for subscription. > > There is also better support for filtering visible lists based on the > current vhost, which I see a few people are already waiting for from > mailman-users list. > > A full changelog has been added to each project in the top. > -- > thanks, > Abhilash Raj (maxking) > _______________________________________________ > 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/ >

6 years

Mailman-users search results for query "Postorius"