Search results for "Postorius" - Mailman-users

Re: Mailman3 throws 500 error (unicode encode) when loading held messages in Postorius

by Stephen J. Turnbull

Simon Handfield via Mailman-users writes: > I have been able to identify a file in the shunt queue that threw a > matching error when I performed mailman qfile on it. > I have run a loop over all remaining files in the shunt queue and > all the remaining files can be accessed by mailman qfile without > error. Good. But there are still a bunch of problems with those files since they got shunted. > I moved this file out of the queue in the hope that I would then be > able to load the held_messages page successfully. Unfortunately I > am still seeing a 500 error on loading the page. If this is a Mailman problem, I don't understand it. The shunt queue is not the moderation queue. The shunt queue is for messages that Mailman cannot handle without throwing an exception. Once a message is sent to the shunt queue, Mailman ignores it, so it shouldn't cause problems for the moderation page. Have you tried restarting Mailman since moving the qfile? If that doesn't work, and if it's the same error message and traceback, the easy suspect is browser caching (although we should be disabling that, I hope). Try a manual refresh (usually Ctrl-R or in the menu). If that doesn't work, try a private browsing window or another browser if you don't want to clear the cache or restart the browser. > I temporarily reenabled debug logging to confirm that the same > error was being thrown. > > Assuming that file was the cause are there other steps I need to > perform in addition to removing the file from the shunt queue > directory? The only one I can think of is the check for browser-side caching. Unfortunately, Mark's out of town (like, on top of a mountain with no bars on his phone), and I am not going to be able to do much with this until Thursday at the earliest. If you do get a new traceback, post it here (somebody else may have an idea). If you like you may send me the qfile at the address in From. I'll see if I can reproduce the bug, and I'm pretty sure I can tell you what's in the file so at least you'll know whether it's important to somebody who isn't a scammer/spammer. Steve

4 years, 11 months

Re: {Spam?} Server name in new account confirmation email

by Meehan, John

Thanks for your replies. From Mark's reply, and looking at django_allauth, the Subject of the confirmation email uses the site name from the django_site db table in brackets, but the URL in the message body comes from the HTTP header. Adding proxy_set_header Host $http_host before the proxy_pass line on the SSL proxy server solved the problem. ________________________________ From: Mark Sapiro <mark(a)msapiro.net> Sent: Thursday, December 3, 2020 10:25 AM To: mailman-users(a)mailman3.org <mailman-users(a)mailman3.org> Subject: [MM3-users] Re: {Spam?} Server name in new account confirmation email On 12/3/20 9:26 AM, Meehan, John wrote: > Hi, when someone creates a new account (Sign Up), an email is sent to them to confirm their email address. It has the form below. Does anyone know how I can Caution (External, mark(a)msapiro.net<mailto:mark@msapiro.net>) Sensitive Content, First-Time Sender Details<https://shared.outlook.inky.com/details?id=Y29tbXNjb3BlL2pvaG4ubWVlaGFuQGNv…> Report This Email<https://shared.outlook.inky.com/report?id=Y29tbXNjb3BlL2pvaG4ubWVlaGFuQGNvb…> FAQ<https://www.inky.com/banner-faq/> Protection by INKY<https://www.inky.com> On 12/3/20 9:26 AM, Meehan, John wrote: > Hi, when someone creates a new account (Sign Up), an email is sent to them to confirm their email address. It has the form below. Does anyone know how I can change the server name in the URL (From server.example.com to something else)? I have an SSL proxy server that I want to direct users through. Thanks. - John This message comes from django_allauth. The domains come from the django_site database table. If you have Postorius >= 1.3.3 The Domains view will show you the SITE_ID for the domain and has an `Edit` link the the Django admin UI entry for that site. Otherwise, you can go to the Django admin `Sites` view and see the DOMAIN NAME and DISPLAY NAME for each defined site, and you can edit the domain name. You may also need to adjust the SITE_ID setting in your Django settings to match the site you want. The trick here is the SITE_IDs aren't displayed in the Django admin UI or in Postorius < 1.3.3, and they may not be sequential or start at 1. If you query the database with `SELECT * FROM django_site;` you'll see entries with columns id, domain and name which will tell you the SITE_ID. -- 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://secure-web.cisco.com/1FBkrl8Fna83jeBpMzhcS-TGdx6ALOyBwi0uCPsqGDtm9J…

