spookylukey
commented
1 year ago This would actually be a huge amount of work. What we'll have to do instead is:
- find out which verses are affected
- send a notification to affected users
- just directly update the text in the DB, plus wordsuggestions.
We want to gracefully handle cases where a new version of a text comes out, especially when access to the old version may become restricted. This is needed to handle ESV update, for example.
Requirements
need database fields to store the link between the versions
what should we do when version text is identical?
where the updated text is identical, we could automatically change all UserVerseStatuses to point to the new version.
this also means: if they choose to learn a new verse set using the old version, it should create UserVerseStatuses that point to the new version if the text is identical, but keep with the selected version otherwise.
This will make the version links when testing incorrect and confusing.
Instead, at verse load time, we can transparently use the newer text. However, the UserVerseStatus still points to original requested version.
For some cases, we need to forbid new users from using the old text:
where a person hasn't already started using it, they should never see that it exists on the site.
if they get a permalink for a verse set using a text version they are not allowed to see, ideally it should automatically redirect them to the version they are allowed to see.
where a person has already started using the old text, they should be able to continue using it.
We should have an
updatablefilter added to the verse progress page, so they we can send these users a hyperlink to show all verses that can be moved.We should have a "change version" button that allows switching version, only between the two related versions, without losing progress. It will work for the entire verse set at a time.
Implementation notes
For each user, store
allowed_restricted_versionsas a M2M (or perhaps ArrayField, for efficient loading). Then, for each user the visible versions will be all unrestricted versions, plus restricted versions if they are referred to inallowed_restricted_versions. A migration will populateallowed_restricted_versionsbased on what they have already started learning.