Search results for "sapiro" - lists.mailman3.org

[MM3-users] Re: Problems with shunted Mails

by Stephan Krinetzki

Mark Sapiro wrote: > On 4/20/22 02:00, Stephan Krinetzki wrote: > > Mark Sapiro wrote: > > You might be able to fix this with something like > > for mbr in m.regular_members.members: > > ... if mbr.address is None: > > ... mbr.address = mbr.user.preferred_address or > > member.user.addresses[0] > > ... > > commit() > > This fix didn't worked. It returned a "Index out of bounds" exception. > > Apparently these Users have no associated Addresses at all. Do you have > any idea how these Users got created/subscribed to the list? Unfortunately not. We only see the result.

3 years, 1 month

[MM3-users] Re: Social signup?

by Mark Sapiro

Duane Raymond wrote: > Wow - thanks for the redirection on where to patch it and the first-cut > code. I'll look into this in 2 weeks when I am able to focus on it. I have submitted https://gitlab.com/mailman/django-mailman3/-/merge_requests/198 for this. It is currently a draft because I'm looking for feedback on the specific wording.

2 years, 2 months

[MM3-users] Re: Alleviating confusion regarding"Subscription options" that are left unselected.

by Mark Sapiro

I have committed https://gitlab.com/mailman/postorius/-/merge_requests/812 to add the note to the user's list options page.

2 years

[MM3-users] Re: Where to put static files referred to from list Info page?

by Greg Newby

On Tue, Aug 6, 2024 at 9:25 AM Mark Sapiro <mark(a)msapiro.net> wrote: > Mark Sapiro wrote: > > You could put them in Mailman's static/ directory and reference them > > with a /static/... URL. > > One caveat: if you run the mailman post-update command, it contains > > mailman-web collectstatic --clear --noinput --verbosity 0 > > and the --clear option will remove your added files. You could have > backups somewhere and copy them back after. > I'm glad you mentioned this. Thanks! ~ Greg

10 months, 2 weeks

[MM3-users] Re: anomalous behavior

by Donato Molino

On Saturday 05 October 2024, alle 11:07, Mark Sapiro wrote: > On 10/5/24 11:01, Mark Sapiro wrote: > > > > Is there anything relevant in mailman.log? Are there messages in > > Mailman's shunt queue?. The fact that the message is archived means the > > issue is either in mailman/handlers/to_outgoing.py or > > mailman/runners/outgoing.py Great Mark! They were the permissions of /var/lib/mailman3/templates/lists I changed them from root:root to list:list and now work perfectly A thousand thanks Donato

8 months, 2 weeks

[MM3-users] Re: possible backscatter attack using Mailman3 servers

by Mark Sapiro

David Newman wrote: > > I have made this change. As for not having web accounts, this just means > new users cannot sign up to manage their Mailman settings, correct? I > presume existing web accounts will continue to work. That's correct.

5 months, 2 weeks

[MM3-users] Re: The paradox of VERP probe messages

by Jeremy Stanley

On 2025-01-29 19:26:30 -0000 (-0000), Mark Sapiro wrote: > Mark Sapiro wrote: > > > > You could submit an issue at > > https://gitlab.com/mailman/mailman/-/issues/new to make this configurable. > > I did this. See https://gitlab.com/mailman/mailman/-/issues/1195 Thanks! I would have been happy to file it, just hadn't gotten a free moment yet. -- Jeremy Stanley

4 months, 2 weeks

[Test] Re: mailman-users@mailman3.org

by Mark Sapiro