4 years, 8 months

Re: Changing subscription address

by Stephen J. Turnbull

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'. 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. > 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. 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. 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. 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. 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. Regards, Steve

4 years, 4 months

Re: Changing subscription address

by Abhilash Raj

> On Mar 22, 2021, at 7:53 AM, Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > > Abhilash Raj writes: > >> Well a couple of stars have to align for it to work unfortunately. > > I'm not going to wait for the stars; I have backward-incompatible > surgery in mind. > >> Add to that you can’t set an address as primary using just email >> commands, you end up with what you are seeing. > > Right. The idea is that the first time an address is used, a User > will be created and that address will be primary for that User. When > the person wants to claim that address, they go to Postorius, create a > Postorius account, do the address verification dance and set > credentials, which links the Postorius account to the User via the > Address. > > This is why the ability to merge Users becomes an urgent need: people > who subscribe via email are going to end up with multiple Users. Well, it doesn’t change the situation much from status quo. You also have multiple users today, even if you subscribe via individual address since an address always has a User. And like we were discussing over on the other thread, when the owner decides to join in P and control both the addresses from single P account, we’ll merge both users. > >> We don’t necessarily need the flag on user to set an unverified primary >> address, we might be able to get away without that. We could set the >> address as primary *after* we verify it. We always verify addresses >> regardless of the choice of the subscription mode (user or address). > > I'm not clear what you're saying. In general admins can't read your > mail, so they can't verify you on a mass subscribe or an import. What I meant was, we can set the address as primary after the verification dance with the user and then subscribe the primary address. The existing subscription workflow is a multi-step process that can be paused and resumed. We pause when we send out a confirmation email and then resume when that confirmation token is somehow processed via email or API. So, post receiving the confirmation and before actually subscribing, we can se the address as primary if the user doesn’t have one and subscribe user as inhert. We don’t do any of that if user already has chosen a primary address and it doesn’t match the current address. Also, mass-subscribe and import does allow you to verify an address by clicking this “Pre-verified” checkbox, which can be useful if you are migrating from a different service or you exported a list of users from somewhere you know to be valid. > >> Right now, P is explicit about it. You can choose if you want Primary >> Address or one of the explicit addresses added to your account. The >> primary address is the pre-selected choice, so if you go and just click >> on subscribe button, you get the primary address being subscribed. If >> you choose the explicit address then we subscribe the explicit address. >> >> Is that something you think needs modifying? > > No. The option to set a subscription to the literal primary address > should still be available. I don't see a good reason to complicate > the UI logic by comparing primary to literal addresses just to remove > that one. I just want the primary address to be populated > automatically, and inherit-from-primary be the default subscription > address when the subscription address matches primary, *unless* the > subscriber explicitly chooses that literal address in Postorius. > > This is backward-incompatible, but I think it will be overwhelmingly > popular with new users and old. There would be no behavioral change for users using email commands. For those using P, I think will be able to manage and switch rather easily. > >> The email join command does the first part you suggested, (if the lookup >> succeed and matches primary address, use inherit) but doesn’t do the >> second part (it will create a user, add the address to it and then use the >> address to subscribe). We can and should fix that. > > I think that's all we need to do going forward. > > We do need a better UI for setting options (including address) for a > selection of subscriptions, but that's an independent task. > > Thanks for looking at this, Abhilash! Of course :) > > Steve -- thanks, Abhilash Raj (maxking)

4 years, 4 months

Re: REST API Question: possible to change user preferred email?

by Abhilash Raj

