Search results for "Postorius" - Mailman-users

Re: Error when click on mailing list: An error occurred while processing your request.

by Mark Sapiro

On 7/14/24 21:40, adam.heathcote(a)utas.edu.au wrote: > Hi Mark, > > Sorry about the delay in replying. > > You're correct, I am clicking on the list in the Mailing List view. > > Navigating to the list URL directly while not logged in produces the same error and even produces the error when a different user is logged in. Now it's my turn to apologize. I've been traveling. In your original post you wrote "I've tried removing it and reimporting it to no avail." What exactly does this mean. You removed the list how? Then you reran the import21. Was the list broken at that point, or only after removing the old owners and adding yourself? What if you try the following steps in order and try to view the list in Postorius after each step. - remove the list with `mailman remove list(a)example.com` and recreate it with `mailman create list(a)example.com` - run `mailman import21 list(a)example.com path/to/config.pck` - in Postorius, add yourself as owner. - in Postorius, delete one of the other owners. - repeat the deletion and viewing the list for the other unwanted owners one at a time. If the view throws the error at some point, after which step? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 10 months

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

by Andreas Vetter

Stephen, after thinking a lot about it, I came up with this. Stephen J. Turnbull wrote: > Andreas Vetter writes: > > A list of all addresses subscribed to all lists owned by the logged > > in person. > > This is starting to take a better form. It's still very specialized, > so I'm starting to wonder if trying to add it to Postorius is a great > idea. Of course if people are coming in over the network, you don't > want to reproduce all the authentication and authorization logic > implemented in Django and Postorius. That may as well be done in > Django, and if you're doing Django it may as well be Postorius too. > > But if you're in a single sign-on environment so presence in the > network implies strong authentication, you will get more flexibility > from local scripts using mailmanclient, or if you're confident in > security access to the REST API directly. Just putting that out for > your consideration, since implementing what is taking shape here would > take quite some time as the folks skilled with Postorius are not so > active these days. I agree, this is very special. In our case we will cook it down to a very special solution providing owners with the info they need. Based on that, they can use the unchanged postorius for (un-)subscribing. > > Owner is the primary target group for that. But since it should be > > a tool for managing subscriptions in a simple way, it might also be > > of interest for superusers. For me as a superuser it would make > > life easier. > > [...] > > > Ah, I see the problem and agree: So, the presentation should have a > > sorted and searchable list of addresses and a Button next to each > > address, maybe labeled "Subscriptions". > > Looking at your description above, for superusers that is basically > the Users tab, though. Users are identified by primary address, and > you'd not see alternate addresses in the list. But presumably your > internal users use their @your.org addresses as primary. Can you make > clear what could be more streamlined for your use cases as superuser? > I give one example below, maybe that's what you're mostly interested > in. > > The caveats about access to User objects still apply for owners, so > even if they look the same (which is a good UX idea if owner > functionality is a subset of superuser functionality, also they might > even be able to share the basic page templates), the implementation is > going to be rather different. I suspect you superusers would be quite > frustrated if using the "subscribe all these lists" functionality > meant you couldn't get at the User object without going to a different > page. > > I do see one weird thing: you can't manipulate subscription itself > from the User page as seen by the superuser from that list, only > toggle moderation and delivery mode. I guess that's reasonable for a > lot of use cases, though. I've never wanted to do a subscribe or > unsubscribe from there. I always have a long list of users to > subscribe to specific lists, never a list of lists a specific user > should belong to, We have a list for almost every working group and have scripts reading members from there and putting them together in the higher level lists. People can be in more than one working group list. Users come, stay some years and go, so mass (un-)subscription is used for single addresses usually. But if the owner forgets to delete someone from a list, the person is still in one of the higher "automatic" lists. So an overview would have been nice. The "(un-)subscribe all" buttons are not really needed in our use case. We run about 300 lists. For a superuser this is a lot, given the fact there is no filtering in the table of lists. A owner wants to see in an address view all his lists. A superuser does not, because it would be too much unrelevant information (e.g all 200 research lists, when user is in finance). As a superuser I could need in the users view: - clicking on a list name to manage the list - unsubscribe button > > The presentation given when above "Subscriptions" Button is clicked > > should contain the address as kind of Headline. Then a table of > > all lists of the logged in owner and next to each mailing list an > > indication, if the address is subscribed or not and a Button to > > toggle subscription/unsubscription. May be a single Toggle Button > > or (maybe better) two buttons, a suscribe and a unsubscribe button, > > where one is greyed out. > > This would not work with the current User page as presented to a > superuser, that's true. The current presentation is quite suited to > its purpose, with sections for Addresses, Subscriptions, Ownership, > and Delete User in that order. But especially for superusers, there > are plenty of sites with thousands, even tens of thousands of lists, > and even a paged or scrollable presentation would be awful UI, and the > potential for a disastrous mistake using "do all" is high. I agree. So I think superusers "users view" and owners "addresses view" should be different things. > > In addition my owners would like to have a "unsubscribe from all my > > lists" button. And a "subscribe to all my lists" button. This might > > be visually nicer, when having the two-button approach above. > > I wonder if your owners really want "subscribe all". "Unsubscribe > all" does make sense for separations, of course, and they wouldn't > necessarily be terminations. It would be useful in an internal > transfer where "delete user" is not a solution. But in my experience > specialized channels tend to proliferate but the same people are > likely to be running them as run the department-wide lisst. Yes, "subscribe all" is usually not wanted, I just mentioned it for symmetry. Since we populate higher lists with members from lower lists by script, we would not strictly need "unsubscribe all" as long as the owner knows which lists are populated automatic. We currently hide that info in the short description of the list. Everything very special, I agree. > > In our case we would want to (un-)subscribe the address in a "do > > it, don't ask anyone" fashion, but maybe this is not a good idea in > > general. What do you think? > > I think we would implement it similarly to the mass subscribe for > multiple addresses case, where the list owner can decide how much > bureaucracy to require of the subscriber. You'd want to be careful to > make sure address verification is done at most once (for your use > case, probably not at all). And there would be some things that could > be done to arrange that most lists would have sensible defaults. Yes, this is and was a problem for us. We imported many lists from mailman2. Some settings have to be changed after migration, and a mailman config command to set settings for lists would be great. Or a way to permanently create new list styles. > > Yes, I agree, but policy here is to get rid of subdomains, and that > > falls on our feet now. > > Well, once we figure out how to implement domain ownership, it > wouldn't be hard to adapt that technology to "departments" that are > administratively distinct but share mail and/or web domains. The main > problem would be deciding whether and how to nest them. Superuser > > domain owner > list owner > moderator is pretty obvious, but how > "department owner" would fit in is less so. I already had this wo possibilities here (at different times): In fact a department owner could own several domains. The department research (as opposed to e.g. administration) could contain biology.example.org and physics.example.org) Would it harm to be owner of several domains? Or it could be the other way round (physics.uni.edu has a theory department and an experiment department, each having chairs with the list owners). So there is no single way. Department owner and domain owner seem to be roles on the same level with different funcionality. Superuser has to decide how to use it. -- Mit freundlichen Gruessen, Andreas Vetter

