- Implement proper users listing, added tests for it
- Deleting users/accounts
TODO: more browser tests
It could, indeed. Then we should change isDeleted() so it also returns true when !empty($this->deleted_at), or not? I don't want to make things more complicated at the moment.
save() would work, but would generate updated/updating event which we don't need/want.
The question is then how the complete process of deleting a domain (or a user for that matter) is reflected in real life, vs. the database record.
I believe I intended for the database to reflect in 'deleted_at' the semantics for UI/UX -- including billing and pro rata temporis if you will, and for STATUS_DELETED to be the final confirmation.
In a sense, deleting could spawn the dispatched process -- it creates a series of actions to need to have occurred much like creating a user does (ldap ready, imap ready).
I think it is there where I figured STATUS_DELETED would add value compared to just deleted_at.
I think we need to settle what deleting and deleted is compared to deleted_at vs. STATUS_DELETED, before we need to consider $domain->save() and its triggering of updating()/updated().
Think... "remove entitlements billed to wallets owned".
When email@example.com owns a wallet to which all entitlements associated with any @kolab.org-related entitlements are billed -- and how would he not?? --, then iterating over his wallets and entitlements billed to said wallets is a very predictable path.