Search results for "Postorius" - Mailman-users

Re: Postorius List members

by Alain D D Williams

On Wed, Nov 13, 2024 at 07:10:04PM -0800, Mark Sapiro wrote: > On 11/13/24 19:00, Alain D D Williams wrote: > > > > Is it possible to add delivery status to the summary where many users are > > shown ? I find this (on mailman 2) to be very useful, ie get a quick overview of > > what is happening to users. > > > There is a merge request in process for this. See > https://gitlab.com/mailman/postorius/-/merge_requests/953 Great I look forwards to that -- although since I have installed via Debian packages there will prolly be some delay :-( Thanks -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html #include <std_disclaimer.h>

5 months

add custom styles to postorius list creation menu

by Michael Hazan

Hello, When creating a list via postorius, i can see 3 style appear (announce, discussion, private). Is it possible to either create a new style and add it to that list or modify one of those style ? I’m using the virtual env setup and i have been trying to manipulate via the mailman-web shell but it doesn’t work when adding a new style. I need to delegate list creation to admins and I don’t want them to have to redo every list settings for every list they create when they are the same style. Also, coming from mailman2, you could directly set the members post moderation action when subscribing, now you can only do it via the user menu, is there a way to automate this in mm3 ? Thanks for the help. Michael

2 years, 11 months

Re: Hiding the "subscribe without creating an account"

by Ben Sturmfels

> On 13/07/2024 07:17, Mark Sapiro wrote: > >> On 7/10/24 7:36 PM, Ben Sturmfels via Mailman-users wrote: >>> >>> Is there a configuration option that does this, or was it a custom change >>> made in the templates? Was the change made to reduce fake registrations? Did >>> it work? >> >> It was added in Postorius 1.3.9. See the UI section at >> https://docs.mailman3.org/projects/postorius/en/latest/news.html#news-1-3-9 >> >> Yes, the change was made in an attempt to reduce fake registrations. Thanks very much for the prompt advice Mark and Matthew! Really appreciate it. I'm currently running Postorius 1.3.8 (Debian Stable/Bookworm), so will look at upgrading and applying the settings you suggested. Regards, Ben

9 months

Re: List invisible to moderator

by Mark Sapiro

On 6/16/20 3:43 AM, Olaf Zaplinski via Mailman-users wrote: > I just have promoted a member to a moderator. Now when he logs in to > Postorius, he gets the message "There are currently no mailing lists.". > > I have set "Show list on index page" to "no" before. But as a moderator, > the list should be shown, right? I mean, all lists are shown to the > administrator also. > > When I manually enter the complete URL, the moderator can see the list. > I think this is a bug. Moderators should see their lists. What do you > thing? What Postorius version is this? It works for me in Postorius 1.3.3. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 10 months

add / remove / set moderation bit of non-members via mailman shell

by Zaheer Abbas

I have a situation where I need to add / remove 10-20 non-members to a particular list every week and set the moderation bit to 'accept immediately (bypass other rules). I do the above via postorius because I couldn't find a way to do this via mailman shell. Can anyone help me please to achieve the above? I know how to remove all non-members via /opt/mailman/mm/bin/mailman shell -l list.example.com for nonmember in m.nonmembers.members: ... nonmember.unsubscribe() ... commit() I am just having difficulties adding the non-members and setting the moderation bit to 'Accept' Currently I am using Mailman 3.2.2 (La Villa Strangiato) and Postorius Version 1.2.4 so cant use 'postorius => settings -> message acceptance -> id_accept_these_nonmembers' -- Regards, Zaheer

1 year, 2 months

Re: No DBA password when installing Mailman3 with remote database server

by Stephen J. Turnbull

Markus Ludwig Grandpré writes: > Dpkg allows to skip database configuration. Is there routine or skript > to create database, database user and all required tables after the > installation process has finished? Not the whole thing. The users and databases must be created by a database administrator. After that, any "mailman" command will initialize the core's tables, and the "mailman-web migrate" command creates the Django tables for both Postorius and HyperKitty if mailman-web is installed, or you use the Django "manage.py migrate" command separately in both HyperKitty and Postorius if Debian uses the older installation without mailman-web. After the migrate command, you should use mailman-web or manage.py to issue the collectstatic, compress, and compilemessages commands for HyperKitty and Postorius.

2 years, 5 months

Re: customized welcome message

by Nils

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.

1 year, 4 months

Re: Disable archives per list

by Stephen J. Turnbull

