Skip to content

TaaS Scope and permissions

nkumar-topcoder edited this page May 5, 2021 · 1 revision

Welcome to the TaaS - Roles, Scope, Status and permissions wiki

Permission for TaaS-Api

These permission are already implemented at taas-app and taas-api

https://github.com/topcoder-platform/taas-apis/issues/72

Connect and TaaS-App certain roles and scope might overlapp or need to be streamlined, this discussion pending.


TaaS member Invite Scopes.

read:project-invites for https://github.com/topcoder-platform/taas-apis/issues/138

write:project-invites - not needed at the moment, but just in case for https://github.com/topcoder-platform/taas-apis/issues/148

read:project-members for https://github.com/topcoder-platform/taas-apis/issues/138

write:project-members for https://github.com/topcoder-platform/taas-apis/issues/148

Job Candidate (JC) Status

Status Description
open JC is created
selected JC is selected for the Job
Placed JC is placed for the Job, note this gets automatically updated when RB.status = placed
cancelled JC is cancelled
interview JC is selected for interview in RCRM
OLD-Status Description
IGNORE THESE NO LONGER USED
topcoder-rejected JC is rejected in RCRM
shortlist JC is shortlisted in TaaS App
rejected JC is rejected in TaaS App

Ignore above 3, it's no longer used.

Candidate Status Mapping

taas.jobcandidates and rcrm.candidates.status

Rejected

  • Topcoder Rejected
  • Client Rejected - Screening
  • Client Rejected - Interview
  • Client Rejected - Interview No Show
  • Client Closed Opportunity

Shortlist

  • Resume Handoff to Client
  • Schedule Interview
  • Interview Scheduled
  • Interview Rescheduled
  • Phone Screening Organised
  • Shortlist

Job Candidates - recruit CRM Status Mapping

  • taasapp.jobcandidate.status.open = rcrm.assigned
  • taasapp.jobcandidate.status.selected = rcrm.placed

No longer used - ignore

  • taasapp.jobcandidate.status.rejected = rcrm.rejected
  • taasapp.jobcandidate.status.shortlist = rcrm.shortlist
Recruit CRM TaaS App Connect-app
Job creation No No Yes
Candidate assign Yes (via Zap) No No
Candidate shortlist Yes (via Zap) - status=interview in taas-app Yes (via Zap) No
Candidate reject Yes (via Zap) Yes (via Zap) No
Candidate selected Yes (via Zap) No No
ResourceBooking Yes (via Zap) No No
TaaS Dashboard No Yes No

Job Status

Status Description
in-review Job is created by the Customer and waiting for the Topcoder staff to approve it.
sourcing Job is reviewed by Topcoder staff and we are looking for the resources to fulfill the needs.
assigned All the resources needed for the job are assigned.
closed Job is completed and not active anymore.
cancelled Job is cancelled for some reason before actual start. In case even part of the Job is done we should use status closed.

Resource Booking (RB) Status

Status Description Constraints
placed RB is placed to the job (and can actively work on it). -
closed RB has completed its work for the Job and is closed (non-active) now. -
cancelled RB was cancelled together with the Job before actual start. In case resource did at least some part of the job, we should use status closed. Not allowed if some payment was already done for any WorkPeriod.

Work Period (WP) Automation and Constraints

We have to keep Work Periods in sync with data in Resource Bookings because Work Periods represent the weeks of the time when ResourceBooking is assigned to the job and actively works on it.

ResourceBooking is created

Imagine we created a ResourceBooking for some work from the 1st March 2021 till 30th March 2021:

     March 2021

Su Mo Tu We Th Fr Sa  
    ˯
    1  2  3  4  5  6  
 7  8  9 10 11 12 13  
14 15 16 17 18 19 20  
21 22 23 24 25 26 27  
28 29 30 31   
      ˄

In such case, we have to create for this ResourceBooking 5 WorkPeriods to cover all this time.

Each WorkPeriod should ALWAYS represent 1 FULL week from Sunday to Saturday and daysWorked defines how many days the member worked at that week.

Sunday and Saturday are treated as days off and should NOT be counted as daysWorked. So full week working days would be equal to 5 by default.

In the situation above, we have to create 5 WorkPeriods:

1. startDate="2020-02-28" endDate="2020-03-06" daysWorked=5
2. startDate="2020-03-07" endDate="2020-03-13" daysWorked=5
3. startDate="2020-03-14" endDate="2020-03-20" daysWorked=5
4. startDate="2020-03-21" endDate="2020-03-27" daysWorked=5
5. startDate="2020-03-28" endDate="2020-04-03" daysWorked=2

NOTE, that WorkPeriod 5 represents the FULL week from Sunday 28 March till Satruday 3 April, but we set that in that week member worked only 2 days, because ResourceBooking was assigned only until 30 March.

WorkPeriod deleting

We should not allow deleting WorkPeriod if we fully or partially paid for it, i. e. if its paymentStatus is partially-completed or completed

ResourceBooking canceling or deleting

We should not allow canceling Resource Booking or deleting if at least one payment was already processed for at least one of the Work Period of the Resource Booking. Other words, if at least one Work Period of the Resource Booking has paymentStatus as partially-completed or completed.

ResourceBooking startDate or endDate is changed

  • If we extend the duration of Resource Booking by making startDate earlier or endDate later, then no problem. We just increase daysWorked in the corresponding WorkPeriods or create new WorkPeriod if new weeks added to the Resource Booking.
  • If we reduce the duration of Resource Booking by making startDate later or endDate earlier, then we would have to reduce the daysWorked in the corresponding WorkPeriods or remove WoekPeriods if weeks was fully removed from the Resource Booking.
    • ⚠️ CONSTRAINT: we should NOT allow deleting WorkPeriod if the payment for such WorkPeriod was already scheduled or processed, even if partial payment. In such case if we try to change the dates for the Resource Booking we should return an error.

Example for the CONSTRAINT:

We have a Resource Booking with Start 1 March 2021 and End 30 March 2021. And we have 5 corresponding Work Periods: 4 already paid, and 1 not yet paid.

March 2021

Su Mo Tu We Th Fr Sa  
    ˯
    1  2  3  4  5  6    <- Work Period 1 - PAID
 7  8  9 10 11 12 13    <- Work Period 2 - PAID
14 15 16 17 18 19 20    <- Work Period 3 - PAID
21 22 23 24 25 26 27    <- Work Period 4 - PAID
28 29 30 31             <- Work Period 5 - NOT paid
      ˄

We allow reducing ResourceBooking End to 24 March. As a result Work Period 5 would be removed, which is fine because it’s not paid yet. And Work Period 4 daysWorked would be reduced to 3 (even though we already paid it's fine to reduce daysWorked afterward for us).

But we don’t allow reducing ResourceBooking End to 20 March because this would result in deleting Work Period 4 which was already paid.