`StudyStatus.Configuring.canGoLive` should check for more data about carp.core-kotlin HOT 6 CLOSED

The case is to change the invitation name and description because it's a form that might be prone to users' error and changes. Unlike protocols that dictate what data to collect and other critical study information that should not be altered mid-study, invitations are less intrusive. They can be improved by simply adding a "thank you" note or feedback-based information. Given the flexibility of recruiting participants during the study and the semantic nature of invitations, they should be open to change.

from carp.core-kotlin.

For reproducibility reasons (how users are prompted is part of a study protocol, which ideally is also submitted as part of ethical approval, etc.), it is currently originally locked in. Correctly instructing the user of these consequences is a UI concern.

But, for flexibility reasons (not all studies have equally strict requirements), I did think ahead and didn't want to prevent changing invitations entirely. In short, it's a restriction in the current studies subsystem, but not in the deployments subsystem. Each invitation sent out gets stored separately in the deployments subsystem, so it should be possible to come up with a feature to change invitations in between deployed participants. Similarly, there may be a need to modify invitations depending on subgroups, etc.

It should thus be possible to implement this as a feature fairly easily, though it warrants some thinking on how to keep track of that if there is ever a need to link up invitations (different versions as managed in the studies subsystem) to participants; or, perhaps that's not a real requirement.

This can be added to the backlog, but I presume that means that the originally reported issue here is resolved/invalid?

from carp.core-kotlin.

Could you then create an issue for this feature? I mark this as closed for now.

from carp.core-kotlin.

Study.name isn't nullable. Do you perhaps mean empty string checking? Any additional constraints on name are best implemented as constraints when setting this property. But, I'm not certain this is warranted; the same restriction can easily be implemented on the UI without restricting the domain.

Study.description is nullable, and thus optional, by design. The domain does not prevent a study going live if no description is set. What is the motivation behind this, i.e., does every study need a description? Infrastructure decisions can always tighten these restrictions freely without impacting the domain.

Lastly, similar to Study.name and .description, Study.invitation.name also isn't nullable and .description is nullable by design.

Could you elaborate on your use case?

from carp.core-kotlin.

Then there is some inconsistency, because in this case you can start a study without setting the invitation, but you cannot change the invitation once the study is running. Because in this scenario we would probably want to be able to set the invitation when study is live.

from carp.core-kotlin.

Then there is some inconsistency, because in this case you can start a study without setting the invitation

You can't start a study without setting an invitation, since by default it is set to take the name of the study (which is facing the researcher and can be different from the study name for the participant). And, it can't be 'unset', only changed.

but you cannot change the invitation once the study is running. Because in this scenario we would probably want to be able to set the invitation when study is live.

You can't change the invitation once the study has gone live. Before, you can.

What is your use case for changing the invitation while some invitations may have already been sent out to participants and they may be collecting data?

from carp.core-kotlin.