✨ Backend data for Government Career Planning Employee Profile

[tristan-orourke]

✨ Feature

Add a EmployeeProfile model with a one-to-one relationship to User so that applicants can store the data associated with new Employee Profile section.

Note: this does NOT include the community-specific data

🕵️ Details

QUESTION: how strict do we want to be about non-gov employees? Should we do any validation which requires user to be employees before updating this data? If its not important, would be easier not to. What if a user stops being a gov employee?
ANSWER: we won't worry about validating this on the backend.

Add a way for users to store their:

• talent mobility preferences
• dream job
• career goals and work style

🎨 Design

https://www.figma.com/design/Xnkie0dSq9RujvQRAZwrY4/Employee-profile-(Employees)?node-id=26-18365&node-type=frame&t=VeY3Kg8mOWlgGWXb-0

@JoshBeveridge

📸 Screenshot

🙋‍♀️ Proposed Implementation

Important

Some high-level details of the proposed implementation have changed a bit since estimating.

• In the graphql schema, we'll keep EmployeeProfile a separate model from User. This is because the permissions will differ, and different roles will need access to one or the other.
• However, in the database, we will implement EmployeeProfile as additional fields on the users table. This will simplify the implementation of different relationships. This is similar to what we did with UserAuthInfo.
• Also, the mutations to update the Employee Profile can be simplified to a single mutation. It is not necessary for our backend validation to directly match frontend validation, as long as the data saved to the backend remains sensible and valid.

Enums

We will need some new enums to support the form options and storing them in the database. I think it makes sense to make these localized enums.

1. Organization types
   • Current department/agency/crown corp
   • Other departments
   • Other agencies
   • Other crown corps
2. Promotions/Lateral moves
   • Above level/promotion
   • At level/lateral
   • Below level/demotion
3. Mentorship status
   • Not participating
   • Mentee
   • Mentor
   • Both mentor/mentee
4. Mentorship interest
   • Mentor
   • Mentee
5. Exec coaching status
   • Not participating
   • Have a coach
   • Is a coach
   • Both coaching/learning
6. Exec coaching interest
   • Coaching
   • Learning

Database

These fields will be added to the users table, backing the new EmployeeProfile graphql type.

Talent mobility options

• career_planning_organization_type_interest - jsonb array, nullable (enum 1)
• career_planning_move_interest - jsonb array, nullable (enum 2)
• career_planning_mentorship_status - string, nullable (enum 3)
• career_planning_mentorship_interest - jsonb array, nullable (enum 4)
• career_planning_exec_interest - bool, nullable
• career_planning_exec_coaching_status - string, nullable (enum 5)
• career_planning_exec_coaching_interest jsonb array, nullable (enum 6)

Dream role

• dream_role_community_id - foreign key, nullable
• dream_role_title - string, nullable
• dream_role_additional_information - string, nullable
• dream_role_classification_id - FK, classifications:id
• dream_role_work_stream_id FK, work_streams:id

Dream job relationships

This relationship will require a new table. Ensure there is a user_id/department_id uniqueness constraint, and a user can't add the same department multiple times.

• user_dream_role_departments - Table
  • user_id - FK, users:id
  • department_id - FK, departments:id

Goals, Work Style

• career_planning_about_you - string, nullable
• career_planning_career_goals - string, nullable
• career_planning_learning_goals - string, nullable
• career_planning_work_style - string, nullable

Other

The EmployeeProfile should also have a userPublicProfile: UserPublicProfile field, so users accessing the profile can see the associated name and email, without accessing more private data.

GraphQL

Queries

Create new EmployeeProfile model, with a one-to-one relationship with User. It should be protected by @canResolved(ability: "view"), because some managers who may have permission to view the applicant profile should not be able to see the employee profile.

type User {
  type employeeProfile: EmployeeProfile @self @canResolved(ability: "view")
}

type EmployeeProfile {
  ...
  userPublicProfile: UserPublicProfile @self
}

One implementation I'm not yet sure about is whether EmployeeProfile should have its own Laravel Model, which is backed by the 'users; table, or whether it should use the @model(class: "\\App\\Models\\User") directive like UserPublicProfile.

