Refactor the report version cloning in a model-agnostic way
- Dominant language
- No language data
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
#### Description of the Tech Debt
PB:
I think there might be a way of doing this entirely programmatically (probably for a later refactor):
take a report version
using reflection, list all models that have an fkey onto it
copy each of these model instances using method (clone, change pk, save)
SH:
Possibly explore the usefulness of generic format string approach for defining the reverse relationship name for dynamic names based on the model class.
#### 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 |
| Medium |
| Low |
| Technical Debt - Risk Types | Level | Value |
| ----------------------------------------------------------------------------------------------------------------------------- | ----- | ----- |
| Business Area Risk - Risk of business area visibility / damage to user experience | 0 | 0 |
| Developer Fault Risk - How likely will this tech debt cause a future error related to coding on top of it | 0 | 0 |
| System Fault Risk - Risk of system errors or application downtime | 0 | 0 |
| Time Scale Risk - Compound risk effect if left alone. How much more difficult to fix or dangerous will this become over time? | 0 | 0 |
| Time Sink Risk - How much will this tech debt slow the development process down | 0 | 0 |
|
#### Development Checklist:
- [ ] Checklist item
- [ ] Checklist item
- [ ] Checklist item
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by locating the existing report version cloning logic and the related models with foreign keys. Review the proposed reflection-based approach and define what model-agnostic cloning should cover; no files, tests, or concrete completion criteria are named in the issue.
Written by the indexing model from the issue text.
Assessment
- Domain
- backend, databases
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100