DOC: embargoedUntil -- extend semantic to be able to mark with the date when it was unembargoed#143
DOC: embargoedUntil -- extend semantic to be able to mark with the date when it was unembargoed#143yarikoptic wants to merge 1 commit intomasterfrom
Conversation
|
this will cause a change to the schema. but i think the field can be used when unembargo happens. so i would suggest doing the archive change first and use the field. in terms of provenance, i've talked about a full audit log that's different from the schema. i think it should be prioritized once current issue are resolved. cc/ (@waxlamp) |
rright... since such a minor change as a doc, I think we could make it just a patch and delay actual release until some other change "pushes it out"
coolio, so we are inline in our thinking then. Filed dandi/dandi-archive#1286 |
|
ok, I will move it to draft, and say that it is blocked by dandi/dandi-archive#1286 |
…te when it was unemabroed The motivation is to (ab)use this metadata field to enable annotating dandisets which were unembargoed in the archive. ATM it would be impossible (?) to tell from dandiset metadata if it was unemabrgoed since we do not carry much (if any) of provenance. Whenever we unemabrgo a dandiset we could use this field then to fill-in datetime for when it was unembargoed, which would actually be "semantically" correct since that would be the date time until when it was embargoed. Of cause if the intention of this field is more of "unembargoUntil" (so no "done" notion), then it must remain as is Conflicts: dandischema/models.py -- so much water since old days
yarikoptic
force-pushed
the
enh-unembargoed
branch
from
6b81226 to
ebe4e5c
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #143 +/- ##
=======================================
Coverage 97.92% 97.92%
=======================================
Files 18 18
Lines 2405 2405
=======================================
Hits 2355 2355
Misses 50 50
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
well -- as it appeared to be a chicken/egg issue as someone should do it first, and as schema is the "driver" here -- I will likely to proceed with this PR first so archive would 'match' the doc spec eventually ;) |
Fixes #1286 When a dandiset transitions from EmbargoedAccess to OpenAccess, record the actual unembargo timestamp in the embargoedUntil field, replacing the original embargo end date. The logic is in Version._populate_access_metadata() which detects the status transition and sets the timestamp at that point. See dandi/dandi-schema#143 for field semantics. Co-Authored-By: Claude Code 2.1.63 / Claude Opus 4.6 <noreply@anthropic.com>
Fixes #1286 When a dandiset transitions from EmbargoedAccess to OpenAccess, record the actual unembargo timestamp in the embargoedUntil field, replacing the original embargo end date. The logic is in Version._populate_access_metadata() which detects the status transition and sets the timestamp at that point. See dandi/dandi-schema#143 for field semantics. Co-Authored-By: Claude Code 2.1.63 / Claude Opus 4.6 <noreply@anthropic.com>
2 participants
The motivation is to (ab)use this metadata field to enable annotating dandisets which were unembargoed in the archive. ATM it would be impossible (?) to tell from dandiset metadata if it was unemabrgoed since we do not carry much (if any) of provenance. Whenever we unemabrgo a dandiset we could use this field then to fill-in datetime for when it was unembargoed, which would actually be "semantically" correct since that would be the date time until when it was embargoed. Of cause if the intention of this field is more of "unembargoUntil" (so no "done" notion), then it must remain as is.
If merged -- TODO: file an issue with dandi-archive to fill-in this field (possibly overwriting an existing value) upon "unembargo" action for the dandiset.