Duplicate Publishable attributes in CommonModel + DOI in Dandiset as Optional #285
Conversation
…Optional That is necessary to later be able to make our model more restrictive and disallow addition of arbitrary attributes as it does now. ATM any Draft version of a dandiset which was already published at least once, would have those attributes although base Dandiset (similar in Asset model; @candleindark would check) does not have them defined. This is what this PR fixes. More details on how those were found and in which dandisets could be obtained from https://github.com/dandi/dandi-schema-status/blob/main/reports/diff_reports/dandiset/jsonschema_errs_summary.md#errs-diff-detailed-tables This should be "backward compatible" change at the level of the schema, as any prior valid record would remain valid. Hence just boosting the "patch" portion of the version
| # Our current draft dandisets could be coming from Published ones, | ||
| # and thus carry their attributes. So we would need to define them here as well | ||
| # but make them optional, and `Publishable` would overload to make | ||
| # them mandatory. |
There was a problem hiding this comment.
when published, the draft state should remove the published by component. or we need a better flow that allows owners to create a new draft state from the latest published record (instead of defaulting to creating one). originally the process mimicked github in that a release is a tag on a branch. we can evolve that to be a staged evolution. draft/unpublished -> published -> create draft/unpublished when any change is made by the owner. i.e. any modification creates a new staged state. when that happens irrelevant attributes can be removed.
but it can continue to have derivedFrom to indicate that this new unpublished state did come from a previous published state.
|
in addition to the general comment, i think we really need to spend a bit of focused time to revise the models in relation to linkml. we should arrange a time in the next few weeks with @candleindark @djarecka @yarikoptic and @satra (cc: @kabilar) |
That is necessary to later be able to make our model more restrictive and disallow addition of arbitrary attributes as it does now.
ATM any Draft version of a dandiset which was already published at least once, would have those attributes although base Dandiset (similar in Asset model; @candleindark would check) does not have them defined. This is what this PR fixes.
More details on how those were found and in which dandisets could be obtained from https://github.com/dandi/dandi-schema-status/blob/main/reports/diff_reports/dandiset/jsonschema_errs_summary.md#errs-diff-detailed-tables
This should be "backward compatible" change at the level of the schema, as any prior valid record would remain valid. Hence just boosting the "patch" portion of the version