Closed rv0lt closed 10 months ago
Merging #1480 (494b7bc) into dev (e9a0d1d) will increase coverage by
0.12%
. The diff coverage is100.00%
.
@@ Coverage Diff @@
## dev #1480 +/- ##
==========================================
+ Coverage 90.19% 90.32% +0.12%
==========================================
Files 29 29
Lines 4426 4484 +58
==========================================
+ Hits 3992 4050 +58
Misses 434 434
Files | Coverage Δ | |
---|---|---|
dds_web/api/project.py | 91.39% <100.00%> (+1.07%) |
:arrow_up: |
@rv0lt So since the new statuses added to the projectstatuses
table have the exact same creation date and time, I'm wondering if there's a risk that the code thinks that the Expired
status is added last and therefore the system thinks that that is the current status..? Maybe we should do for example
new_status_row = self.expire_project(
project=project,
current_time=curr_date - <1 second here>,
deadline_in=project.responsible_unit.days_in_expired,
)
?
Or if we should add checks in the tests that you have added that verifies that project.current_status
is Available
.
Also, currently we set (example above) deadline_in = project.responsible_unit.days_in_expired
but it feels like it could become confusing to us in the case that the deadline for the Expired
status is after the deadline for the Available
status that's added. So I'm wondering if we should set the deadline_in
here as e.g. tomorrow.
@rv0lt So since the new statuses added to the
projectstatuses
table have the exact same creation date and time, I'm wondering if there's a risk that the code thinks that theExpired
status is added last and therefore the system thinks that that is the current status..? Maybe we should do for examplenew_status_row = self.expire_project( project=project, current_time=curr_date - <1 second here>, deadline_in=project.responsible_unit.days_in_expired, )
?
Or if we should add checks in the tests that you have added that verifies that
project.current_status
isAvailable
.Also, currently we set (example above)
deadline_in = project.responsible_unit.days_in_expired
but it feels like it could become confusing to us in the case that the deadline for theExpired
status is after the deadline for theAvailable
status that's added. So I'm wondering if we should set thedeadline_in
here as e.g. tomorrow.
@rv0lt So since the new statuses added to the
projectstatuses
table have the exact same creation date and time, I'm wondering if there's a risk that the code thinks that theExpired
status is added last and therefore the system thinks that that is the current status..? Maybe we should do for examplenew_status_row = self.expire_project( project=project, current_time=curr_date - <1 second here>, deadline_in=project.responsible_unit.days_in_expired, )
? Or if we should add checks in the tests that you have added that verifies that
project.current_status
isAvailable
. Also, currently we set (example above)deadline_in = project.responsible_unit.days_in_expired
but it feels like it could become confusing to us in the case that the deadline for theExpired
status is after the deadline for theAvailable
status that's added. So I'm wondering if we should set thedeadline_in
here as e.g. tomorrow.1. The double-checking that the project is kept as available sounds alright. Maybe set again the curr date before the call of the expire and release so it has different seconds 2. Yeah sounds reasonable that the deadilne here can be some dummy data to avoid confussion
Great. Do that.
deadline_in=project.responsible_unit.days_in_expired
to deadline_in=1
Read this before submitting the PR
If there is a field which you are unsure about, enter the edit mode of this description or go to the PR template; There are invisible comments providing descriptions which may be of help.
1. Description / Summary
Implemented the functionality in the API of extend the deadline for a project with a new endpoint:
The new endpoint is PATCH /proj/status
Currently, it only supports the functionality of extending the deadline for which the following body is necessary:
If, _new_deadlinein has not been provided then, nothing is executed. If it is provided, it needs to be an integer that defines the extension in days for the new deadline. These days while be added on top of the current day's left.
The workflow process that should be handled when project status extend deadline is called is as follows:
2. Jira task / GitHub issue
Link to the github issue or add the Jira task ID here.
3. Type of change
What type of change(s) does the PR contain?
Check the relevant boxes below. For an explanation of the different sections, enter edit mode of this PR description template.
4. Additional information
master
branch: _If checked, read the release instructions5. Actions / Scans
Check the boxes when the specified checks have passed.
For information on what the different checks do and how to fix it if they're failing, enter edit mode of this description or go to the PR template.