Comments (6)
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.
Related Issues (20)
- TypeScript types passed between modules cause incompatible type warning requiring cast to `any` HOT 1
- Deserializing Measurement fails when using custom data types HOT 5
- TypeScript export for `Nullable` is missing HOT 7
- Need to know the version tag for a StudyProtocolSnapshot HOT 1
- Add phone number input data type HOT 3
- Redundant data type descriptors on data stream data points
- Add informed consent input data type HOT 2
- Add Social Security Number as Input Data Type HOT 4
- Inherited properties are missing from StudyProtocolSnapshot TS class
- Add participants to studies identified through other mechanisms than email HOT 4
- Consistent formatting for JSON type identifiers
- Disallow custom/extending types in CARP namespaces
- Specify input data type for `CustomParticipantAttribute` instead of generating one
- Allow study subsystem to retrieve input elements for participant attributes
- Personal identifiable information (PII) in the deployment subsystem
- List unsupported browsers (user agents) in `Website` device
- Serializing "unknown types" on JS release throws exception HOT 1
- Add deployment warning on invalid expected participant data
- Need the study ID in the study invitation HOT 3
- Need more endpoints for getting data in the Data Service
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from carp.core-kotlin.