Dds 1691 -- New API endpoint to extend the deadline: ProjectStatus.patch

[rv0lt]

Read this before submitting the PR

1. Always create a Draft PR first
2. Go through sections 1-5 below, fill them in and check all the boxes
3. Make sure that the branch is updated; if there's an "Update branch" button at the bottom of the PR, rebase or update branch.
4. When all boxes are checked, information is filled in, and the branch is updated: mark as Ready For Review and tag reviewers (top right)
5. Once there is a submitted review, implement the suggestions (if reasonable, otherwise discuss) and request an new review.

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:

{
"new_deadline_in": int
}

If, new_deadline_in 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:

1. CLI: call ProjectStatus.patch
2. API: ProjectStatus.patch returns project status and deadline (days left)
3. CLI: Print project status, deadline, and chosen new deadline. Ask for confirmation.
4. CLI: call ProjectStatus.patch with confirmed flag
5. API: ProjectStatus.patch verifies correct status, and ok deadline, and extends the deadline.

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.

• New feature
  • Breaking: Why / How? Add info here.
  • Non-breaking
• Database change: Remember the to include a new migration version, or explain here why it's not needed.
• Bug fix
• Security Alert fix
• Documentation
• Workflow
• Tests only

4. Additional information

• Sprintlog
• Blocking PRs
  • Merged
• PR to master branch: _If checked, read the release instructions
  • I have followed steps 1-8.

5. 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.

• Black

• Prettier

• Yamllint

• Tests

• CodeQL

• Trivy

• Snyk

[codecov]

Codecov Report

Merging #1480 (494b7bc) into dev (e9a0d1d) will increase coverage by 0.12%.
The diff coverage is 100.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%)	⬆️

[i-oden]

Am I understanding it correctly if I say you're aiming at this being the full flow for the CLI and API?

1. CLI: call ProjectStatus.get
2. API: ProjectStatus.get returns project status and deadline
3. CLI: Print project status, deadline, and chosen new deadline. Ask for confirmation.
4. CLI: call ProjectStatus.patch
5. API: ProjectStatus.patch verifies correct status, and ok deadline, and extends the deadline.

If so, also add this to the PR description so that it's easier to work on the CLI command part. If not add the correct imagined steps to the PR description 🙏🏻

[i-oden]

A few minor things

[i-oden]

Looking good, need some small adjustments though - e.g. change from days_in_expired to days_in_available and a change in an error message for the users

[i-oden]

@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]

@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.

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

[i-oden]

@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.

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.

1. Expired should have one second before Available.
2. Add check that the status is available still
3. Change deadline_in=project.responsible_unit.days_in_expired to deadline_in=1

[i-oden]

If the tests pass now, this PR is approved and you can merge!