[$100] Should not set `daysWorked` during automatic WP creation/updates

[maxceem]

Background

At the moment, when we automatically create and update WorkPeriods for ResourceBookings as per this logic https://github.com/topcoder-platform/taas-apis/wiki/TaaS---Scope,-Status-and-permissions#work-period-wp-automation-and-constraints. We are going to update this logic as per new requirement https://github.com/topcoder-platform/taas-apis/wiki/Work-Periods-(WP)-Automation-and-Constraints below I would describe the reason for this update and solution.

Issue

Topcoder Manager could be interested in manually set the actual daysWorked for WP.

If after this, we update RB start/end dates, the WPs would be re-calculated automatically, and the value which is set by Manager would be lost, as daysWorked would be re-calculated.

Solution

During automatic creation of WPs we should NOT calculate daysWorked they should be left as null. When we show work periods in UI if we see null UI should calculate the default value to show based on RB start/end dates.

• Manager would be able to manually set daysWorked. If it's set, then the value would be saved to API.
• During automatic WP create/update don't set daysWorked

Implement Constraints / Automatic updates

• If we reduce the duration of Resource Booking by making startDate later or endDate earlier, then
  • if some WorkPeriod has daysWorked set (not null) then we have to make sure that such daysWorked is a possible value. If currently set daysWorked is not possible - we have to update it to maximal possible as per new Resource Booking startDate/endDate. see examples for constraints
• If we extend the duration of Resource Booking by making startDate earlier or endDate later, then no problem.
  • If some WorkPeriod has daysWorked set, we don't update it.
• Update existent unit tests and create good unit tests to check all the essential cases in the logic of constraints and automatic updates - this is important

UI Logic

Not in scope of this issue, but to explain how UI would work:

• if UI sees daysWorked=null in some Work Period it should calculate the default value to show by itself
• if UI see daysWorked=N then is just shows the value
• when in UI we would process payments and daysWorked=null then again the payment would be process with the calculated value which is currently visible to the Manager

[maxceem]

@eisbilir this is ready for pick up now. Please, assign yourself if you would like to work on this.

[maxceem]

Challenge https://www.topcoder.com/challenges/7b609463-7462-4dba-81d2-33495ea73c70 has been created for this ticket.

This is an automated message for maxceem via Topcoder X

[maxceem]

@eisbilir, please sign-up with Topcoder X tool

This is an automated message for maxceem via Topcoder X

[eisbilir]

@maxceem

If we reduce the duration of Resource Booking by making startDate later or endDate earlier, then

what if new dates of RB causes deletion of a WorkPeriod which is not paid but has daysWorked set ?

If we extend the duration of Resource Booking by making startDate earlier or endDate later, then no problem.
If some WorkPeriod has daysWorked set, we don't update it.

Can we make the following inference?
If a WorkPeriod has daysWorked=null then we'll keep it null
If a WorkPeriod needs to be created after extending RB's duration then new WorkPeriod's daysWorked will also be null

After this fix there will still be an uncovered implementation according to https://github.com/topcoder-platform/taas-apis/wiki/Work-Periods-(WP)-Automation-and-Constraints which is :

We should not allow canceling Resource Booking or deleting if at least one payment was already processed or in progress for at least one of the Work Period of the Resource Booking.

We don't allow deleting but cancelling for now

[maxceem]

what if new dates of RB causes deletion of a WorkPeriod which is not paid but has daysWorked set ?

delete such WorkPeriod

Can we make the following inference?
If a WorkPeriod has daysWorked=null then we'll keep it null
If a WorkPeriod needs to be created after extending RB's duration then new WorkPeriod's daysWorked will also be null

correct

We don't allow deleting but cancelling for now

good catch, yes we would need to protect us from canceling RB, once some WP is paid. This would be done in another issue.