castellum issueshttps://git.mpib-berlin.mpg.de/groups/castellum/-/issues2024-01-10T09:33:23Zhttps://git.mpib-berlin.mpg.de/castellum/castellum/-/issues/165Error "no such column: rowid" in development setup2024-01-10T09:33:23ZBengfortError "no such column: rowid" in development setupWhen running `make` on a fresh checkout, the migrations for the contacts database fail with the following error message:
```
django.db.utils.OperationalError: error in trigger ISO_metadata_reference_row_id_value_insert: no such column: ...When running `make` on a fresh checkout, the migrations for the contacts database fail with the following error message:
```
django.db.utils.OperationalError: error in trigger ISO_metadata_reference_row_id_value_insert: no such column: rowid
```https://git.mpib-berlin.mpg.de/castellum/study-registration/-/issues/6[Feature request] Add additional input fields per deploy target2023-07-19T14:41:36ZPhilip Jakob[Feature request] Add additional input fields per deploy targetHey,
Is there a possibility to add additional fields for certain deploy targets, which a user can/must fill in during deployment? E.g. if a conda environment should be created or if the website has to be publicly accessible.
That would...Hey,
Is there a possibility to add additional fields for certain deploy targets, which a user can/must fill in during deployment? E.g. if a conda environment should be created or if the website has to be publicly accessible.
That would be cool!
Thanks,
Philiphttps://git.mpib-berlin.mpg.de/castellum/study-registration/-/issues/5[Feature request] Optional commit constraint per target2023-07-03T10:01:30ZPhilip Jakob[Feature request] Optional commit constraint per targetHey,
We have thought about omitting the commit field selection on certain development targets. This would allow scientists to develop better because the specified branch would always be updated automatically. However, for production sys...Hey,
We have thought about omitting the commit field selection on certain development targets. This would allow scientists to develop better because the specified branch would always be updated automatically. However, for production systems, especially if they are accessible from outside, a specific commit should still be specified, which must be explicitly updated in redeployment.
Could deploy targets be given an option whether to require a commit hash or not?
Thanks,
Philiphttps://git.mpib-berlin.mpg.de/castellum/castellum/-/issues/146Redundancy between study type, session name, resource, tags2021-10-27T15:54:32ZBengfortRedundancy between study type, session name, resource, tagsFor studies with a focus on MRI it is not uncommon to mention MRI in all of `StudySession.study_type`, `StudySession.name`, `StudySession.resource`, and `Study.tags`.
These fields are clearly not all the same, but there *is* a big overl...For studies with a focus on MRI it is not uncommon to mention MRI in all of `StudySession.study_type`, `StudySession.name`, `StudySession.resource`, and `Study.tags`.
These fields are clearly not all the same, but there *is* a big overlap.
- `StudySession.study_type` has been pushed around quite a lot. In !1352 it was moved from `Study` to `StudySession`. In !2094 we move the external event feed from study type to resource. Today it can be used to filter the study list and to express disinterest in certain study types.
- `StudySession.name` is a necessary evil to distinguish sessions. We could also automatically generate a name from its position in the study, maybe mixed with some other information such as study type or resource.
- `StudySession.resource` plays an important role in our appointment system: Two appointments can not use the same resource at a time. Since !2094 we also assume that there may be external event feeds for resources (rather than for study types).
- `Study.tags` feel a bit pointless right now. They are not displayed anywhere. They are considered in search, but that is not explained anywhere. Their selling point is that they can be created by study coordinators, while study types can only be created by admins. They are also much more obvious in the study creation UI. At MPIB they are either used as academic keyword (e.g. "quantitative reasoning" or "reinforcement learning") or like study types (e.g. "online questionnaires" or "fMRI"). In !1805 they were rename to "tags" from "keyword" to move away from academics and also use them for things like research groups. This doesn't seem to have worked on a UX level.