✨ Backend model for Development Program

[tristan-orourke]

✨ Feature

Development Programs are training programs managed by a Community. They will start as a simple model, with relationships with Communities and Classifications. Users can express interest, which will be stored in a pivot table with their EmployeeProfile model. In a later ticket, it will be possible to nominate users for programs as well.

🕵️ Details

Development programs have:

• name
• description for profile
• description for nominations
• community (a required belongsTo relationship)
• a list of eligible classifcations (a belongsToMany relationship)

Additionally, CommunityInterest has a belongsToMany relationship to Development Programs, with additional data in the pivot table:

• participation status (NOT_INTERESTED, INTERESTED, ENROLLED, or COMPLETED)
• completion date

There's no need to add a top-level query for DevelopmentPrograms or the pivot records, as long as they can be queried on Communities and from CommunityInterest respectively.

We'll need to add a mutation allowing users to add or update the programs connected to their profile. The mutation should allow for syncing, connecting and detaching of multiple records to an EmployeeProfile. It should check the update-own-employeeProfile permission.

We can hold off on adding mutations to create the Development Programs themselves. I suspect the first batch will be added programmatically.

🎨 Design

@JoshBeveridge

Based on figma designs, though the current model has been simplified and I'm not sure if these designs are up to date yet.

Development Program from Applicant perspective

Development Program from Nominator perspective

📸 Screenshot

🙋‍♀️ Proposed Implementation

type DevelopmentProgram {
  id: UUID!
  name: LocalizedString
  descriptionForProfile: LocalizedString
  descriptionForNominations: LocalizedString
  community: Community # belongsTo 
  eligibleClassifications: [Classification] # belongsToMany
}

type Community {
  ...
  developmentPrograms: [DevelopmentPrograms] # These are public, don't require permissions to view.
}

# a pivot table for users to express interest in programs. Linked to CommunityInterest 
type DevelopmentProgramInterest { 
  program: DevelopmentProgram
  participationStatus: ParticipationStatusEnum # NOT_INTERESTED, INTERESTED, ENROLLED, COMPLETED. Maybe rename to interestStatus?
  completionDate: Date
}

type CommunityInterest {
  ...
  interestInDevelopmentPrgrams: [DevelopmentProgramInterest ] @belongsToMany # No need for extra permission check. If you can see this, you can see pivot record.
}

input DevelopmentProgramInterestInput {
  developmentProgramId: UUID!
  participationStatus: ParticipationStatusEnum
  completionDate: Date
}

input DevelopmentProgramInterestBelongsToMany {
  connect: [DevelopmentProgramInterestInput!]
  sync: [DevelopmentProgramInterestInput!]
  detach: [UUID!]
}

input UpdateCommunityInterest {
  ...
  interestInDevelopmentPrograms: DevelopmentProgramInterestBelongsToMany 
}

There's no need to add a top-level query for DevelopmentPrograms or the pivot records, they can be queried on Communities and on EmployeeProfiles.interestInCommunities respectively.

The mutation should allow for syncing, connecting and detaching of multiple records to a CommunityInterest record. It may be easiest to add fields to the mutation used in #12253 than to create a new mutation.

🌎 Localization

✅ Acceptance Criteria

• Models defined as described in schema
  • DevelopmentPrograms can queried via Communities, visible to anyone who can view the Community
  • The connection between Programs and Users can be queries via the EmployeeProfile, via the CommunityInterest record, visible to anyone who can view the EmployeeProfile
• Migrations for underlying tables; Laravel models; factories and seeders
• Employees can use a mutation to update development programs associated with a EmployeeProfile, protected by the 'update-own-employeeProfile' permission
• Validation ensures that when a DevelopmentProgramInterest is created, the CommunityInterest and the DevelopmentProgram it connects both use the same Community.

🛑 Blockers

Blocked By

Preview Give feedback

1. ✨Backend model for Community Interest #12253
   1 of 1
   feature +1
   

[tristan-orourke]

For additional discussion:

There should probably be a way for these programs to be hidden from applicants without deleting them. Perhaps an active flag, or open and close dates (which could potentially be left empty).

@JoshBeveridge has proposed combining this with the Training Opportunities advertised on the Instructor Led Training opportunities page, since they both represent training programs. This would mean merging the new model with the existing model:

type TrainingOpportunity {
  id: UUID!
  title: LocalizedString
  courseLanguage: LocalizedCourseLanguage 
  registrationDeadline: Date 
  registrationDeadlineStatus: LocalizedDeadlineStatus
  trainingStart: Date 
  trainingEnd: Date 
  description: LocalizedString
  applicationUrl: LocalizedString
  courseFormat: LocalizedCourseFormat 
}

We'd also have to migrate existing opportunities to belong to a community, and delegate responsibility for managing these opportunities to the CommunityAdmins. (If we don't plan to do that, I don't recommend merging the models). If we do that, we may want to consider #12086. (We made the decision to allow headers in our Rich Text editor with the explicit assumption that only Platform Admins would be using it.)

Additionally, we'd probably to want to add some additional fields controlling where the Training Opportunity / Development Program appears:

appearsOnInstructorLedOpportunities: Boolean
appearsInNominations: Boolean
appearsInCommunityInterest: Boolean # I'm not sure what to call this yet

[tristan-orourke]

An earlier, more complex version of the data model, saved for posterity:

Data model

type DevelopmentProgram {
  id: UUID!
  title: LocalizedString
  description: LocalizedString
  community: Community
  fundingRequirement: Int # dollar value
  durationRequirement: Int # in months?
  classificationRequirement: [Classification] # optionally requires candidate to be one of these classifications
  collectCohortPreference: Boolean # I don't really know what this is about
}

# a pivot table for users to express interest. Could use a better name?
type UserDevelopmentProgram { 
  program: DevelopmentProgram
  user: User
  participationStatus: ParticipationStatusEnum # NOT_INTERESTED, INTERESTED, ENROLLED, COMPLETED
  completionDate: Date
}

[gobyrne]

Thanks Tristan. This looks right to me. The list of classifications is for flagging eligibility. So "eligible classifications" or "target classifications" might serve as a better name.

[github-actions]

Status: Blocked ❌

Issues blocking this PR:

• ✨Backend model for Community Interest #12253 ❌

---

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