Add participants to studies identified through other mechanisms than email about carp.core-kotlin HOT 4 OPEN

1. Is there a need for them to be able to "login" again after having completed the study? E.g. the next day, for another round of data collection, or to communicate with the researcher.
2. If so, is there a need for them to set up a login in any way? Or, the expectation is they hold on to the link to revisit the webpage/study?

The answer to the questions is most likely yes, so we are proceeding with UsernameAccountIdentity.

@Whathecode was there a specific reason for the current RecruitmentService.AddParticipant to take EmailAddress instead of EmailAccountIdentity?

from carp.core-kotlin.

@Whathecode was there a specific reason for the current RecruitmentService.AddParticipant to take EmailAddress instead of EmailAccountIdentity?

Yes. Application service endpoints reflect API endpoints. The caller potentially doesn't need to know about account identities. Letting them create the concrete type at best achieves exactly the same, but at worst may leak implementation details unnecessarily.

However, if we do expect more extensibility of account identity (as indicated in the description of this issue, this was currently not considered), the abstraction will necessarily need to be lifted out into the API. And, a single endpoint which takes a polymorphic account identity would make most sense.

It sounds like the current needs fit more with what was originally anticipated, so instead, we should probably just add an endpoint for username/password specifically. How to deal with naming in that regard may warrant some discussion.

from carp.core-kotlin.

I think there is not a whole lot to this issue, now that I have looked into it: in most of the places it seems that AccountIdentity was used instead of just EmailAddress/EmailAccountIdentity. What I've just realized though, is that core supports api migrations (which is pretty cool). This made me think: should I, instead of adding a new request to RecruitmentService, just change addParticipant and migrate the request for anyone using a lesser minor version?

@Whathecode In general when would you do an api migration?

from carp.core-kotlin.

I'd always do an API migration if it means a cleaner API. The point of the migration strategy is to be able to do traditionally breaking changes without any impact.

The bigger question is: what is a good API here? A single generic call which requires the caller to care about AccountIdentity (I don't think they do yet), or separate calls per concrete type?

I think the former is preferred if the type is already exposed through one of the types in the current API (consistency) or when it needs to be an extendable type (custom account identity implementations). The latter if these assumptions are unlikely to hold.

from carp.core-kotlin.