♻️ Associate every Request with a Community

[tristan-orourke]

♻️ Debt/Refactor

Create a many-to-one relationship between Requests and Communities - every Talent Request must belong to a single community.
(A community can have many requests.) This should apply retroactively too: every existing request in the database should belong to either the Digital community or the ATIP community, and we can use Pool Stream to determine which.

🕵️ Details

When submitting a talent request, it should be submitted to one of our communities.

For existing communities, they should belong to either the Digital community or the ATIP community, based on Pool Stream.

• ACCESS_INFORMATION_PRIVACY means ATIP community
• any other stream means Digital
• a request without a stream (or with conflicting ones) defaults to Digital

The Community can be accessed from the ApplicantFilter and PoolCandidateSearchRequest types:

type ApplicantFilter {
   ...
   community: Community
}

type PoolCandidateSearchRequest {
   ...
   community: Community
}

For now, this community doesn't need to affect the results of the search. A future ticket will ensure that results are scoped to the community.

🙋‍♀️ Proposed Solution

Add community_id foreign key to both the PoolCandidateSearchRequest and the ApplicantFilter entities. (Schema type, eloquent model, and database tables.) It should a required non-nullable field on the search request, but optional in the filter. It is required on the search request because we will soon use it to control access. We will also use it to scope the results, hence being on the filter.

Note: we don't need to scope the results OR change access controls in this ticket. This is just setting us up for that.

An additional challenge:
If the migration adds a required (non-nullable) community_id field to the Requests table, what do we do about running the migration on systems with requests already in the database? We can do the matching in the mutation itself, but only if the Communities already exist. We likely need to blocking merging this until #10298 has been deployed and the seeder has been run.

🌎 Localization

(optional) Provide any new copy along with translations available.

✅ Acceptance Criteria

A set of assumptions which, when tested, verify that the debt was addressed and expected functionality has not been affected.

• All existing Requests associated with a Community in the database
• Any new Requests required a community
• The Community can be accessed from a Request in the api
• Creating new requests now requires selecting a Community
• The search page automatically sets the community on the request and filter based on the Pool Stream.
• Search request UI is unchanged

🛑 Blockers

Issues which must be completed before this one.

Blocked By

Beta Give feedback

1. [Feature] Creating the community model #10305
   deployment +1

[github-actions]

Status: Ready to merge ✔️

Issues blocking this PR:

• Create Spike template #10288 ✔️

---

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

[tristan-orourke]

Blocked until some Communities exist in production.

[petertgiles]

one-to-one relationship

Should be one-to-many, right? A community will have many requests.