Bernd Wurst writes: > Am 25.02.21 um 22:01 schrieb Mark Sapiro: > > Normally a list admin can select which of the enabled archivers is > > active for that list via Postorius. To prevent this, you would have to > > modify Postorius. It would be easy enough to just remove settings from > > the relevant templates. > > This will take effect for all lists at once, I suppose. :( I'm not familiar with the content of Postorius's templates, but they support all of the Django features, so you can filter out the settings for specific lists. It would require code and database schema changes to make that configurable from Postorius, I think. > Hyperkitty has a rather cool frontend but stores all messages from all > lists together in one database table. Additionally, neither Mailman nor > Hyperkitty seems to know or tell anything about archive sizes of a list. > This is horribly for accounting. Mailman core doesn't know anything about archives except where you've told it to send them. Historical note: I'm not saying it was a good idea, but the folks who designed HyperKitty were aiming at the Fedora use-case. There's a fair amount of cross-posting between Fedora lists, so I think this makes sense for them both from the indexing and from the storage point of view. I doubt they were thinking about the hosting perspective. > So I thought if I can have a separate hyperkitty installation per user > without having to duplicate the whole mailman. You could do that, but it requires a separate port or domain for each. If you're already aliasing a server (or a server farm) for virtual domains, then that's no problem. > Alternatively, I'd like to enable archiving only for some customers > that buy a suitable plan. > I did not really get into mailman plugins. I don't think anybody has gotten into them. > Is is possible for plugins to hook into such settings? Since archiving involves getting the message from Mailman core, yes. Plugins can only deal with that end though. Everything else is controlled by the archiver itself. Without a plugin, you could disable archiving somewhat easily by giving each list a different posting pipeline that doesn't have the 'to-archive' handler in it. This wouldn't stop the list admin from configuring, but ... there wouldn't be any archives there. I don't know if that deserves a smiley. :-/ Unfortunately this would be annoying because you'd have to go in and modify for each list. With a plugin, Mailman core could refuse to configure a archive. However, stock Postorius wouldn't know anything about that. It would just see a "refused" response in the REST protocol, but without modifying Postorius, I suspect it would just log and display an error to the user. And without code changes Postorius can't provide a good UI for that. Steve

4 years, 1 month

Re: Source Installation Assistance

by actionmystique＠gmail.com

I have built python3-django-hyperkitty for Ubuntu/Debian distributions from the gitlab hyperkitty sources with the commit that fixes the issue(266): use an errorless test to determine the existence of the table social_auth_usersocialauth. It passes the test on Ubuntu focal with flying colors: ``` # python3 manage.py makemigrations # python3 manage.py migrate "No changes detected", "Operations to perform:", " Apply all migrations: account, admin, auth, contenttypes, django_mailman3, django_q, hyperkitty, postorius, sessions, sites, socialaccount", "Running migrations:", " Applying contenttypes.0001_initial... OK", " Applying auth.0001_initial... OK", " Applying account.0001_initial... OK", " Applying account.0002_email_max_length... OK", " Applying admin.0001_initial... OK", " Applying admin.0002_logentry_remove_auto_add... OK", " Applying admin.0003_logentry_add_action_flag_choices... OK", " Applying contenttypes.0002_remove_content_type_name... OK", " Applying auth.0002_alter_permission_name_max_length... OK", " Applying auth.0003_alter_user_email_max_length... OK", " Applying auth.0004_alter_user_username_opts... OK", " Applying auth.0005_alter_user_last_login_null... OK", " Applying auth.0006_require_contenttypes_0002... OK", " Applying auth.0007_alter_validators_add_error_messages... OK", " Applying auth.0008_alter_user_username_max_length... OK", " Applying auth.0009_alter_user_last_name_max_length... OK", " Applying auth.0010_alter_group_name_max_length... OK", " Applying auth.0011_update_proxy_permissions... OK", " Applying sites.0001_initial... OK", " Applying django_mailman3.0001_initial... OK", " Applying django_mailman3.0002_maildomain... OK", " Applying django_q.0001_initial... OK", " Applying django_q.0002_auto_20150630_1624... OK", " Applying django_q.0003_auto_20150708_1326... OK", " Applying django_q.0004_auto_20150710_1043... OK", " Applying django_q.0005_auto_20150718_1506... OK", " Applying django_q.0006_auto_20150805_1817... OK", " Applying django_q.0007_ormq... OK", " Applying django_q.0008_auto_20160224_1026... OK", " Applying django_q.0009_auto_20171009_0915... OK", " Applying socialaccount.0001_initial... OK", " Applying socialaccount.0002_token_max_lengths... OK", " Applying socialaccount.0003_extra_data_default_dict... OK", " Applying hyperkitty.0001_initial... OK", " Applying hyperkitty.0002_auto_20150311_0913... OK", " Applying hyperkitty.0003_thread_starting_email... OK", " Applying hyperkitty.0004_archived_date_and_subject... OK", " Applying hyperkitty.0005_MailingList_list_id... OK", " Applying hyperkitty.0006_thread_on_delete... OK", " Applying hyperkitty.0007_allauth_20160808_1604... OK", " Applying hyperkitty.0008_django_mailman3_profile... OK", " Applying hyperkitty.0009_duplicate_persona_users... OK", " Applying hyperkitty.0010_email_sender_name... OK", " Applying hyperkitty.0011_email_parent... OK", " Applying hyperkitty.0012_thread_order_null... OK", " Applying hyperkitty.0013_mailinglist_id_1... OK", " Applying hyperkitty.0014_mailinglist_id_2... OK", " Applying hyperkitty.0015_mailinglist_id_3... OK", " Applying hyperkitty.0016_auto_20180309_0056... OK", " Applying hyperkitty.0017_file_attachments... OK", " Applying hyperkitty.0018_threadcategory_color... OK", " Applying hyperkitty.0019_auto_20190127_null_description... OK", " Applying hyperkitty.0020_auto_20190907_1927... OK", " Applying postorius.0001_initial... OK", " Applying postorius.0002_auto_20160210_0721... OK", " Applying postorius.0003_drop_addressconfirmationprofile... OK", " Applying postorius.0004_create_email_template... OK", " Applying postorius.0005_auto_20180707_1107... OK", " Applying postorius.0006_auto_20180711_1359... OK", " Applying postorius.0007_auto_20180712_0536... OK", " Applying sessions.0001_initial... OK", " Applying sites.0002_alter_domain_unique... OK", " Applying socialaccount.0004_openidnonce_openidstore... OK" ``` Anyone can grab the binary package on my [Ubuntu Focal PPA](https://git.sdxlive.com/PPA/tree/Ubuntu/pool/unstable/p/python3-django… or [Debian Bullseye Repository](https://git.sdxlive.com/DR/tree/Debian/pool/unstable/p/python3-…. python3-django-hyperkitty has been built for the latest Ubuntu & Debian development distributions (focal & bullseye), but it should be possible to use them on earlier distributions since there is no specific dependencies.

5 years, 4 months

Re: Member Issue Discovered

by Brian Carpenter

On 11/5/20 12:20 PM, Stephen J. Turnbull wrote: > Brian Carpenter writes: > > > I think everyone should care that data should be removed when there is > > an expectation that it is being removed. > > I do care, and I agree that everyone should care. > > The difference is that I also think that everyone should care that > data *should not* be removed when there is an expectation that it > *will be retained*, and, therefore, that the base Mailman we > distribute should at least ask before deleting data as a side effect > of some other action. > > I don't see how I can make it plainer than that, so I'm done here. Well I am having the same difficulty. *With your statement here, let me ask you this:* 1. If someone subscribes to a public list, are they being notified that a user account is being created (by Mailman 3 core) as part of the subscription process? 2. When someone unsubscribes from mailing list, are they being notified that their data is being retained when they unsubscribe (by Mailman 3 core)? 3. When someone subscribes to a public list, are they being made aware that there is no way, for them, the subscriber, to remove their user data *except* if they also register an account through Postorius and then proceeds to delete that account along with them unsubscribing from a list? 4. Am I correct to assume when someone unsubscribes from all lists, AND deletes their Postorius/Django account, that all data on them is being removed? So please understand that questions 1-3 are for a scenario of a subscriber that is only subscribing to a SINGLE list and has not registered with Postorius/Django. Question 4 is dealing with someone who has multiple subscriptions AND is also a registered Postorius/Django user. *This is what I believe are valid reasons for an expectation that data being retained:* 1. A subscriber who is NOT a Postorius/Django user but has multiple subscriptions to various lists on the same Mailman 3 instance subscribes from a single list. They should expect their user data to be retained because they still have active subscriptions to other lists. 2. A subscriber who IS a registered Postorius/Django user is subscribed to a single list and unsubscribes from that single list but did NOT delete their Postorius/Django account. 3. A combination of 1&2. All I am requesting is that for single list subscribers who are not registered users of Postorius/Django, to have their user data totally removed when they unsubscribe. I simply fail to see how someone could claim a right to data retention when they unsubscribe from the one list that they were subscribed to. This is important to me because almost all of the list members of the lists that I host fall into this category: single list member who is not a registered user of Affinity/Postorius. > If you need help implementing the "delete everything" policy in > Affinity because of some insufficiency in the REST API, let me know > and I will make sure the REST API allows you to do that. But I'm > pretty sure it's already possible. It has already been done with Affinity and the REST API was sufficient to allow us to do that. Thanks for offering. > _______________________________________________ > 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/ -- Brian Carpenter Harmonylists.com Emwd.com

4 years, 5 months

Mailman-users search results for query "Postorius"