• The former keeps EmployeeProfile-related relationships and Policies organized separately from the rest of the User, but maybe makes later relationship work more complicated (I'm not sure).
• The latter keeps the User.php model growing, and means we need to add new policy methods to UserPolicy.php and do something like type User { type employeeProfile: EmployeeProfile @self @canResolved(ability: "viewEmployeeProfile") }.

Mutations

Create new mutation updateEmployeeProfile, where id is required (note that EmployeeProfile.id and User.id are the same) and all other fields are optional. We don't need a create mutation because users don't create Users, and if a user exists so does its "nested" EmployeeProfile!

Validation

All the new fields are nullable, and type constraints are handled by Lighthouse Graphql. The only extra validation I can think is possibly ensuring that the same department is not added to Dream Roles multiple times. Even that seems better implemented as a database constraint.

One of the frontend forms which updates EmployeeProfile requires all its fields before submitting, but I'm not concerned about validating that on the backend here. (I'm all for splitting up mutations into smaller, more focused ones, where it provides value, but upon reflection this case was becoming an anti-graphql-ish pattern.)

Permissions

Permissions check if the authenticated user has permission to view or update their own employee profile (view-own-employeeProfile, update-own-employeeProfile). Create these permissions if they don't exist yet. Create EmployeeProfilePolicy if it doesn't exist yet, or depending on implementation details, add new methods to UserPolicy.

Snapshot

This new data does NOT need to be saved in applicant snapshots

🌎 Localization

✅ Acceptance Criteria

• New enums created
• Database migrations created - mostly adding columns to users table, with one new pivot table
• GraphQL schema updated with new EmployeeProfile type
  • include one new updateEmployeeProfile mutation, protected by new permission check
  • User type includes link to EmployeeProfile type, protected by new permission check
• New fields taken into consideration for seeders and factories
• Create view-own-employeeProfile and update-own-employeeProfile permissions

Tasks

Preview Give feedback

No tasks being tracked yet.

[tristan-orourke]

I like the idea of making CareerPlan its own table and graphql model, with a 1-to-1 relationship with User, instead of squeezing it into the already large User table.

edit: we went back and forth on this in refinement - for now keep it in the User table.

(Gray editing this) edit edit: see later comment, probably back to it's own table

[tristan-orourke]

QUESTION: what is area_of_interest?
ANSWER: its actually just a Community

[mnigh]

• Mentorship status

  • Not participating
  • Mentoree
  • Mentor
  • Both mentor/mentoree

• Mentorship interest

  • Mentor
  • Mentoree

@tristan-orourke Is mentee the term that you were going for? I don't think mentoree is a word commonly used.

[tristan-orourke]

The discussion around this is raising a few questions:

• Should models be split up if possible, or should they be combined if possible?

  • one reason we may be resistant to splitting up models, our User model is already kindof overloaded, representing both account settings and profile info

• should we try to restrict mutations to full CRUD operations?

  • I still feel strongly that mutations can be smaller and more specific
  • Eric: more, smaller mutations makes the schema more complicated but everything else simpler

• Realizing that this data shouldn't be saved in applicant snapshots, and that it will likely require different permissions to access from the rest of the "Applicant Profile" (ie most of the User model), pushed us to make it its own model.

[tristan-orourke]

Note

Some high-level details of the proposed implementation have changed a bit since estimating.

• In the graphql schema, we'll keep EmployeeProfile a separate model from User. This is because the permissions will differ, and different roles will need access to one or the other.
• However, in the database, we will implement EmployeeProfile as additional fields on the users table. This will simplify the implementation of different relationships. This is similar to what we did with UserAuthInfo.
• Also, the mutations to update the Employee Profile can be simplified to a single mutation. It is not necessary for our backend validation to directly match frontend validation, as long as the data saved to the backend remains sensible and valid.

[esizer]

For the form, it is not entirely clear for the difference in the options for exec coaching interest. While the option "I’m interested in coaching another employee." is pretty explicit, the other option "I’m interested in being considered for executive coaching." could be interpreted as being considered to be a coach, rather then being coached 🤔