On Fri, Mar 15, 2019, at 10:59 AM, Nathan Dixon wrote: > Hi, > We are in need of being able to change a user's email address via the REST > API. After looking through the documentation and code, I can't see a way to > do this in a simple way. > > Although the documentation seems to show that if a user changes their > preferred address, it will track throughout all their subscriptions. It depends on how are you actually using Mailman. Postorius today subscribes people using their addresses, so the method you mentioned below is the correct way to change addresses. If you think you are going to do this more frequently, you could subscribe users with their user_ids and then when you need to change their memberships, you just update their preferred_address. See [1] here for how to join a mailing list using user_ids. Note that this isn't available today using Postorius (our Web UI), but I'd be happy to work with you if you want to contribute it. [1]: https://mailman.readthedocs.io/en/latest/src/mailman/rest/docs/membership.h… > > See: > https://gitlab.com/mailman/mailman/blob/master/src/mailman/rest/docs/member… > "When Gwen changes her preferred address, her subscription automatically > tracks the new address." > > The only way I can see to do this via the REST API would be to do the > following long winded way: > > *1. Create a new address:* > POST to http://<api_url>/3.1/users/<$OldEmail>/addresses > $postData: {email = "$NewEmail"} > > *2. Verify the new address:* > POST to http://<api_url>/3.1/addresses/<$NewEmail>/verify > $postData: { } > > *3. Get all the memberships for the old email address* > $memberships = GET to http://<api_url>/3.1/addresses/<$OldEmail>/memberships > > *4. Change users email for each membership individually* > foreach ($membership in $memberships) { > PATCH to http://<api_url>/3.1/members/<$membership.member_id> > $pathData: { address = $NewEmail } > } > > *5. Delete Old Address* > DELETE to http://<api_url>/3.1/addresses/<$OldEmail> > > Am I missing something (as in there is a way to do a single PATCH request > somewhere)? Or is this the only way to update someone's email address with > these 5 steps? > > Thanks, > Nathan Dixon > _______________________________________________ > 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: Emergency moderation and clearing out a lot of held messages

by Stephen J. Turnbull

Caballero, Danny (Dan) writes: > I don't understand. We have a single database configured for > everything. I don't recall reading anything in the set-up > documentation about using more than 1 database for Mailman3. I was trying to help localize the database request to one of the three major components: core, Postorius, HyperKitty. If you use the two- database scheme documented here: https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-inst… knowing that database would at least identify whether the slowness is associated with core or with the web apps. The excruciating details: Conceptually, there are three separate databases: the one used by Mailman core to manage everything but authentication and archives, the one used by Django to manage authentication for HyperKitty and Postorius, and the one used by HyperKitty to manage archives. They don't share tables, and there are no name collisions for the tables so it doesn't really matter how the backend handles them. The two database configuration is not really a recommendation. I suppose the practice derives from an abundance of caution, as there are concepts like "User" that must be implemented in somewhat different ways across components (core doesn't authenticate users, while Postorius's primary function is authentication of users). I myself would worry that there might be name collisions among tables, which would cause mayhem, but that's probably excessive.

2 years, 9 months

MM3 error on moderation request

by Odhiambo Washington

