Handle PLDP Survey metadata
Closed this issue · 4 comments
In its current implementation, the django-pldp
Survey element has the following fields:
- location (required)
- study (required)
- time_start
- time_stop
- time_character
- representation
- microclimate
- temperature_c
- method
Some of these (study, location) should stay the same between administrations of the survey. Others (time_start, time_stop, time_character, microclimate, temperature_c) should change. I'm not sure which of those categories representation and method would best fit into. Let's make sure we're all on the same page about those categories.
I first outlined this issue here: #17 (comment)
In #56 I've implemented study, representation, and method as Fobi form elements. This means that they're added to surveys like any other question, the survey creator sets a default value for them, and then the survey runner can change them if they'd like.
I see two paths here:
- Study and location stay as form elements and I modify them so that they cannot be changed while running the survey. As these are required fields, don't allow users to save surveys that don't include these questions.
- Move study and location into the new survey creation form and save them as metadata there, meaning modifying the
django-fobi
FormEntry model. This is a heavier lift as it requires modifying the package, but may fit our data better and be worth the extra time.
A third path we're pursuing: subclassing FormEntry
to add our own fields! Working on it in #83. This means that some PLDP elements can be attached to the survey model and some can be components.
On survey model:
- location
- study
Components:
- total - according to PLDP, this will need to be a required field on all observational surveys
- time_start
- time_stop - right now I'm using this to record submission time. If this component exists we could override the submission time, or they could be separate
- time_character
- representation
- microclimate
- temperature_c
- method
@jeancochrane this issue is just for picking an approach, which I believe we've done. Did you want to include implementing this approach in this sprint as well? It's partially done but there's more to do (see checkboxes above)
My instinct is to go ahead and implement this, since subclassing fobi.models.FormEntry
turned out to be easier than anticipated.