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.
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,
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.
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.
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, 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.