MM3 - 3.3.10, Postorius 1.3.13. After receiving the notification to attend to a moderation request: ``` At your convenience, visit https://mm3-lists.kictanet.or.ke/mm/lists/kictanet.lists.kictanet.or.ke/hel… to approve or deny the request(s). ``` Upon visiting the link I ended up with a server error. mailmanweb.log has the below to say: ``` [ERROR] [2024-10-10 12:29:15,905] [log] 809040 139858772735552 Internal Server Error: /mm/lists/kictanet.lists.kictanet.or.ke/held_messages Traceback (most recent call last): File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/defaulttags.py", line 1026, in find_library return parser.libraries[name] ~~~~~~~~~~~~~~~~^^^^^^ KeyError: 'humanize' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/core/handlers/exception.py", line 55, in inner response = get_response(request) ^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/core/handlers/base.py", line 197, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/contrib/auth/decorators.py", line 23, in _wrapper_view return view_func(request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/postorius/auth/decorators.py", line 63, in wrapper return fn(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/postorius/views/list.py", line 889, in list_moderation return render(request, 'postorius/lists/held_messages.html', context) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/shortcuts.py", line 24, in render content = loader.render_to_string(template_name, context, request, using=using) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/loader.py", line 61, in render_to_string template = get_template(template_name, using=using) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/loader.py", line 15, in get_template return engine.get_template(template_name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/backends/django.py", line 33, in get_template return Template(self.engine.get_template(template_name), self) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/engine.py", line 175, in get_template template, origin = self.find_template(template_name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/engine.py", line 157, in find_template template = loader.get_template(name, skip=skip) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/loaders/cached.py", line 57, in get_template template = super().get_template(template_name, skip) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/loaders/base.py", line 28, in get_template return Template( ^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/base.py", line 154, in __init__ self.nodelist = self.compile_nodelist() ^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/base.py", line 200, in compile_nodelist return parser.parse() ^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/base.py", line 513, in parse raise self.error(token, e) File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/base.py", line 511, in parse compiled_result = compile_func(self, token) ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/loader_tags.py", line 293, in do_extends nodelist = parser.parse() ^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/base.py", line 513, in parse raise self.error(token, e) File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/base.py", line 511, in parse compiled_result = compile_func(self, token) ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/defaulttags.py", line 1088, in load lib = find_library(parser, name) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/django/template/defaulttags.py", line 1028, in find_library raise TemplateSyntaxError( django.template.exceptions.TemplateSyntaxError: 'humanize' is not a registered tag library. Must be one of: account admin_list admin_modify admin_urls allauth bootstrap_tags cache compress d_gravatar date_helpers debugger_tags decorate gravatar highlight highlighting hk_generic hk_haystack i18n indent_text l10n log markdown membership_helpers more_like_this nav_helpers p_gravatar pagination postorius_helpers rest_framework socialaccount static syntax_color tz widont [WARNING] [2024-10-10 12:29:16,384] [log] 809040 139858704070336 Not Found: /mc/compose ``` How to fix? -- 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]

10 months, 1 week

Re: Issues with @gmail.com addresses

by Mark Sapiro

On 9/5/23 12:59, Mohsen Masoudfar wrote: > Hi, > > since 8/1/2023 I get complains from users with @gmail.com addresses, that they are not getting any emails. > I checked the logs and I see that the emails are going out: > > to=<xxxx(a)gmail.com>, relay=email-smtp.us-east-1.amazonaws.com[35.169.171.20]:587, delay=0.46, delays=0.03/0.06/0.13/0.24, dsn=2.0.0, status=sent (250 Ok xxx ) > > But it seems the users are getting email delivered to them. > I’ve advised them to check their spam, promotions, and social folders and to add the list address to their email safe-senders lists, but still no success. > Is there any way to help this list members? Even though gmail publishes a DMARC policy of none, it has recently started enforcing a stricter policy for mail From: the gmail.com domain. You need to apply DMARC mitigations to mail From: the gmail.com domain. There are two ways to do this. One way is to set DMARC Mitigations -> DMARC Mitigate unconditionally to Yes (and set DMARC mitigation action appropriately) The other way requires upgrading Postorius and Mailman core to the heads of the GitLab branches (core=3.3.9b1, postorius=1.3.9b1). Doing this enables a DMARC Addresses setting which can be set to `^.*(a)gmail\.com$` to apply DMARC mitigatations to mail From: the gmail.com domain regardless of it's published policy. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 11 months

Rolling releases for Container Images and Funding Campaign for Mailman

by Abhilash Raj

