✨ Applicant-facing PoolCandidate status chips

[tristan-orourke]

✨ Feature

This task is to update the status chips used to represent the status of PoolCandidate objects to applicants.

Note: conceptuallly, PoolCandidate objects can be considered to represent two slightly different things at different points in their lifecycle. These are displayed separately, as Applications and as Recruitment Processes.

1. Initially, the PoolCandidate object represents an Application to a pool or job. This can be in draft, in assessment, or qualified/rejected.
2. If the Application is accepted (Qualified), the user can be considered be a candidate in a Recruitment Process. This can have statuses like "Looking for job", "suspended", "expired" or "removed".

🕵️ Details

Status Pill logic - I attempted to work through the whole logic here

We only need to worry about showing a PoolCandidate object as a Recruitment Process if the user was Qualified in the process. ie finalDecisionAt is not null and finalDecision is one of

• QUALIFIED;
• QUALIFIED_EXPIRED;
• QUALIFIED_PLACED;
• QUALIFIED_REMOVED;

Note, QUALIFIED_PENDING indicates they're likely to be qualified, but finalDecision has not actually been made yet, and finalDecisionAt will be null. From the application's perspective, the application is still in assessment.

🎨 Design

@JoshBeveridge

[https://www.figma.com/design/oZhQe9ahidHFfaiqgREvxa/Dashboard-(All-users)?node-id=2086-63995&node-type=frame&t=1x50TV9VIcwOqroM-0](Figma link to where these appear in new dashboard designs.)

These statuses also appear on the old (current?) design, and thus this can be completed before #10788.

📸 Screenshot

Applications:

Recruitment processes:

🙋‍♀️ Proposed Implementation

Currently, utils/poolCandidate.ts getCandidateStatusChip generates the status chip that is shown to applicants when representing "Applications", while components/QualifiedRecruitmentCard/utils.ts getQualifiedRecruitmentInfo generates the chip that appears to the applicant when represeinting a "Recruitment Process". I think we should move these both to utils/poolCandidate, with some clear documentation on the distinctions. (computeInAssessmentStatusChip, also in utils/poolCandidate.ts, is shown to assessors.)

Then, update the two functions which generate the chips shown to applicants, to match the logic described in this ticket and accompanying spreadsheet. Also, in addition to the color and label, these functions can return the longer description which matches them.

There's one case where the longer description for a status (Unsuccessful) differs depending on pool.areaOfSelection. (Pools which are only able to gov employees, not the public, allow unsuccessful applicants to reach out about why they were disqualified.) That means we may also have to pass pool.areaOfSelection into the getCandidateStatusChip function.

When it comes to distinguishing between Received, Under review, Pending assessment, and Under assessment, we can use the PoolCandidate.assessmentStatus (type AssessmentResultStatus).

If JobPoster has screening questions, numberOfApplicationScreeningSteps = 2. Otherwise numberOfApplicationScreeningSteps = 1.
If currentStep == 1 and assessmentStepStatuses is empty, status is Received
If currentStep <= numberOfApplicationScreeningSteps and assessmentStepStatuses is not empty, status is Under Review
If currentStep > numberOfApplicationScreeningSteps and length(assessmentStepStatus) <= numberOfApplicationScreeningSteps , status is Pending Assessment
If currentStep > numberOfApplicationScreeningSteps and length(assessmentStepStatus) > numberOfApplicationScreeningSteps , status is Under Assessment

🌎 Localization

Each status title, the thing that appears in a chip, has an associated longer description. See designs here: https://www.figma.com/design/oZhQe9ahidHFfaiqgREvxa/Dashboard-(All-users)?node-id=1721-27550&node-type=frame&t=1x50TV9VIcwOqroM-0

Applications

status	description
Draft	A draft application has been started but not submitted. You can continue a draft and submit it any time before the application deadline.
Received	Your application has been successfully submitted and is awaiting review. We’ll notify you when HR staff begin the review process.
Under review	Your application is actively being reviewed by HR staff. We’ll notify you when next steps are required.
Pending assessment	Your application was successfully screened in and you are now queued for further assessment. Depending on the volume of applications received, there may be a delay of up to several months before HR staff will reach out with next steps.
Under assessment	Your application was successfully screened in and merit criteria are now being assessed. You will be contacted directly about each required assessment. We will also notify you when your application status changes based on the results.
Paused	Your application is still under review but has been paused due to missing information or a delay in the hiring process. If HR staff require information from you they will be in touch. We will notify you when your application review resumes. There is no paused status for applications
Successful	Your application has been approved and you’ve passed the required assessments. Depending on the type of process you applied to, HR staff or potential hiring managers will be in touch with next steps.
Unsuccessful	Unfortunately, your application was unsuccessful. Due to the high volume of applications, we’re unable to provide specific feedback why an application was rejected.
Unsuccessful (on Gov-only poster)	Unfortunately your application was unsuccessful. For opportunities internal to the Government of Canada, you may request an informal conversation about this decision. If you’d like to discuss this application, please reach out to the functional community. (Don't worry about this being a link for now)
Expired	The deadline to apply for this opportunity has passed.

Recruitment Processes (poolCandidates where Applicant is Qualified)

status	description
Open to jobs	You’re currently interested in receiving job opportunities related to this recruitment process. You can change this status at the end of this dialog.
Not interested	You’ve indicated that you aren’t interested in receiving job opportunities related to this recruitment process. You can change this status at the end of this dialog.
Hired	You've accepted a job thanks to this recruitment process. You'll no longer receive job opportunities related to this process. If you wish to continue receiving referrals, you can let us know by editing your status at the end of this dialog.
Expired	Recruitment processes usually retain talent for a limited amount of time, after which candidates need to be re-evaluated. If you're interested in similar roles, apply to opportunities on the "Browse jobs" page.
Removed	You’ve been removed from this recruitment process by HR staff due to unresponsiveness or another relevant reason. If you feel this was an error, please reach out to the functional community.

✅ Acceptance Criteria

• Update utils/poolCandidate.ts getCandidateStatusChip so it returns colour, label and description according to Application tab of spreadsheet
• Replace components/QualifiedRecruitmentCard/utils.ts getQualifiedRecruitmentInfo with another function in utils/poolCandidate.ts which returns colour, label, and description according to Recruitment process tab of spreadsheet

[tristan-orourke]

@gobyrne the status Paused appears in the design, but not in the spreadsheet yet. Where is it supposed to fit?

[gobyrne]

Paused is the status that should appear when an Applicant marks themselves as no longer interested on a Process they qualified in (not for an application). I'll summon a Josh.

[gobyrne]

Josh removed "paused" from the list in slack. Let's just pull make it clear not to do it for this.

[mnigh]

Unsuccessful | Unfortunately, your application was unsuccessful. Due to the high volume of applications, we’re unable to provide specific feedback why an application was rejected.

Unsuccessful (on Gov-only poster) | Unfortunately your application was unsuccessful. For opportunities internal to the Government of Canada, you may request an informal conversation about this decision. If you’d like to discuss this application, please reach out to the functional community.

If part of the purpose of this issue is to simplify statuses so that they are easier for everyone to understand, why is there a need to a two-tiered (internal, external) system for Unsuccessful? The statement "we’re unable to provide specific feedback why an application was rejected" also applies to the internal candidates. The other statement includes requesting an "informal conversation" which seems preferential to that of external opportunities and the statement to "please reach out to the functional community" is vague enough that with likely result in requests like "how do i reach out to the functional community".

[tristan-orourke]

@mnigh we're aware its preferential but we're required by policy to do this :/ As for it being confusing, #12215 is meant to help.

[mnigh]

@mnigh we're aware its preferential but we're required by policy to do this :/ As for it being confusing, #12215 is meant to help.

@tristan-orourke Strange policy, but if that is the case, why aren't there two statuses (government, non-government) for each real status? Creating a GC Digital Talent support ticket seems a circuitous and unintuitive way to get in touch with a functional community, no (unless functional communities are actually administered and owned by the GC Digital Talent helpdesk)?

[esizer]

Currently the status chips are being computed on the client. Since the new statuses require access to assessments, this will not be possible.

We will likely need to move this logic to the server. Since this reads from multiple tables, I don't think it would be very efficient to do this on fly and could be better if we store it as a computed value in the database similar to the final decision.

[brindasasi]

Even if we ignore the assessment status and do this client side for now , it will not benefit us much for the release and we need to rewrite this anyways.
So I'm hoping to do this right way as the server implementation even thought it may cause the subsequent dashboard tickets to go on the next release.

[tristan-orourke]

For now, let's keep this logic on the frontend. We'll follow up with #12421 to make it work.