Hi Maryam, This issue will be solved in the upcoming DSpace 8.0 release. As of 8.0, DSpace no longer sets the "dc.date.available" field by default (existing values in this field will still remain). The reason this has been removed is that the "dc.date.available" no longer accurately represented the correct date when an embargo existed, as Embargoes <https://wiki.lyrasis.org/display/DSDOC8x/Embargo> are now stored on the Item's resource policy (and not in metadata).
See the "Breaking Changes" <https://wiki.lyrasis.org/display/DSDOC8x/Release+Notes#ReleaseNotes-BreakingChanges> section of the 8.0 Release Notes for more details. This change will not be backported to 7.x as it's considered a "breaking change" (changes the default submission behavior). But, you could manually backport it yourself by making the code changes in https://github.com/DSpace/DSpace/pull/9103 to your 7.x instance. Tim On Friday, May 24, 2024 at 1:48:49 PM UTC-5 uali...@gmail.com wrote: > Hello Everyone, > > Some ETDs are under an embargo for a set period of time. In those cases we > supply a dc.date.available field with the date the embargo lifts (and so > the content will be accessible) as the value. DSpace seems to create > a dc.date.available field upon submission with the date and time the item > was submitted. I wanted to know if it would be possible to not create a > dc.date.available field if one is already included in the metadata? > if yes, in which file I should make changes? > > Sincerely yours, > Maryam > -- All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/56c3db66-f736-4953-8190-a520cb66fde0n%40googlegroups.com.
