- Stephen J. Turnbull (turnbull.stephen.fw@u.tsukuba.ac.jp) [210213 17:35]:
Andreas Barth writes:
I'd even say: these are different flags.
They already effectively are, as Abhilash explained earlier (more precisely, four values for one variable).
Well, currently these are exclusive-states, I'd rather see them as or-able-states.
So basically I'd consider it rather (as seperate boolean ones):
I don't think separate booleans is a good idea, since they're basically mutually exclusive states, and in most scenarios you want the user to be able to reenable from any of the disabled states, so having both "member disabled" and "admin disabled" would have no special semantics.
That's where I disagree :)
- "disabled by member" (could be set by an admin as well of course)
Currently this is determined by whether the logged in user is the subscriber or not. It's an interesting idea to allow it to be set by an admin. Then we could have the semantics that the only transition allowed from this state would be to enabled, so that admins would know the user had intentionally disabled and know not to enable without permission.
Exactly. Or while importing from another server, and there are people who have receiving mails disabled, this is the state that could be used for it.
I expect that state to be the most-often used when setting a state manually.
For "who set that", I would consider having some kind of history as useful (and displaying "last set by user / $person" to the admin but not the user).
- "disabled for administrative reasons" (only by admin but user should be able to see it)
I don't see why a user would need to see the difference. Unless you're suggesting that the user would not be able to reenable without asking the admin? What is the use case for this?
I'm suggesting exactly that, yes. Why? Well, worked with user for too long. ;)
E.g. consider that seeing archives works only for subscribers. And the subscriber in question complains about too many mails but still re-enables getting mails. This is basically "an admin has blocked you from more mails but not unsubscribed you". Might be an corner case, but still. Might also be too unimportant.
- "bounced" (user and admin could reset it but not set it)
Reenable but not set "bounced" is the current situation.
Except if someone sets the state to "disabled" and then undo this, the state is automatically cleared. Which might be the right thing to do, but perhaps not.
Anyways, that's just what I'd prefer. Doesn't mean that everyone needs to agree to it. :)
Andi