Search results for "Postorius" - Mailman-users

Re: Upgrading other python packages than the mailman ones in a venv results in dependency conflicts

by Odhiambo Washington

On Mon, Dec 16, 2024 at 1:39 PM Ulf R. <ulf.rapphahn(a)offis.de> wrote: > Hello, > I know this should be the way to upgrade: > https://docs.mailman3.org/en/latest/upgrade-guide.html > I have 3.3.10 installed. > I saw that some python packages are outdated an tried this which install > all outdated packages in a row: > pip list --outdated --format=json | jq '.[].name' | xargs -n1 pip install > -U > One outdated package was django and this part happened: > ------------------------------- > vDownloading Django-5.1.4-py3-none-any.whl (8.3 MB) > Installing collected packages: Django > Attempting uninstall: Django > Found existing installation: Django 4.2.16 > Uninstalling Django-4.2.16: > Successfully uninstalled Django-4.2.16 > ERROR: pip's dependency resolver does not currently take into account all > the packages that are installed. This behaviour is the source of the > following dependency conflicts. > hyperkitty 1.3.12 requires django<5.1,>=4.2, but you have django 5.1.4 > which is incompatible. > mailman-web 0.0.9 requires django<4.3,>=4.0, but you have django 5.1.4 > which is incompatible. > postorius 1.3.13 requires django<5.1,>=4.2, but you have django 5.1.4 > which is incompatible. > django-mailman3 1.3.15 requires django<5.1,>=4.2, but you have django > 5.1.4 which is incompatible. > Successfully installed Django-5.1.4 > ------------------------------- > > So I made a roll back. > > Is this really the only secure way to update the venv?: > pip install -U mailman postorius django-mailman3 hyperkitty mailman-web > Correct! > May be yes and I have to ignore the rest? ;-) > Yes. Let them pull their own versions of dependencies. -- 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]

8 months

Re: Listing/Exporting member list error: Mailman REST API not available. Please start Mailman core.

by Daniel Armengod

Can confirm the problem is reproducible on mailman 3.3.0 installed via PIP. Postorius hangs on exporting CSV subscribers [1] (~6k in this case), with error "Mailman REST API not available. Please start Mailman core" (which is otherwise running fine). mailman3.log also shows WORKER TIMEOUT log entry, exactly the same as OP's message. > You can add a new |gunicorn.cfg| next to your |mailman.cfg| and add > the additional options. For further reference if anyone reads this thread, see [2]. I had to look that up to figure out where the file name "gunicorn.cfg" came from. It's not immediately obvious to the reader why a file named "guincorn.cfg" should be specially interpreted by mailman3. The suggested fix - increasing timeout of worker process - did work perfectly for me. Thanks :) Regards, Daniel [1] http://www.<redacted>.org/postorius/lists/<redacted>/csv_view/ [2] https://mailman.readthedocs.io/en/latest/src/mailman/runners/docs/rest.html…

5 years, 5 months

Re: How to store additional information about lists?

by Stephen J. Turnbull

Andreas Barth writes: > Not sure if this is the right approach, or if it wouldn't be more > appropriate to "just" replace the dependency on allauth in postorius, > and do all the magic in the frontend only (because that's where people > actually subscribe). If it's purely a matter of managing subscriptions by individual users, that's the path of least resistance, I think. I would not be surprised if there are things you don't actually need, but you'd need to implement so that Postorius doesn't blow up if some IMember feature you haven't implemented gets accessed. If in the future you might have an external personnel database with other stuff in it, and you want Mailman automatically synced to that, then IMember now might make sense to avoid technical debt in the future. But I don't know enough about IMember or your use case at the moment to make a useful recommendation. Steve

4 years, 2 months

Re: Template's encoding setup

by Mark Sapiro

On 9/15/19 3:33 AM, Ugnius S wrote: > > This noticed only on HTML text messages. If message comes in HTML the > header does not add extra <enter> new line, new paragraph > and footer as well. For example if message body has no additional, list's > decorated message looks next: > > TEST HEADER > _____________________Hello, > > text text text, pictures, text > > regards > Ugnius____________________ > TEST FOOTER > > I have tried to add more empty lines in "The footer for a regular > (non-digest) message.", but mailman removes these empty lines. > Work around is put dot "." and then several empty lines. The stripping of leading whitespace from templates created in Postorius is <https://gitlab.com/mailman/postorius/issues/301> to be fixed by <https://gitlab.com/mailman/postorius/merge_requests/434> > Mark, I have found Your post about HTML headers and footers: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… > YES, that works good, I have tested it, but only in cases if message comes > in HTML. If sender sends plain text message, > mailman adds footer with all HTML code: > > <BR>__________________<BR> > <B> LIST NAME </B> > > Could it be possible that decorate.py would recognise message and if it > has HTML text body, then just would add header/footer and if not (if > message body is plain text) , then would strip header/footer "html to plain > text" may removing html code from it? As it says in the post you reference: message and digest footers and headers are always added either to a MIME text/plain message body or as separate MIME text/plain parts. HTML tags will just be displayed as plain text and will not be rendered as HTML. Also see <https://wiki.list.org/x/4030707>. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 11 months