1 year, 3 months

Re: Postorius claims 2 messages held when there are none - out of sync

by Ken Alker

--On Monday, June 26, 2023 5:26 PM -0700 Mark Sapiro <mark(a)msapiro.net> wrote: > On 6/26/23 4:19 PM, Ken Alker wrote: >> >> What else is stored in /var/messages, if not archives? I see 4711 >> messages in that directory (which I presume would be as many messages >> are in the archive database). If there is a write-up on this, feel >> free to point me to it. I found >> <https://docs.mailman3.org/projects/mailman/en/latest/build/lib/mailman/ >> model/docs/messagestore.html> but this isn't really answering my >> question. > > > These are probably artifacts from your old Debian package. There have > been issues in the past with handled messages not being removed from the > message store. See https://gitlab.com/mailman/mailman/-/issues/257 > > This was fixed in 3.3.5 and the task runner implemented in 3.3.5 removes > orphaned messages from the message store, but if they are still > referenced in pendings they won't be deleted. So is the only thing stored in var/messages/ the held messages, and nothing more? Is there an outline as to how to clean up the var/messages hierarchy? (I assume one has to be careful not to remove current held messages and maybe old ones that have not been processed; or maybe "old ones" can all be assumed orphaned, and thus, removed w/o concern?)

2 years, 11 months

Re: sqlite3 Database "read only" error on mailman_sync job

by Abhilash Raj

