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