- 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