On Wed, Sep 4, 2019, at 2:05 PM, Ugnius S wrote: > > I have installed using documentation. My linux distribution version has no full package available. I have installed step by step: > $ sudo pip3 install mailman > $ sudo pip3 install postorius > $ sudo pip3 install hyperkitty > $ sudo pip3 install mailman-hyperkitty > And of course all mandatory components... Everything without errors, I can drop db files and I can download mailman-suite again and start from empty page again. But it will not guarantee that DB will not become READ ONLY again. Here should be logic. No developing support here? Could you be running two separate processes such that the database is locked by one and so other finds it as READ Only? When you find a read only database, can you check if it is open in some other process? > > > > 2019-09-03, an, 19:36 Abhilash Raj <maxking(a)asynchronous.in> rašė: >> >> >> On Sun, Sep 1, 2019, at 3:22 AM,ugniusviln(a)gmail.com wrote: >> > Hi. All the project installation is under the same user / path and >> > it works. Archiving working as well, (just one remark: no matter what >> > to set in postorius, hyperkitty shows list as public) >> > I have found work around - it is possible to change list as private in >> > "admin" page. >> > I started to get issues with runjobs after I have created couple of >> > new lists with "no archive" option. >> >> How did you install all these components. It seems there the installation is broken in weird ways. >> >> > >> > If as owner user from project home I run: >> > >> > django-admin mailman_sync >> > >> > Traceback (most recent call last): >> > File >> > "/home/user/.local/lib/python3.5/site-packages/django/db/backends/utils.py", >> > line 84, in _execute >> > return self.cursor.execute(sql, params) >> > File >> > "/home/user/.local/lib/python3.5/site-packages/django/db/backends/sqlite3/base.py", >> > line 383, in execute >> > return Database.Cursor.execute(self, query, params) >> > sqlite3.OperationalError: attempt to write a readonly database >> > >> > "django-admin runjob sync_mailman " - makes read only errors as well. >> > "django-admin runjob new_lists_from_mailman" >> > django.db.utils.OperationalError: attempt to write a readonly database >> > END TRACEBACK >> > >> > I did not find information how to fix this. It was worked without errors >> > before. >> > I noticed, that if I stop mailman, "django-admin mailman_sync" starts >> > to work. >> > If I start "mailman start", then "django-admin mailman_sync" failing >> > again. >> > I did not check other jobs, but I think what is related to database, >> > will get errors. >> > Seems mailman locking the database. It is not a file permissions issue. >> > Mailman db location is: /project_directory/var/data/mailman.db >> > >> > if to rename /project_directory/var/data/mailman.db to something, >> > mailman creates database file size 0, django-admin runjobs start >> > working, but of course postorius stops working. I did it for testing. >> > I have returned this database file back, postorius started to work >> > again, but django-admin runjobs does not work, error: "database read >> > only". >> > Please help me how to fix this issue. >> > _______________________________________________ >> > 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) -- thanks, Abhilash Raj (maxking)

6 years, 9 months

Re: How to set up mailman 3

by Mark Sapiro

On 03/25/2017 04:55 PM, Mark Sapiro wrote: > > A list's message_size can't currently be set in Postorius. File an issue > at <https://gitlab.com/mailman/postorius/issues/new>. Actually the attribute name is max_message_size, not message_size. It exists in core and can be set, e.g., from the command line via 'mailman shell', but it needs to be exposed in Postorius. -- 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

Re: Help request, almost got it going, but ....

by Mark Sapiro

On 09/01/2017 02:33 PM, Claus-Justus Heine via Mailman-users wrote: > > Seemingly, at some point in the deep dungeons of the source code the > "Acceptable aliases" Text-Box is not interpreted correctly. > > Specifically, at the start it contains the string > > [] See <https://gitlab.com/mailman/postorius/issues/58>. In order to set things on this page, you need to clear the Acceptable aliases box before submitting changes. You can't actually set Acceptable aliases via Postorius until this is fixed. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 9 months

Displaying new lists in Hyperkitty (Re: "Private archives" aren't private)

by Simon Liebold

> settings in postorius are not reflected in hyperkitty. That's not yet fixed, or is it? Am 28.07.2017 um 10:55 schrieb cyp(a)trojina.si: > but "mlist_object.update_from_mailman()" works. So luckily we have a workaround, thanks. I am unsure where/how to use this workaround. Can anyone explain how I get Hyperkitty to display (and archive for) new lists created via Postorius. Simon

8 years, 8 months

Django logins for new subscribers

by Alex McLean

Hi all, I'm moving our groups to mailman3 (http://we.lurk.org) Enjoying it so far! I've mass-subscribed people via postorius. However the subscribers don't have django (postorius/hyperkitty) logins. It seems they only exist on the mailman side, not the django side. If they go through the process of creating an account in postorius, they can configure their mailing list subscriptions, but this is a bit fiddly. Is this expected behaviour? It would be great if they could be sent a temporary link to set a password and go. Best wishes, alex

8 years, 5 months

setup of URLs

by Peter Münster

Hi, I would like to point "https://my-domain.org/" to the list of mailing-lists of this domain. How should I setup my Apache configuration and/or the urlpatterns please? With my actual configuration, the above URL is always rewritten to https://my-domain.org/postorius/lists/ These are my urlpatterns: urlpatterns = [ url(r'^$', RedirectView.as_view( url=reverse_lazy('list_index'), permanent=True)), url(r'^postorius/', include('postorius.urls')), url(r'^archive/', include('hyperkitty.urls')), url(r'', include('django_mailman3.urls')), url(r'^accounts/', include('allauth.urls')), url(r'^admin/', include(admin.site.urls)), ] TIA for any help, -- Peter

8 years, 4 months

Re: List description as sender

by Mark Sapiro

On 9/25/18 3:34 AM, Henrik Rasmussen wrote: > Yes, but even the Settings -> Alter Messages -> Anonymous list is set to No, the 'anonymous_list': is still True. It works for me with Postorius 1.2.2. Settings -> Alter Messages -> Anonymous list follows changes I make to the list's anonymous_list in core and core follows changes I make in Postorius. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 8 months

Mailman-users search results for query "Postorius"