Re: Mailman, etc. upgrade woes and persistent bugs
Steve,
What I mean by per-user permissions is that some transitions, for example bounce-disabled to enabled, should be only possible by someone with appropriate permission to do so -- perhaps the list admin, perhaps someone else, but not just anyone. Another example _could_ be if a user disables themselves then only that user can re-enable them again (though I can see that might not be good).
Of course, you can to some extent group users by role, so 'admin' role is always ok, 'list-owner' role is ok for any action on that list, etc. If you had a 'role' which was 'account-owner' then you can probably code the rule for re-enabling an account disabled by the account owner as "role = admin or role = list-owner or role = account-owner". Whether this needs to be extended to "role=admin or user = guy" (where 'guy' is a named account holder) I don't know... I suspect it would be better if that wasn't done unless it was shown to be necessary, as "here be dragons".
Do you see where I'm at?
In writing this up it occurs to me that being able to see/edit rules such as these, stored in per-list config, would probably be a good thing. Don't know how practical that is though.
Regards,
Ruth
On 16/02/2021 15:29, Stephen J. Turnbull wrote:
Hi, Ruth,
Thanks for the comments. I'll have to think about most of it, but I have one immediate question.
Ruth Ivimey-Cook writes:
On 13/02/2021 16:34, Stephen J. Turnbull wrote:
I don't think separate booleans is a good idea, since they're basically mutually exclusive states[.]
While using one variable makes some sense as you say, it does complicate the allowed state transitions especially when per-user permissions as well as logic are applied to the situation.
I don't understand how "per-user permissions" apply here.
Regards, Steve
-- Software Manager & Engineer Tel: 01223 414180 Blog: http://www.ivimey.org/blog LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/
Ruth Ivimey-Cook writes:
What I mean by per-user permissions is that some transitions, for example bounce-disabled to enabled, should be only possible by someone with appropriate permission to do so
Right. So what you mean is "ok, we have group permissions, and maybe someday there will be a case for ACLs down to arbitrary subsets of the user population," but you don't have a concrete use case for arbitrary ACLs at the moment.
BTW, I'm fine with that. Normally I'd take mere intuition of somebody like Brian (who interacts with large numbers of admins, and probably subscribers too) as a strong argument for at least experimental implementation, but I see anything more complex than the current system as likely to be a huge mess and developer time sink indefinitely, unless we keep it to the minimum necessary feature set.
UI improvements based on the current permissions structure are definitely needed, though.
Do you see where I'm at?
Yes, thank you for replying.
In writing this up it occurs to me that being able to see/edit rules such as these, stored in per-list config, would probably be a good thing. Don't know how practical that is though.
I don't think it's hard at the proof-of-concept level. Eg, just use ACLs and allow arbitrary groups of Mailman User objects. But have you ever used Zope 2? That UI was based on that design, and ended up being a complete disaster. I suspect that's why permission structure is one thing that Barry did not import from Zope. Designing a way to do rules that doesn't end up like something like Zope2 sounds like a monstrously hard problem to me, and probably application-specific. Which is why I'm pushing back on Andreas and Brian -- without a good "rules definition framework", I think it's better to get it pretty close with a minimal number of moving parts.
Regards, Steve
- Stephen J. Turnbull (turnbull.stephen.fw@u.tsukuba.ac.jp) [210217 09:54]:
Ruth Ivimey-Cook writes:
What I mean by per-user permissions is that some transitions, for example bounce-disabled to enabled, should be only possible by someone with appropriate permission to do so
Right. So what you mean is "ok, we have group permissions, and maybe someday there will be a case for ACLs down to arbitrary subsets of the user population," but you don't have a concrete use case for arbitrary ACLs at the moment.
BTW, I'm fine with that. Normally I'd take mere intuition of somebody like Brian (who interacts with large numbers of admins, and probably subscribers too) as a strong argument for at least experimental implementation, but I see anything more complex than the current system as likely to be a huge mess and developer time sink indefinitely, unless we keep it to the minimum necessary feature set.
I definitly have a usecase for that, but: currently other priorities :) (I had to do an ad-hoc takeover of lots of infrastructure in my spare time within an volunteer organisation including mailing lists, so getting wishlist itmes done is not my top priority at the moment.)
Just from the top of my head, for example I want to differentiate between private, member and public lists. So if a member logs in, they see more lists than a non-member. This is currently not possible, not too big a deal (all member lists are currently configured as private) but of course would be nice. Also archiv access should be aligned with these permissions.
So, if/when I start working on it, I would try to incorporate upstream whatever makes sense, and that includes discussing the concepts early here. Of course the appropriate split between private changes and public changes is also something which might need some discussions.
Andi
On 2/17/21 6:52 AM, Andreas Barth wrote:
Just from the top of my head, for example I want to differentiate between private, member and public lists. So if a member logs in, they see more lists than a non-member. This is currently not possible, not too big a deal (all member lists are currently configured as private) but of course would be nice. Also archiv access should be aligned with these permissions.
What I have done with Affinity is design everything around roles. Roles are List Owner, Moderator, and List Member. So when a registered user logs in they will see:
All their lists that they have a role in and an icon assigned to each role that they play. Those lists are shown at top.
Below their lists associations, public lists are shown. These they do not have a associations with for the logged in user.
Here is an image in what I am referring to:
https://www.mailmanhost.com/wp-content/uploads/2021/02/Screenshot_2021-02-17...
Is the above image what you are thinking about? If it is then I do think that is possible with Postorius with some customization.
-- Brian Carpenter Harmonylists.com Emwd.com
Andreas Barth writes:
- Stephen J. Turnbull (turnbull.stephen.fw@u.tsukuba.ac.jp) [210217 09:54]:
Right. So what you mean is "ok, we have group permissions, and maybe someday there will be a case for ACLs down to arbitrary subsets of the user population," but you don't have a concrete use case for arbitrary ACLs at the moment.
I definitly have a usecase for that, but: currently other priorities :) (I had to do an ad-hoc takeover of lots of infrastructure in my spare time within an volunteer organisation including mailing lists, so getting wishlist itmes done is not my top priority at the moment.)
Just from the top of my head, for example I want to differentiate between private, member and public lists. So if a member logs in, they see more lists than a non-member. This is currently not possible, not too big a deal (all member lists are currently configured as private) but of course would be nice. Also archiv access should be aligned with these permissions.
This would not be worth doing with generic ACLs from Postorius, unless the list had (many) fewer than 100 users. What I'd end up doing (and I bet you would too) is write a 15-line mailmancli script that extracted membership information and then created the ACLs. But you'd still have to modify the Django templates, I suspect, and perhaps database schema.
Essentially the same 15 lines could be put into Mailman itself without ACLs, and checking ACL membership is not going to be much, if at all, faster than checking list membership.
Of course the appropriate split between private changes and public changes is also something which might need some discussions.
Not sure what you mean by private and public here, but if you mean which changes we should maintain and which changes you should maintain locally, I haven't seen anything in this thread that we wouldn't want to offer all Mailman 3 users. From Abhilash's and Mark's posts, I believe they feel that way too. It's just a question of whether a very general implementation is needed/worthwhile.
Steve
participants (4)
-
Andreas Barth -
Brian Carpenter -
Ruth Ivimey-Cook -
Stephen J. Turnbull