Postorius Suggestion: Give owner a view of all users of all owned lists

by Stephen J. Turnbull

Andreas Vetter writes: > it would be real great if owners that own several lists, but are > not superusers, can see all users of all *their* lists and manage > them. A down-"selected" version of the superusers view. > Would that be possible? Possible, yes. I don't know how to do it well enough to add to our distribution. Note that owners can't actually manage users -- that really does need to be a superuser. Owners can manage subscriptions to the lists they own. So first we'd want to create a new "Subscriptions" item for the top menu; the "Users" item isn't appropriate. I'm not sure who that item should be visible to. Most likely only owners, because individuals already have ways to see all their subscriptions, and it's not obvious they would want the same presentation as your superowners. Then you'd iterate over the logged-in owner's lists and collect all of the subscriptions. I guess you'd want them to be organized by address rather than by list. By User is out, I think -- owners can't normally see Users, and I'm unhappy abou the privacy implications of being able to correlate nole(a)alset.com with head(a)dodgy.gov in general, although I realize it's not a problem in your setting. Without a more complete specification of what your users need, and the presentation they'd want to see, I personally am unwilling to go farther than those comments. Maybe one of the other devs feels differently. Also, "domain owner" is way under-implemented currently. For the hierarchical situation you outline, all the problems go away for domain owners. Of course then you'd need to split out lists by domain, but to me that's a small cost to preserve sanity in the structure. Steve

5 months

Re: Moderate mails from owner

by Abhilash Raj

On Thu, Mar 21, 2019, at 8:47 AM, Malcolm Austen wrote: > On Wed, 20 Mar 2019 18:42:10 -0000, Mark Sapiro <mark(a)msapiro.net> wrote: > > > However, this is apparently not relevant because both the Member and > > Non-Member actions are Hold. Thus, the post should be held unless it has > > an Approved: header with the list's moderator_password attribute if > > there is one, or it matches a Header filter rule with an accept action. > > At the risk of getting this really wrong - I have only limited MM3 > knowledge - I will ask what is, I fancy, a closely related question ... > > My only experience of MM3 is with Ancestry's 'RootsWeb' installation. From > the emails I can see a header "X-Mailman-Version: 3.1.0" but I can't find > anything to identify Postorius which is the only interface I have to the > system. > > From symptoms seen and described by others, I have deduced that the > Postorius admin-per-user moderation options of "Default processing" and > "List default" mean that a user may be set (by default on the rootsweb > system!) to use the system default moderation settings rather than the > list default settings. "Default Processing" means the default pipeline defined in List > Settings > Alter Messages > 'Pipeline' ( in the bottom). This pipeline is system wide and is defined in source code, so it can't be customized by site administrator. > > Are my deductions correct? And if so, could this be the explanation of the > issue detailed in this thread? > > Apologies if I'm barking up entirely the wrong tree, Malcolm. > > -- > Malcolm Austen <malcolm.austen(a)weald.org.uk> > _______________________________________________ > 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, 4 months

Re: Chinese characters in list name shows question mark (?)

by Franklin Weng

Franklin Weng 於 2019/10/24 上午8:05 寫道: > Hi Mark, > > Thanks for your reply. > > Mark Sapiro 於 2019/10/24 上午6:10 寫道: >>> Is there any other setting I should look at? >> The list's preferred_language setting (Postorius -> Settings -> List >> Identity -> Preferred Language. The list welcome message is encoded in >> Mailman's character set for the list's preferred_language. If this is >> English (USA), the character set is us-ascii. If it is set to Chinese >> (Taiwan), the character set is utf-8, and it should work. > However in my settings -> List Identity page I didn't see Preferred > Language option. > > https://nextcloud.slat.org/index.php/s/45tGaE7ALgAFQFK > > What may be possible wrong that I couldn't see Preferred Language > settings in the web interface? I got it. It is implemented in postorius 1.2.5 but my Debian buster contains 1.2.4-1 for now. Franklin

5 years, 9 months

Re: Changelog and/or Release Notes

by Brian Carpenter

