🪓 stuff from Government Employee section of profile but it's actually more work not less

[gobyrne]

✨ Feature

We're adding all the collection of government information to the experiences. This makes a lot of the info on the Government Employee section of the profile redundant. This ticket explains how we will update the government employee information section for applicants, what info we will provide to Community/Admin users in it's place and how we will manage backwards compatibility (for peeps who don't add new experiences.

🕵️ Details

Changes to Government employee section of the profile

Hide (and freeze the data) but don't delete the following:

• Government employee status
• Current department
• Employment type
• Current classification group and level

Add this message in this section: How we collect employee information has changed To better capture your career journey in the public service, we now collect details like your classification and department as a part of your career experience. If you currently work for the Government of Canada, update your latest work experience to include this information.

Update "work email" label Just so it's extra clear, relabel the "Work email" in this section to "Government of Canada work email"

Changes to Admin view of Government employee information

We will display very similar information to community/admins going forward, but where that data comes from is more complicated. We want to use new experience information if it exists, but fall back on the "frozen" Government employee information otherwise.

Going forward we will show basically the same info to community/admins on the Snapshot (application) view, the snapshot (applicant) download, the applicant profile, the profile download AND the CSV download. Only difference is the addition of Position type and where the data is coming from. Government of Canada employee: Yes/No Department: Department Employment type: EmployementType (position type if term/indeterminate, expected end date if available) Current classification: Group-level

Now for where we pull that info from. For snapshots and snapshot download (application/candidate download, we just need to start saving the new (position type) and, going forward, displaying it when it's available. When saving the snapshot we'll have to use the logic from the pseudo code below.

For user profile, profile download and CSV download All current experiences are being migrated to be non-gov experiences. The user has to go in and change them to government experience for them to be considered "government work experience". We will take advantage of this to determine what to calculate/display as their government employee status.

Gray's fantabulous pseudo code for this:

 If **no government experience** exists in the experience
    use the info from **government employee section** of the profile
 else 
      if the **government experience is Current**
         **set employee status** to : Yes, government employee
         find the **current** government experience with the **most recent start date**
            use **department, EmploymentType (PositionType, expected end date), Group-Level** from that experience
      else (**no current government experience**)
         **set employment status to : No**, not government employee

🎨 Design

@JoshBeveridge mostly involved, but @gobyrne can also address

Other sections on Community/Admin view

📸 User profile

[Figma file](https://www.figma.com/design/vZEg5z6aXiJPNB07LamrgY/Admin---Users?node-id=270-26057&t=lufTPLHrZd9MZYqo-1) 

📸 Application snapshot

[Figma file](https://www.figma.com/design/mbgNRMD2ujao55nJkakrZM/Candidate-application-(Communities)?node-id=824-9139&t=l2HHdM3CjkygSQ6I-1) 

📸 Print Profile/Application

[Doc file](https://docs.google.com/document/d/1tKlZ381GBaT7eeJ3vAueTiw4MmzkVqQFWCn_b3W_dqU/edit?usp=sharing) 

🙋‍♀️ Proposed Implementation

Create a new set of fields in the database, on the users table. They MUST default to null.

• computed_is_gov_employee
• computed_gov_employee_type
• computed_current_classification
• computed_department

Update User.php to use the computed fields if is_gov_employee !== null, without modifying the User type in graphql schema:

• add getIsGovEmployeeAttribute which returns computed_is_gov_employee if computed_is_gov_employee !== null, or is_gov_employee otherwise. (Note: check the nullness of computed_is_gov_employee, not computed_gov_employee_type)
• add getGovEmployeeTypeAttribute which returns computed_gov_employee_type if its not null, or gov_employee_typeotherwise.
• modify currentClassification relationship method so that it uses the computed_current_classification foreign key if computed_is_gov_employee !== null, and falls back to current_classification foreign key otherwise.
• modify department relationship method so that it uses the computed_department foreign key if computed_is_gov_employee !== null, and falls back to department foreign key otherwise.

Remove isGovEmployee, govEmployeeType, currentClassification and department from UpdateUserAsAdminInput and UpdateUserAsUserInput so they can't be set directly by the user.

Create a new method in User.php, computeGovEmployeeProfile (or computeGovEmployeeProfileData? Or something else?), similar to computeFinalDecision is PoolCandidate.php. This function may update the new computed fields:

If no government experience exists in the users experiences AND computed_is_gov_employee is null or false
  do nothing    
else if (no government experience exists in the users experiences AND computed_is_gov_employee is true) OR (government experience exists but none is current)
  set **computed_is_gov_employee** to false
  set **computed_gov_employee_type** to null
  set **computed_current_classification** to null
  set **computed_department** to null
else if **government experience** exists and at least one is current
  find the **current** government experience with the **most recent start date**
  set **computed_is_gov_employee** to true
  set **computed_gov_employee_type** based on the most recent current gov experience
  set **computed_current_classification** based on the most recent current gov experience
  set **computed_department** based on the most recent current gov experience

Create a laravel Event, ExperienceSaved, which dispatches whenever an update to a WorkExperience is saved. See AssessmentResultSaved as an example. Create a Laravel App Listener, ComputeGovEmployeeProfileData (open to other names). Similarly to how ComputeCandidateAssessmentStatus is set up to run in response to an AssessmentResultSaved event, set up the new listener to run in response to an ExperienceSaved event. The ComputeGovEmployeeProfileData listener simply runs user->computeGovEmployeeProfile.

✅ Acceptance Criteria

• [ ] Hide fields listed above on Government Employee section of the profile, and add the dismissible message
• [ ] Remove the fields from mutation inputs so applicant can't change them directly
• [ ] Add an Event Observer which computes a user's gov employee profile whenever one of their Work Experiences is updated, according to the logic in Proposed Solution
• [ ] Add accessors to User model (and logic to relationships) which uses the computed data if it has ever been set (look for a non-null computed_is_gov_employee field)
• [ ] Test to ensure that the everything uses the correct values (which is NOT NECESSARILY the computed ones)
  • [ ] snapshots save the correct data
  • [ ] file download and csv use the correct data
  • [ ] admins see the correct data when viewing an applicant profile
• [ ] phpunit tests for the computeGovEmployeeProfile working how and when expected

🛑 Blockers

- [ ] #11864 

ate

[tristan-orourke]

Discussion:

• Do we compute this on the frontend? In Laravel accessors? In observers?
• If we need the computed gov status info for filtering candidates, its easiest to already have it in the database
• Data analytics also wants this info in the database somewhere (or computed in a view)
• That suggests the best solution here is to capture and compute this in observers

[tristan-orourke]

Flags for observer solution

• have to be careful when mutation database directly, eg with mutations, since that won't trigger observers.
• Date ranges are fuzzy. Could create ambiguity.

[Jerryescandon]

Updated design section to include updates to Community/Admin pages