On 04/05/2016 09:09 AM, Simon Hanna wrote: > There are a couple of issues that would be nice to fix first. Most of them have merge requests > pending with fixes that I think are ready for merging. I agree it would be 'nice' to have everything fixed first, but we've been promising this list since last year and it's time to eat our own dog food. > Postorius: > > https://gitlab.com/mailman/postorius/issues/70 > All non ascii input shows up garbled upon saving in postorius. > The fix is in mailmanclient and I have a mr pending: > https://gitlab.com/mailman/mailmanclient/merge_requests/10 > > > https://gitlab.com/mailman/postorius/issues/93 > Isn't really a bug, but it looks weird and has a merge request pending > > > This one doesn't affect users (admins only) but already has a merge request: > https://gitlab.com/mailman/postorius/issues/117 I have the patch from this MR installed. > https://gitlab.com/mailman/postorius/issues/20 > Not important if all lists will have public archives, otherwise this should be fixed first It will have public archives. > And Hyperkitty: > > https://gitlab.com/mailman/hyperkitty/issues/23 > This will affect users, the bug has a merge request pending I've patched this one too. > https://gitlab.com/mailman/hyperkitty/issues/76 > Just found it, shouldn't be caused by normal navigation though so it's not that important > > https://gitlab.com/mailman/hyperkitty/issues/29 > It's a nasty bug but we can live without fixing it for now Yes, and I've looked into it some per my comments on the issue, but we'll live with it. > https://gitlab.com/mailman/hyperkitty/issues/65 > It's not important if all lists that are created are sent an email immediately There is an archive. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

9 years, 2 months

[MM3-users] Re: What is result of planned MM3 integrated installation at Pycon?

by Mark Sapiro

On 6/9/18 5:11 PM, Tom Browder wrote: > > Thanks, Mark. Will the release be pretty much a one-step affair for us > older folks without much energy? Probably not, but it depends at least in part on what you are currently running. There is a major change in that everything is now Python 3. This means that you now must run Django under Python 3 which probably entails changes to how the web server runs wsgi apps to support Python 3. Also, You can run Django versions 1.11.x, or 2.0.x, but Django 2.0.x requires you make changes to the Django config as in this diff. > --- a/mailman-suite_project/settings.py > +++ b/mailman-suite_project/settings.py > @@ -94,13 +94,12 @@ INSTALLED_APPS = ( > ) > > > -MIDDLEWARE_CLASSES = ( > +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.auth.middleware.SessionAuthenticationMiddleware', > 'django.contrib.messages.middleware.MessageMiddleware', > 'django.middleware.clickjacking.XFrameOptionsMiddleware', > 'django.middleware.security.SecurityMiddleware', > --- a/mailman-suite_project/urls.py> +++ b/mailman-suite_project/urls.py > @@ -19,7 +19,7 @@ > > from django.conf.urls import include, url > from django.contrib import admin > -from django.core.urlresolvers import reverse_lazy > +from django.urls import reverse_lazy > from django.views.generic import RedirectView > > urlpatterns = [ > @@ -31,5 +31,5 @@ urlpatterns = [ > url(r'', include('django_mailman3.urls')), > url(r'^accounts/', include('allauth.urls')), > # Django admin > - url(r'^admin/', include(admin.site.urls)), > + url(r'^admin/', admin.site.urls), > ] I.e., the name MIDDLEWARE_CLASSES is changed to MIDDLEWARE and the obsolete django.contrib.auth.middleware.SessionAuthenticationMiddleware has to be removed; the reverse_lazy import is changed and include(admin.site.urls) becomes just admin.site.urls -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years

[MM3-users] Re: non-members issue with held email

by Mark Sapiro

On 7/20/21 2:09 AM, Lars Schimmer wrote: > > We created a new mailinglist, added 3 owner and several members. > Now we want some email addresses to post to that list but not receive > mails from the list. So I added those to the "non-member" area of the > mailinglist and checked every non-member to "acceppt at once". > > But on a test, a email address, which is owner AND non-member, cannot > send to mailinglist, always get a "HOLD: ...... The message is not from > a list member" See https://gitlab.com/mailman/mailman/-/issues/659 If you read through the comment thread, you'll see that the issue is when setting moderation action for an address which is both an owner and a nonmember, it is the owner's action that actually gets set, so that the nonmember's action remains set to list default. You need to set the moderation action for the nonmember via `mailman shell`. If all the non-members are the ones you added, you can do ``` $ mailman shell -l your.list.id Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. The variable 'm' is the ... mailing list >>> for nonmember in m.nonmembers.members: ... nonmember.moderation_action = Action.accept ... >>> commit() ``` If there are other nonmembers whose action you don't want to set to accept, you need to do something like ``` >>> emails = ['first(a)example.com', 'second(a)example.com', <more emails>, ] >>> for nonmember in m.nonmembers.members: ... if nonmember.address.email in emails: ... nonmember.moderation_action = Action.accept ... >>> commit() ``` to only do the ones you want. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 11 months

Search results for query "sapiro"