Updating the query set logic to include the expiry check for course based trainings #2223
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The model connection between Course and Trainings has now been updated to a one-to-many relationship. The initial plan of implementing the M2M was to avoid adding new fields to training. For example, the training_type is attached to course via a foreign key in course, thereby not changing the training_type model, but was not the best implementation and has hence been changed to the more logical implementation - one training can only have one course, but a course can have multiple trainings. That implementation requires a migration and a new table to be created, which is created in the #1951. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
This is a small PR making a tiny change in the queryset for the trainings. The logic is updated to also include custom logic for courses as their expiry is determined in slightly different way than the regular one.
Why
A TrainingType can have multiple courses attached to it, each being a unique version in itself. Each course version should have it's own valid duration - and hence it's own expiry date.
Whenever a user takes an on-platform course, it is the latest version of the course available at that time, but with time new versions can come in, and at some point, the version of the course that this training was attached to, will be deprecated. At that point all the trainings associated with this course version should be renewed. Thus, admin panel provides an option to set an expiry date to the associated trainings when deprecating a course version. That is how the expiry date for the trainings is decided for course version, which is different from the way it is determined for other types of trainings.
Thus, this PR adds onto the logic of querysets so that all the courses are accurately identified and put under active / expired versions.
This PR does not disturb the regular flow - it only add onto the logic to also fetch the course based trainings (A feature in the upcoming Trainings part-2 PR)