Problem/Motivation
This is a working issue to figure out the right solution for declaration states, assuming we have declaration types
✨
Declaration types
Active
.
It's unavoidably intertwined with considerations of cancellations and confirmations as these also involve state.
Considerations
1. The procedure in 3.10.1 for handling oral declarations lacking a recording is exactly the same as that in 3.8.1 for handling other declarations that are invalid due to lacking sufficient evidence. I actually cannot see any reason why the oral declarations procedure - strictly speaking - needs to be discussed separately in the guidance. I interpret it
2. This confirmation procedure could in theory be executed at any point in the declaration lifecycle: immediately on creation, later but before any donations might have been claimed, later after donations have been (erroneously) claimed, and even retrospectively after cancellation if audit finds a problem later.
3. Editing a declaration after a confirmation email has been sent but before its 30 days grace period had passed potentially invalidates the pending confimation, which would need to be resent and the grace period restarted..
4. Cancelling applies retrospectively if declaration requires confirmation, otherwise prospectively.
5. It's true that these 3 states are mutually incompatible:
- NEVER VALID: the declaration has never been valid, and cannot be made valid by confirmation.
- REQUIRES_CONFIRMATION: the declaration either lacks sufficient evidence, or an explanation was never given, but this can be fixed by sending a confirmation.
- VALID: the declaration has sufficient evidence, including evidence that a suffcient explanation was given.
6. Nice to have:
(a) Allow staff to suspend a declaration, so donations are not claimed under it until the declaration has been further reviewed or problems addressed, but without invalidating claims previously made
(b) Allow staff to seek confirmation on a declaration, but without invalidating any (dubious, yes) past claims made under it
(c) Given the hassles of having to refund claims made in error, it'd be good to have a very robust way of determining whether or not its possible that any claim has ever been made under a declaration
(d) Allow staff to trigger resending of confirmations, including after a previous one has been sent but before the 30 days grace period is over, so they can resend a confirmation if for example they found an email address mistake.
Proposed resolution
I will provide code in an MR. It's not at attempt at working, mergeable code, but rather explanation-by-illustration.
Remaining tasks
User interface changes
API changes
Data model changes