Tech Debt: refactor configuration-dependent models to use a manager making queries by configuration much easier

[pbastia]

Description of the Tech Debt

Right now, every model depending on a certain configuration (exposing valid_from: models.Configuration and valid_to: models.Configuration) have this very manual way of retrieving the right object given a date or a configuration.

Idea: use a custom models.Manager to embed the queries into an annotation / something else. instead of:

ActivityJsonSchema.objects.get(activity_id=<id>, valid_from__valid_from__lte=<date>, valid_to__valid_to__gte=<date>)

we'd do

ActivityJsonSchema.objects.get(activity_id=<id>, date=<date>)
# or
ActivityJsonSchema.objects.get(activity_id=<id>, configuration=<configurationobject>)

Benefits:

• test the config or date resolution only once
• easy API and code readability

Tech Debt Triage

The purpose of our technical debt triage process is to analyze technical debt to determine risk level of the technical debt and the value in tackling that technical debt.

Risk Value Scoring:

Level	Value
High	3
Medium	2
Low	1

Technical Debt - Risk Types	Level	Value
Business Area Risk - Risk of business area visibility / damage to user experience
Developer Fault Risk - How likely will this tech debt cause a future error related to coding on top of it
System Fault Risk - Risk of system errors or application downtime
Time Scale Risk - Compound risk effect if left alone. How much more difficult to fix or dangerous will this become over time?
Time Sink Risk - How much will this tech debt slow the development process down
TOTAL SCORE:

[pbastia]

@Sepehr-Sobhani @dleard tagging you if you have any insight whether this is a good idea

[Sepehr-Sobhani]

If this is a very common pattern, I highly recommend using the custom manager. We have an example in TimeStampedModelManager.