Epic: resume data entry

[praseodym]

• Resume data entry without state
  • Minimal implementation
• Save data entry form progress to backend so that user can resume where they left off
  • What is currently not saved? Current page, furthest page, pages with accept warnings checkbox checked, ...?
  • Frontend: split up FormState into separate objects for user data, validation results and static data This is too complicated, it makes more sense to write functions to save/restore only user data to/from the backend.
• Load previously saved data entry after partial save
  • Create backend API endpoint to GET saved data
  • Load data in frontend
• Expand Mock Service Worker with persistence to make data entry save/resume work
  • https://github.com/mswjs/data?
• Show unfinalized data entries for the current user on the select polling station page (Figma)
• Update dom-to-database tests to use new GET API
  • See TODOs in frontend/e2e-tests/dom-to-db-tests/abort-data-entry.e2e.ts
• 'Claim' the data entry as soon as 'Beginnen' is clicked, not only when the 'Recounted'-page is saved.
• Update use cases for resume data entry functionality
• Maybe: Avoiding conflicting saves from multiple clients e.g. by working with timestamp or counter: frontend sends timestamp of previous save to backend, backend cancels save when timestamp is older than current save in database, which means that backend was updated by other client and this client state is out of date
  • See Timestamp-based concurrency control

TODO

• [x] #355
• [x] #368
• [ ] #381
• [ ] #369
• [ ] Update dom-to-database tests to use new GET API
• [ ] Update use cases for resume data entry functionality
• [ ] Expand MSW with persistence
• [ ] Save data entry immediately after beginning
• [ ] Optimistic concurrency control for data entry

[jorisleker]

@praseodym:

Is showing unfinalized data entries for the current user on the select polling station page part of this epic (see Figma)?

And regarding the latter, when do we consider a data entry to be associated to a user? I would say after they click 'beginnen' on the select polling station page. Right now, it's only linked to a user after the submit their first data (click 'volgende' on the recounted page). I think that's too late.

[jorisleker]

Maybe: Avoiding conflicting saves from multiple clients e.g. by working with timestamp: frontend sends timestamp of previous save to backend, backend cancels save when timestamp is older than current save in database, which means that backend was updated by other client and this client state is out of date.

Should'nt we prevent accepting posts from multiple users? The user that started the data entry should be the only one allowed to update it? Doesn't really solve the 'multiple clients' issue, unless we prevent users from logging in on multiple devices (which sounds like a smart idea anyway. We don't want a data typist to use more then 1 machine).

[praseodym]

@praseodym:

Is showing unfinalized data entries for the current user on the select polling station page part of this epic (see Figma)?

Yes it is.

And regarding the latter, when do we consider a data entry to be associated to a user? I would say after they click 'beginnen' on the select polling station page. Right now, it's only linked to a user after the submit their first data (click 'volgende' on the recounted page). I think that's too late.

Indeed, we should 'claim the data entry' as soon as 'Beginnen' is clicked, also to prevent conflicts (what if another user has started in the meantime?).

Maybe: Avoiding conflicting saves from multiple clients e.g. by working with timestamp: frontend sends timestamp of previous save to backend, backend cancels save when timestamp is older than current save in database, which means that backend was updated by other client and this client state is out of date.

Should'nt we prevent accepting posts from multiple users? The user that started the data entry should be the only one allowed to update it? Doesn't really solve the 'multiple clients' issue, unless we prevent users from logging in on multiple devices (which sounds like a smart idea anyway. We don't want a data typist to use more then 1 machine).

Of course a single data entry by multiple users shouldn't be possible at all. But multiple clients on a single machine with a single user can occur by opening multiple windows/tabs on the same machine, and my suggestion above would also prevent that from creating undefined behaviour.

[jschuurk-kr]

@praseodym In our July retro we decided to have two owners per epic. Who is your co-owner for this one?