search

DemocracyClub / yournextrepresentative

👥 A website for crowd-sourcing structured election candidate data
https://candidates.democracyclub.org.uk
GNU Affero General Public License v3.0
21 stars 27 forks source link

Make version history/revert behaviour clearer #1035

Open chris48s opened 4 years ago

chris48s commented 4 years ago

Person objects are related to a number of other entities e.g: Identifiers, Alternative Names, Results, Memberships, Photos etc

At the moment, the selection of those which get stored in version history is a bit haphazard and which ones get modified as a result of a revert operation is a bit haphazard too. This is non-obvious to a user. We need to make this more consistent.

  1. The purpose of version history should be to store an audit trail of edits made in relation to a person. Edits which currently aren't part of the history (e.g: recording results) should be included in the version history.
  2. We should explicitly define a list of related entities which are (should be) modified when we revert a version (Identifiers, Alternative Names, Photos, etc) a list of related entities which aren't (shouldn't be) modified when we revert a version (Memberships, Results, etc).
  3. When we perform a revert that contains versions referencing entities which won't be modified by the revert, we should show the user some kind of summary explaining: "performing this revert operation will change: A, B and C but it won't change: D and E. If you want to revert A, B and C then 'confirm', otherwise if you want to revert D and E, 'cancel' and go do [something else]".
chris48s commented 4 years ago

Just chewing this over a bit more.. another different design decision we could take here would be:

The job of providing an audit trail of edits to Memberships, Results etc is (should be) handled by LoggedAction objects. Only changes which can be reverted should be stored in a Version object.

If we think about it like that, it would simplify the 'revert' operation from the user's perspective because you get rid of the whole "this is thing is contained in that version but reverting it doesn't actually change that thing for [complicated reasons]".

Do we lose anything major if we were to adopt that decision instead?

VirginiaDooley commented 2 years ago

Refer to Michael's merge suggestion table for design; Any changes to the person model would not get reverted; this needs to be handled elsewhere and not on the Version model