Search results for "Postorius" - Mailman-users

Disabling the version disclosure.

by ninad＠iitb.ac.in

Dear All, I recently installed Mailman3. I am new to MM3. As per my organization's policy, I need to turn off the version disclosure of Mailman Core, Postorius, and Hyperkitty. Specifically shown in the footer and in the system information page. Please let me know if there are any settings that I can set. I don't want to change any html code for the same. Please guide me in this regard.

10 months

Re: Moderator e-mails only going out once a day

by jkoral＠luc.edu

Mark, can you clarify the part about (Postorius Admin immed notify is Yes)? Is that a separate setting than admin_immed_notify is True? If so , how do I check that setting.

10 months

Re: Mailman appears to send an email to a closed list, from a member who was removed from that list

by Andy Matthews

Ah, we're not using Postorius, just the API. I see that you can get details about the email via the command line though, so that might work.

6 months, 1 week

Re: Column 'starting_email_id' cannot be null

by kroerig＠web.de

On Debian Django-admin is wrapped with /usr/share/mailman3-web/manage.py But /usr/share/mailman3-web/manage.py makemigrations && /usr/share/mailman3-web/manage.py migrate only reports: Operations to perform: Apply all migrations: account, admin, auth, contenttypes, django_mailman3, django_q, hyperkitty, postorius, sessions, sites, socialaccount Running migrations: No migrations to apply.

5 months, 1 week

Re: Spam from non list members

by Sam Darwin

You configured postfix/exim directly to do rspamd filtering, or you configured mailman to do it? If the latter case (mailman), is it possible that affects acceptance logic? What if you remove rspamd and spam detection from the pipeline? [ that is mere speculation though ] Have you installed the latest versions of mm3, postorius, hyperkitty?

5 months, 1 week

Question: as Admin, I disabled the self-registration via settings.py. What is the correct method to register a few new users now?

by Wikinaut

Disabled by line ACCOUNT_ADAPTER = 'django_mailman3.views.user_adapter.DisableSignupAdapter' (via https://gitlab.com/mailman/django-mailman3/-/merge_requests/129 ) When I want to register a few new users, I need to comment this line and restart mailmanweb. Question: is there a better method for admins to register a few new persons to Hyperkitty/Postorius so that they can act as owners and moderators of some of the lists?

4 months, 3 weeks

Re: After server upgrade debian 11→12 and reinstalling everything in (venv), I got this error when accessing → mailman3/lists

by Wikinaut

Do you have a programmatic way to delete n ( n > 20) such entries in Postorius, e.g. via a python script + REST to loop through all lists and perhaps to exclude a few based on a small condition (like a text found in old template and/or list name)? This would be very helpful.

4 months

Disabling Mass operations

by iMark

Hi All, Can anyone give me a pointer on disabling "Mass operations" (subscribe/removal) in Postorius. Just removing the menu link from the list-owners administration pages would be a good start. On "list-by-list" would be brilliant, but even server-wide would do the job. Cheers, Mark

4 days, 2 hours

Re: Some doc updates from Fedora install experience

by tlhackque

On 26-Jun-17 15:31, Abhilash Raj wrote: > Excerpts from tlhackque--- via Mailman-users's message of June 24, > 2017 4:21 am: >> I had to read code to discover that the web UI (Postorious) server >> address doesn't exist in any config file. > > That is True, there is no stright forward way for Mailman Core to know > who is > using the API and where is the Web UI working. I *think* "Web Host" is > used to > generate emails, but that can't always be completely accurate because > there is > no easy way to know what is the "root" url for Postorius and > Hyperkitty. Generally, the default configurations place it at > "/postorius/" and > "/hyperkitty/", but there are installations where it is placed at > "/mailman3/" > and "/archives/". > It would be helpful for API users to "register" with Mailman, so that API clients can figure out how to direct users to their web pages. There has to be a directory somewhere, and Mailman is the central character. It doesn't have to be one place. Perhaps something like "get( '/lists/config/admin_ui') and get('/lists/config/subscriber_ui") - which could return something like: [ {"type":"gui", "name":"postorius", "uri":"https://www.example.net/mailman3/"}, {"type":"cli","name":"mailmanclient","uri":"domain://my.socket.example.net:1234"},{"type":"gui","name":"mailmanx","uri":"file:///usr/sbin/mailman-Tk"}, ...] (Where the order indicates preference). Speaking of which, without this knowledge, how can Mailman provide the personalized "to unsubscribe, visit your account at "...." customizations"? I see that there are URLs for headers/footers, but we seem to have lost the ability to insert the URL for the GUI managing your list/account into personalized e-mails... >> >> To bind it to something other than localhost, you put the desired ip >> address & port on the >> >> `python manage.py runserver` command line (in mailman-suite_project. > > Ok, so you should never use this in production. AGREEED > This command starts a > "development" server which is only supposed to be used in the development > environment. My development environment is a VM for Mailman, and other VMs for the mail server. And if I try to run a web browser on the Mailman VM, it takes over the machine and even so is unresponsive. So I needed to make the UI visible on the network where my PC is. I do understand the issues, and there are firewalls protecting the environment. > For any production use, in general for any python web app, we use a > wsgi server which interfaces between Django and a "real" web server > like Nginx > or Apache. I would recommend using uwsgi. This[1] and [2] might be of > help. > AGREE. I know that I will have to do this eventually. But my immediate goal is to see if it's possible to get my application talking to Mailman V3 - it's a 1-user environment. So I needed an evaluation environment with the absolute minimum setup costs. If things work out, I'll do the right thing. If not, I can't afford to have spent a week or so untangling nested webservers talking to each-other with frameworks, a half-dozen passwords and config files. This was the quickest path I could find to an 'almost out-of-the-box' evaluation and prototyping environment...and pretty much the only "step-by-step" instructions that I could find. I'd have tried "step-by-step" for production if (a) I could find it and (b) I could configure it with less than a couple of days of study :-( I decided to document this in case it helps someone else. I strongly agree that it's not production, and not for all users. > There is some configuration over here[3] that might help you get it > running. You > would have to change some parameters in the configuration though. > >> >> It must be an IP address - it doesn't resolve DNS names. The port is >> appended to the IP address with a ':'. >> >> So, in venv 2.7 >> `cd mailman-suite_project && python manage.py runserver >> 10.0.0.11:8000` will work. >> >> There are all sorts of issues if your network is at all public, but >> in my >> case, a multi-machine walled garden, with no local web browser, it >> allowed >> bootstrapping to continue. > > It is not supposed to be public and should only be used for development. > Agree, agree, agree. >> >> The runserver command also takes --ipv6 (or -6) to bind to an IPv6 >> address, >> --nothreading and --noreload also exist (but i haven't tracked down >> whethere >> they're useful') > > There are a whole lot of other optins available to `python manage.py` > command > which you can find in the documentation for Django. Truth be told, I had no idea that 'runserver" had anything to do with Django. I was just following instructions to get something out of the box and onto the wire. FWIW, 'python manage.py --help' and 'python manage.py help runserver' are semi-intructive. I still have no clue what an "auto-reloader" is, but the help does say that --noreload won't use it :-) It's clear that a lot of work has gone into this release -- but it's also quite frustrating for people who just want to explore using it to get through the setup effort. I've made some progress. > -- > thanks, > Abhilash Raj

