✨Backend model for Community Interest

[gobyrne]

✨ Feature

On the applicant/employee dashboard, government employees will be able to express interest in a community. When they do so, we collect some additional information about where there interests lie.

🕵️ Details

#I guess this is effectively a pivot table for user-community with a little extra info, we could rename it to UserCommunity or similar
type CommunityInterest {
  id: UUID!
  community: Community # belongsTo
  workstreamInterest: [WorkStream]  #workstreams from this community only
  
  jobInterest: Boolean
  trainingInterest: Boolean

  additionalInformation: String #input by user

  #developmentProgramInterest: [DevelopmentProgramInterest] # This doesn't exist yet, will be added in 12099
}

type EmployeeProfile {
  ...
  interestInCommunities: [CommunityInterest] @hasMany
}

Notes:

• Pivot table for development programs described in: ✨ Backend model for Development Program #12099
• EmployeeProfile added in ✨ Backend data for Government Career Planning Employee Profile #12001
• In the database, each CommunityInterest item belongs to a user_id. EmployeeProfile is backed by the users table.

🎨 Design

https://www.figma.com/design/H1loB8WxGP6vyJTrVqcafd/Functional-communities-(Employees)?node-id=5-9&node-type=canvas&t=51PBxXT2GvAXqEZd-0

📸 Screenshot

🙋‍♀️ Proposed Implementation

In terms of mutations, it may be easiest to add attach/detach/sync fields to EmployeeProfile.interestInCommunities the field.
Similarly, the CommunityInterest input should support attach/detach/sync operations for work streams.

Alternatively, we could add create and update mutations for CommunityInterest, where the input includes a userId or employeeProfileId. In this case the mutations should check the update-own-employeeProfile permission.

Validation:

Work Streams attached to a CommunityInterest belong to the correct community.
For simplicity, we should probably not allow changing the community of a CommunityInterest entity. You'd have to create a new one.
A user should not be able to create two CommunityInterests with the same Community, or add the same stream multiple times to one CommunityInterest (these should also be validated at database level, but we still want Laravel validation to return better error messages).

🌎 Localization

✅ Acceptance Criteria

• Migration defines a community_interests table, with user_id and community_id foreign keys, and a pivot table with work streams. Constraints against the same user_id/community_id combo, or against work streams being added to to one Interest
• Laravel model for CommunityInterest, with relationships and factory and seeder
• CommunityInterest added to schema. It's queryable via EmployeeProfile.
• An employee can use a mutation to add or update their CommunityInterests. Validation ensures that work streams match the proper Community, and CommunityInterests and WorkStreams aren't duplicated.
• phpunit test for that validation

🛑 Blockers

Blocked By

Preview Give feedback

1. ✨ Backend data for Government Career Planning Employee Profile #12001
   feature +1
   

[github-actions]

Status: Ready to merge ✔️

Issues blocking this PR:

• ✨ Backend data for Government Career Planning Employee Profile #12001 ✔️

---

This comment was automatically written by the Blocking Issues bot, and this PR will be monitored for further progress.