Open bardram opened 5 months ago
That sounds trivial/easy enough to include! It would have to live in the studies subsystem, since this type of personal information should be kept out of the deployments subsystem.
The only endpoint in the studies subsystem where this currently could belong is in RecruitmentService.inviteNewParticipantGroup
. It takes a group
which currently only contains participant role assignment.
But, the requirement to edit staged participant groups was already listed before: Endpoints to edit staged participant groups And, implementing this is planned to deprecate inviteNewParticipantGroup
.
This issue is thus dependent on #319, after which it is a simple matter of adding a "name" field to the studies subsystem's ParticipantGroup
(The current StagedParticipantGroup
may be a misnomer, since I see no clear reason not to allow changing the name after deployment. It is currently named staged since device assignment can't be changed after deployment).
Would it be okay to have this name
field be nullable? The front-end could render a default name concatenating the currently assigned participants to the group in case the field is null
. Making it a required field seems unnecessary.
Right now a participant group / deployment only has a UUID. This is not very userfriendly, so we need to be able to have a name to the group. In the portal we right now just merge the participants names like this
But - we should be able to add a prober name like "Family Bardram".