On 11/28/19 1:12 PM, Abhilash Raj wrote: > > On Thu, Nov 28, 2019, at 10:08 AM, Brian Carpenter wrote: >> Now that I am using Mailman 3.3, where can I find the release notes >> and/or changelog for core, postorius and hyperkitty under Mailman 3.3? > Each individual projects maintain their own change logs: > > https://hyperkitty.readthedocs.io/en/latest/news.html#id1 > https://postorius.readthedocs.io/en/latest/news.html#id1 > https://mailman.readthedocs.io/en/latest/src/mailman/docs/NEWS.html#tom-saw… > > >> Thanks! >> Brian >> _______________________________________________ >> 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 and for all of your hard work maintaining those docker containers! -- Please let me know if you need further assistance. Thank you for your business. We appreciate our clients. Brian Carpenter EMWD.com -- EMWD's Knowledgebase: https://clientarea.emwd.com/index.php/knowledgebase EMWD's Community Forums http://discourse.emwd.com/

5 years, 8 months

Re: Changing subscription address

by Abhilash Raj

> On Mar 18, 2021, at 8:29 PM, Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > > Thank you for your comments, Allan! > > Allan Hansen writes: > >> On 3/15/21, 21:28 , "Stephen J. Turnbull" <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > >>> In the 'Mailman Settings' screen, List-based Preferences' tab, > >> You may mean the 'Subscriptions' tab. > > I did mean the 'List-Based Preferences' tab. The 'Subscriptions' tab > is non-functional. It's in some sense aesthetically more pleasing > than 'List-Based Preferences', but you have to do extra, unnecessary > work to get anything done from the 'Subscriptions' tab. It may make > sense to just get rid of the current 'Subscriptions' tab and rename > 'List-based Preferences' to 'Subscriptions'. +1 We can do that. I don’t think I’ve ever used the subscriptions tab myself to do anything. > > The only functionality of 'Subscriptions' over 'List-based > Preferences' is that it lists you once for each role and address > (member, non-member, moderator, owner) that you have for that list. > This is possibly more confusing than helpful for non-owners. > Moderators get informed of their role every time they need to do > something. And it's possible to be both a member and a non-member of > a list, which is pretty confusing. Yeah, technically you can be subscribed to a list with all possible roles at the same time. > >> Under 'User profile for <name>', under the 'E-mail Addresses', add >> button to ensure that 'Primary E-mail' is used for all lists. > > If you define "ensure" strictly, this would be a fair amount of work > because it would require overriding the normal "cascade" of > preferences, and incidentally a way to turn off that override. I'd > rather not make the implementation so complicated. > > There does need to be a way to revert each option to inherit, and > there currently doesn't seem to be one. The 'Preferences' interface I > described in the previous post doesn't provide it either. I will > think about that. The implementation of this isn’t very difficult, but the UX of this is something I don’t know how to implement in that page to be very honest. > It should be normally unnecessary to use the 'Preferences' interface, > because the default subscription should be "use primary address". For > people using the current versions of Mailman 3, who are already have a > bunch of subscriptions with the same *explicit* address, I think it is > good enough. But if there's demand for a "revert all to use primary > address" button, that would be easy enough to add. We do already have ability to switch from an explicit address to Primary Address subscription. I would imagine it would be more than just a button, but more like a dropdown to choose an email or primary address and switch all subscriptions to that. > Here's why I think such a button would be unnecessary in future > versions of Mailman. What should happen if you subscribe by an > address not already known to Mailman without creating an account in > Postorius is > > 1. Mailman registers the address. > 2. Mailman creates a User object to "own" that address, and makes > that address the primary address for the User. > 3. Mailman creates a subscription which links the User (not the > address) to the mailing list so that the primary address is used. > > For addresses already known to Mailman, Mailman should look up the > User registered to that address, and if the subscription address is > the primary address, set "use primary address" for the subscription. This is how Core actually does work[1] if you subscribe via Email and you already have a primary address. It will lookup a user using the address and if the address is the primary address of the user, it will subscribe the primary address. However, if it isn’t the primary address, and this is a new address, it will subscribe the address instead of user because the address isn’t verified at this point and hence can’t be a primary address. We could extend the subscription workflow to add an additional step to set this address as primary and subscribe the primary address. Postorius has the full ability to define its own workflow because REST API provides full expression capability and doesn’t enforce anything. Previous versions didn’t had support for subscribing as Primary Address, but that has since changed and is the default one in the dropdown. This is for authenticated subscription, the anonymous subscribe works similar to email -join command. Mass-subscribe is probably working the same way. [1]: https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/commands/eml_m… > > In this scheme, as far as I can see, your user doesn't need to do > anything with the account until she wants to change the address. At > that point she needs to activate the account: > > - visit her personal options page in Postorius > - request a password reset (she doesn't have one yet, so she can't log > in) > - click the special link > - set a password or link a social media account, and > - finally change the address. > > Note that this is the bare minimum of work for her. She has to prove > she can read mail at that address. Anything less, and *anybody* can > change her subscriptions. We could omit requiring a new password, > but it's not a lot of work once you've got to this point, while the > "request, wait for email, click link, do work" dance is pretty > annoying. Why make someone do it again next time? > > This is problematic if she's already lost access to the old address, > of course, but in that case you're probably going to have to intervene > anyway. > > I don't think Postorius requires her to do anything else, but if she > wants to she can update her profile at that point. > > I have to check the code, and probably also ask Barry and the other > folks who designed the current subscription mechanism in case there's > some fatal flaw in the scheme above. But I think that should do what > almost all "one address" users want, and it's probably what the > majority of people who have multiple addresses and use different ones > for different purposes want most of the time, too. Like mentioned above, it should be possible to do what you suggest. I am getting into the implementation details here, but the Subscription workflow would need an additional flag that would verify an address and use the flag to determine if it should subscribe the address or addresses’s user if an address is provided to the workflow. > > Note to self of possible problems: (1) The primary address is where > you would send administrative mail to the account holder and that > might not be an appropriate address for the default subscription. > (2) This is a pretty radical change from the current situation, so it > might need to be an option for the list or domain owner. > >> And, indeed, new subscriptions should default to 'Use Primary.' > > I agree. I'm astonished that there are situations where they don't, > to be quite honest. That's the whole point of having accounts in the > first place -- having *one* source of information about the user > rather than spreading it out over a bunch of lists. > >> Is that possible now? > > It is already the default for someone who subscribes by logging in to > Postorius. I assume that it is *not* the default for someone who > subscribes by email or mass subscription, otherwise you wouldn't have > the problem. > >> Does a member have to have an account for me to set it up thus for >> them? > > Yes. The primary address is an attribute of the account. > Subscriptions can't know anything about a primary address unless there > is an account. However, it should be possible to make this default > for an account that hasn't been activated yet, such as in a mass > subscription. Primary Address is also an attribute of the Mailman User, so it should be possible for an admin to set that for a user if the user doesn’t have an account. When they sign up, they’d be able to manage and update accordingly. I have started working on designing a User management page[2] in Core which should make it easy for superuser to manage several things about a User, including the ones that don’t have an account in Postorius to manage their own. The list os “tasks” an admin can do isn’t decided, but please feel free to write comments there about things you’d like to be able to do as a server admin. [2]: https://gitlab.com/mailman/postorius/-/merge_requests/605 > > Regards, > 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, 4 months