Hi Everyone, As you all know I have been working on container images for Mailman 3. We now have a new "rolling" tag for both mailman-core and mailman-web images. These images have latest source installed for every Mailman component. You can find more information about them on the website [3]. New images are available on quay.io and, moving forward, the rest of the image builds will also be moved to Quay[4][5]. These images are built using git-heads *only* if they are passing our test suite and are re-generated weekly. You should be aware that while all these components are tested with their individual test suites, their combination might sometimes not be stable. This will get you updates/bug-fixes much faster :) As most of you already know, Mailman 3 is the new and improved version with extra features, better security and much better architecture. We released Mailman Suite 3.0 in April 2015 and have come a long ways since then. Mailman Suite 3.1, release May 2016, was aimed to provide feature-parity with Mailman 2.x series and we think we _almost_ hit that goal. Apart from no monthly password reminders, Mailman 3 has a much better Administrator/User interface, REST API for scripting, a really awesome archiver, support for multiple domains, support for external plugins, support for SSO/social login and so much more! I love working on Mailman and would enjoy being able to do so full time for next 6-8 weeks. Mailman 3 is not very far from becoming the default version everyone would use, but it still needs some work to get there. I need help from you, the users of Mailman, to get us there. If you or your organization would like to move to (or, already moved to) Mailman 3, I urge you to donate[1] to us. There are options to donate using Credit Card, Paypal, Bitcoin, Wire Transfer (of any currency), Check and money order. If this campaign succeeds, here is a road map of what I intend to get done: - Move Django apps(UI/Archiver) to Python 3 (or bilingual) - Fork `mailman import` command to provide an upgrade path to Mailman 3.x from Mailman 2.x - Fix MySQL compatibility in Core - Changes in Postorius: - Add support for missing options that are already exposed in Core’s API - e.g. Support for setting templates - Find the commonly used options that are not exposed in Core, add them to Core's API and add to Postorius - Add Admin Dashboard project from GSoC 2014 (maybe?) - Add better testing of container images and provide deployment instructions for Kubernetes & Docker Swarm - Improve the container images to work with new micro-services architecture, to achieve scaling and redundancy in services. - Administrator/User documentation for Postorius & Mailman - (optional) Fork [mmcli](https://github.com/rajeevs1992/mailmancli) project from Rajeev, fix if there is anything missing and add it as an additional command line tool to work with Mailman Core. Maybe pull it under Mailman umbrella. Except for these, if there is something more important that is preventing the adoption of Mailman 3 from your end, we can discuss them. I'd like to mention that I have been working on Mailman 3 for quite some time now and I intend to implement every single item on the list. You donations would help it get done much sooner, hopefully in time for 3.2 release schedule (at PyCon US 2018). You can follow the progress of this campaign here[2]. [1]: https://my.fsf.org/civicrm/contribute/transact?reset=1&id=22 [2]: https://wiki.list.org/x/17892025 [3]: https://asynchronous.in/docker-mailman/#rolling-releases [4]: https://quay.io/repository/maxking/mailman-web [5]: https://quay.io/repository/maxking/mailman-core -- Abhilash Raj maxking(a)asynchronous.in

7 years, 9 months

Re: Mailman3 is wrongly display name a list member

by Mark Sapiro

On 1/11/22 9:24 AM, Allan Hansen wrote: > Thank youi, Stephen. > > Oops. When I wrote below that I set the name 'B' in the account, I did describe it wrongly. Sorry. > The member just wants one name, 'A' for all her subsriptions. Somehow the 'B' got into the system when we upgraded from Mailman 2 to Mailman 3. > > I removed the address from all the lists, set the account display name to 'A' in Django, verified that she was not subscribed to any list at all, and then resubscribed her again as 'A'. In other words, no 'B' anywhere - straight 'A's. > Nevertheless, the new subscriptions still show up as 'B'. A user has a user record and one or more address records. Each of these has a display name. Removing users from lists does not remove these records. If you have recent Postorius, you should have a `users` item at the top of Postorius pages. Go there, find the user and click "Manage". You can change Display Name there. Otherwise, in `mailman shell` for example ``` >>> usr = getUtility(IUserManager).get_user('user(a)example.com') >>> usr.display_name = 'First Last' >>> for adr in usr.addresses: ... adr.display_name = 'First Last' ... >>> commit() ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 7 months

Mailman-users search results for query "Postorius"