8 years, 7 months

Re: Confusing mailman user model

by Gilles Filippini

Gilles Filippini a écrit le 19/07/2020 à 19:10 : > Gilles Filippini a écrit le 19/07/2020 à 18:00 : >> Mark Sapiro a écrit le 19/07/2020 à 17:30 : >>> On 7/19/20 8:10 AM, Gilles Filippini wrote: >>>> Hi, >>>> >>>> I'm trying to understand the Mailman user model, and I'm confused about >>>> the respective roles of tables 'auth_user' and 'user'. >>> >>> >>> auth_user is a Django auth table. These are the users listed in the >>> Django admin web UI. >>> >>> user is Mailman core's users. >>> >>> >>>> Both have an 'id' column referred to as 'user_id' when used as a foreign >>>> key. But there seems to be no relation at all between them as they use >>>> different ids for the same user. >>> >>> >>> Right, they are unrelated. >>> >>> >>>> Our mailman server was migrated from mailman2 to mailman3 about 1.5 year >>>> ago, and there is an inconsistency I'd like to fix: >>>> 2 of our users have a registered Mailman account with their respective >>>> email addresses in table 'auth_user', but these very same addresses in >>>> the 'address' table are linked to another old admin account in the >>>> 'user' table. >>> >>> Their Mailman account is the 'old' one. the auth_user account is a >>> Django account >>>> >>>> Then if add one of these addresses as a domain owner, it it the old >>>> admin address which is selected instead. How could I fix that? >>> >>> >>> That's because domain owner in a Mailman thing and involvs the Mailman >>> user. You could delete the Django users via the Django admin UI and then >>> re-register them via Postorius. That *might* work. >> >> When login into postorius, it is the Django account that is used, right? >> Then how is the mailman account retrieved from there? It seems UUIDs are >> used in the process, but I fail understanding how, so far. Wouldn't it >> be safe to retrieve the new Mailman account associated to these Django >> users, and link there emails from 'address' table' to them? > > Reading the mailman-web source code I understand now that the mailman > account is retrieved from the Django account email address. Then both > users are tied to the same old mailman admin account, and deleting then > registering them again won't change anything on this aspect. > > Would this work? > 1- For both addresses, update their record in table 'address' to set > 'user_id' to null > 2- On their next login to Mailman-web, a new mailman account would be > created and associated with their own email address. Done that, and it worked. Thanks, _g.

5 years, 6 months

Mailman-users search results for query "Postorius"