Fix hardcoded publication date default in webapp#1709
Open
jcschaff wants to merge 1 commit into
Open
Conversation
New publications defaulted their date to the literal "2023-12-28" in the publication-new form's onNew() template, and the date input on the edit form was commented out, so every publication created/edited via the webapp wrote 2023-12-28 to vc_publication.pubdate. - Default new publications' date to today (yyyy-MM-dd) instead of the literal. - Uncomment the Date input in the edit form so users can set/correct the date. Format (yyyy-MM-dd) round-trips through the OpenAPI Publication.date string and the backend @jsonformat("yyyy-MM-dd"); no client regen or backend change needed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
New publications were defaulting
vc_publication.pubdateto a hardcoded literal2023-12-28, and users couldn't change it.Two webapp causes:
publication-new.component.tsonNew()seeded the default Publication withdate: "2023-12-28"(placeholder scaffold data).<input>inpublication-edit.component.htmlwas commented out, so the placeholder propagated, unedited, all the way to the database.The backend was innocent —
PublicationResource.add()→PublicationService.savePublication()→DbDriverfaithfully stored whatever date the webapp sent. No2023-12-28literal exists in the Java/DB code.Changes
publication-new.component.ts: default new publications'dateto today (new Date().toISOString().slice(0, 10)→yyyy-MM-dd) instead of the literal.publication-edit.component.html: uncomment the Date input so users can set/correct the date.Compatibility
yyyy-MM-ddround-trips through the OpenAPIPublication.datestring and the backend@JsonFormat("yyyy-MM-dd"). No OpenAPI client regeneration or backend change required.Notes / follow-ups (not in this PR)
onNew()still contains other placeholder defaults (title: "title",authors: ["string"],doi: "doi", …) — out of scope here, but worth cleaning up to empty values.toISOString()is UTC, so the default date can read as "tomorrow" for users several hours behind UTC creating a publication late at night. It's only a default and now editable; can switch to a local-date computation if preferred.🤖 Generated with Claude Code