Closed lunkwill42 closed 2 days ago
Issues
0 New issues
0 Accepted issues
Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code
Descriptor | Linter | Files | Fixed | Errors | Elapsed time |
---|---|---|---|---|---|
β PYTHON | black | 991 | 0 | 12.97s | |
β PYTHON | ruff | 987 | 0 | 0.1s |
See detailed report in MegaLinter reports
ββββ8 filesββββββ8 suitesβββ8m 11s β±οΈ 2β140 testsβ2β129 β β0 π€β11 β 4β012 runsββ3β990 β β0 π€β22 β
For more details on these failures, see this check.
Results for commit 26389a57.
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 60.37%. Comparing base (
27b12b5
) to head (26389a5
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
π¨ Try these New Features:
Branch name and history are off, closing to create a new PR
This fixes #3228, but it was not feasible without a significant refactoring of the maintenance task UI codebase.
The codebase originally stems from a time before Django was added to NAV, and was significantly convoluted compared to what it needs to be. This PR makes it slightly less so, but there is still some way to go:
There was a lot of processing and custom validation code for the component fields of the maintenance task forms, which ended up producing large hierarchies of dicts and lists (some of which were fed directly to templates), instead of re-using ORM functionality. While much of the processing would be best encapsulated in Django Forms, this refactor mostly concerns itself with using ORM objects where we can.
The ultimate goal was really only to be able to display deleted components in a better way, by utilizing a new component
description
field. This is achieved in this PR by replacing the template render data witch actual lists of Django model objects, and by replacing the missing objects with a specialMissingComponent
class.Please do ask for clarifications if necessary.