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/