[Feature] New work experience fields

[vd1992]

🤖 Resolves #11868

👋 Introduction

Add new fields to work experiences. This included various tasks like factory, testing, schema, snapshotting, and enum changes.

Figma for reference, needed for proofreading
https://www.figma.com/design/piRkRtWAHheoEX5Jq8d9u7/Create%2FEdit-an-experience-(Applicants)?node-id=472-70951

🕵️ Details

Was stumped for a bit on handling classifications and departments through JSON, but our friend Staudenmeir of EloquentHasManyDeep fame had an answer, HasJsonRelationships

🧪 Testing

Refresh API first!

1. Try seeding data
2. Through GraphiQL, try creating, updating, and querying work experiences
3. Frontend unchanged (can interact with experiences normally through things like career timeline and application view)
4. Proofread!

Useful operations

{
  createWorkExperience(
    userId: "ID"
    workExperience: {
      employmentCategory: GOVERNMENT_OF_CANADA, 
      govEmploymentType: TERM, 
      classification: "ID", 
      department: "ID"
    }
  ) {
    id
  }
}

Add or subtract fields as needed

  me {
    id
    experiences {
      id
      ... on WorkExperience {
        role
        organization
        division
        startDate
        endDate
        employmentCategory {
          value
          label {
            en
            fr
          }
        }
        extSizeOfOrganization {
          value
          label {
            en
            fr
          }
        }
        extRoleSeniority {
          value
          label {
            en
            fr
          }
        }
      }
    }
  }

📸 Screenshot

Creating

Validator

Querying

🚚 Deployment

[vd1992]

Some validation can't be used until the frontend is updated. Validation will need clean-up once the frontend is usable

[vd1992]

A/C in #11864
Makes mention of handling this

[vd1992]

Will delete some of these unused ones after some reviewing is done

[petertgiles]

I dunno, this doesn't smell quite right to me. Laravel validation (and Lighthouse) is all about validation input but really you want to validate the final state of the model. This seems very clunky though. I think I'll ask on Slack if anyone has ideas.

[vd1992]

So uh, what do we want?

[petertgiles]

Decision in scrum: don't query existing model, just expect that all the fields to check exist in the input.

[vd1992]

Aye aye, reusing the validator then in 688a7a9

[petertgiles]

Wow, a big chonky one! I just did a code read-through before I start trying things out.

[petertgiles]

I dunno, this doesn't smell quite right to me. Laravel validation (and Lighthouse) is all about validation input but really you want to validate the final state of the model. This seems very clunky though. I think I'll ask on Slack if anyone has ideas.

[petertgiles]

Maybe these two should be something like DepartmentBelongsTo?

[vd1992]

Hm, I think I should have "id" in the name of that, changed in 371b58a
Not sure about sticking "BelongsTo" in there

[petertgiles]

I'm thinking of two reasons why this might be worth doing (even though it works as is). 1) Consistency is good - it will match the other relationship inputs in the schema. 2) If we do eventually change back to a full work_experiences table we won't be forced to change the schema to make it work.

[vd1992]

The reason I am hesitant about trying to keep it consistent is because it isn't the same at all. We're storing values in JSON and I had to install something to mimic normal Eloquent relations when querying the experience 😕

[tristan-orourke]

Given that you did install something to mimic normal eloquent relations... would DepartmentBelongsTo work? Maybe try it.