Open Whathecode opened 3 years ago
Once these requests are introduced, RecruitmentService.inviteNewParticipantGroup
should be marked as deprecated. The concurrent implementation can lead to errors when the dependent DeploymentService
is down. Eventual consistency should be used instead (#295).
I'm not very clear with the plan for staged participation group, it seems to me this notion have 3 purpose:
Recruitmetn.participantGroups
AssignedParticipantRoles
or connectedDevicePreregistrations
For (2), those information should be removed after the group is invited, since Deployment is then responsible for role/device assignments.
For (3), it sounds redundant with Deployments.ParticipantGroup
, since it contains consent and participant data, but we also have issue on #464
Other things to consider:
Deployment.ParticipantGroup
in created and invited when Deployment
is created through ParticipantGroupService.createAndInviteParticipantGroup
. It can go other-way around, we can create participant group, then later on invite it, and create study deployment when the group is invited.Recruitment Repository
as the number of deployments increase.DeploymentServiceRequest.CreateStudyDeployment
, study/recruitment can not track deployments created directly through this method. same thing might also applies to Stop
.
The backend now has the notion of "staged" participant groups: sets of participants with assigned master devices before they are deployed. https://github.com/cph-cachet/carp.core-kotlin/issues/255
But, we are still missing endpoints to add/remove/change device assignments in the application service.