Re: Postorius fails to show list because of a large message being held

by Mark Sapiro

On 7/14/20 3:54 AM, Brian Carpenter wrote: > On 7/14/20 6:49 AM, Gilles Filippini wrote: >> Mailman Core logs: >> [2020-07-14 10:41:21 +0000] [36] [CRITICAL] WORKER TIMEOUT (pid:49) >> [2020-07-14 10:41:21 +0000] [49] [INFO] Worker exiting (pid: 49) >> [2020-07-14 10:41:22 +0000] [50] [INFO] Booting worker with pid: 50 > > I am pretty sure that timeout is related to gunicorn. If it is, then > increasing the worker out timeout setting for gunicorn should work. You > tend to get such errors when doing an export of a large membership > roster. This is the first time I have seen it related to a held message. It seems weird that a gunicorn worker would run for more that the default 30 seconds because of a 23MB message, but I think Brian is correct. > I have this in my setup: > > mailman.cfg: > > [webservice] > configuration: /opt/mailman/mm/gunicorn.cfg > > gunicorn.cfg: > > [gunicorn] > workers = 4 > timeout = 900 > > You will need to restart gunicorn after adjusting the timeout setting. It's confusing, but after adjusting that setting, you need to restart Mailman core, not gunicorn. If you are running a gunicorn service, that is what is providing WSGI support for Django (Postorius and/or HyperKitty). You may be using gunicorn for this or uWSGI or Apache mod_wsgi, but is any case, that is not the gunicorn we are considering here. Regardless of what you use to provide WSGI support for Django, Mailman core uses gunicorn to support the REST API, and that is the gunicorn affected by the settings in the gunicorn.cfg pointed to by [webservice] configuration: /opt/mailman/mm/gunicorn.cfg If, with the above configuration, you do `ps -fwwA|grep runner=rest` you will see something like: mailman 20582 20561 0 01:21 ? 00:00:16 /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 mailman 20722 20582 0 01:21 ? 00:01:19 /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 mailman 20725 20582 0 01:21 ? 00:01:18 /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 mailman 20726 20582 0 01:21 ? 00:01:18 /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 mailman 20727 20582 0 01:21 ? 00:01:50 /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 The first of these, pid 20582, is Mailman's actual REST runner. The other 4 with parent pid 20582 are the 4 gunicorn worker processes forked from the REST runner. It's the REST runner or Mailman core that needs to be restarted to pick up that change. -- 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

Mailman-users search results for query "Postorius"