Repository navigation
Conversation
bahman026
requested review from
elzody,
grnd-alt and
luka-nextcloud
as code owners
December 8, 2025 12:36
bahman026
force-pushed
the
prevent-invalid-year-input
branch
4 times, most recently
from
December 9, 2025 14:31
a39498a to
d4898e5
Compare
rakekniven
force-pushed
the
prevent-invalid-year-input
branch
from
December 20, 2025 10:50
bbb003d to
1c77d11
Compare
Contributor
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
luka-nextcloud
approved these changes
Jan 8, 2026
bahman026
force-pushed
the
prevent-invalid-year-input
branch
from
May 18, 2026 09:13
f1367fc to
72c807d
Compare
bahman026
force-pushed
the
prevent-invalid-year-input
branch
from
May 18, 2026 09:17
72c807d to
7986cfb
Compare
bahman026
force-pushed
the
prevent-invalid-year-input
branch
4 times, most recently
from
May 18, 2026 10:10
3fa2f80 to
08157ee
Compare
Signed-off-by: Bahman Jafarzadeh <bahman026@gmail.com>
Signed-off-by: Bahman Jafarzadeh <bahman026@gmail.com>
Signed-off-by: Bahman Jafarzadeh <bahman026@gmail.com>
Signed-off-by: Bahman Jafarzadeh <bahman026@gmail.com>
bahman026
force-pushed
the
prevent-invalid-year-input
branch
from
May 31, 2026 07:04
08157ee to
9be1702
Compare
Signed-off-by: bahman <42313073+bahman026@users.noreply.github.com>
The 'date' rule only accepted two of the formats that the API actually receives, and relied on \DateTime to reject the rest. \DateTime silently misreads out of range input instead of failing: '12345-01-01' is parsed as 2005-01-01 12:34. Such a value is written to the DATETIME column but can no longer be read back, which leaves the card permanently broken. Match the value against an explicit list of accepted formats and reject overflowing components (month 13, February 30), which createFromFormat() only reports through its warnings. An empty value stays valid so optional dates can be unset. Validate startdate the same way as duedate, and check both of them on create() as well - previously only update() checked duedate, so an invalid date could still enter the database through card creation. On the frontend, bound the native datetime-local input on both ends instead of only the upper one, so a year like 20250 can no longer be typed. Signed-off-by: bahman026 <bahman026@gmail.com>
…r-input # Conflicts: # lib/Service/CardService.php
The start date ends up in the same DATETIME column as the due date and is now validated the same way server side, so the picker needs the same range. Without it a year like 20250 is still accepted by the input and only rejected once the request reaches the validator. Move the two bounds into a shared helper rather than repeating them in both selectors. Signed-off-by: bahman026 <bahman026@gmail.com>
createFromFormat() does not bound 'Y' to four digits - it consumes as many digits as it finds, so '12345-01-01' and '20250-12-09 04:30:00' parse cleanly and produce no warnings, and the format list alone let them through. Compare the parsed year against the range the DATETIME column can hold, which is also the range the date pickers now offer. Signed-off-by: bahman026 <bahman026@gmail.com>
Author
|
Hi @luka-nextcloud, Following your approval, I’ve extended the fix with a few additional validations:
The latest commits are currently waiting for CI approval. Could you please approve the workflow runs and review the updated changes when you have a chance? Thank you. |
This branch has not been deployed
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
2 participants
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
This PR fixes an issue where a user can manually enter an invalid year in the due date input (for example: 20250).
Although the UI displays a date picker, users can still type values directly into the datetime-local field. When an invalid 5-digit year is submitted, it is saved in the database without validation.
After refreshing the page, PHP throws an error such as:
Before:
Because of this invalid date, the card cannot be edited or updated again until the entire board is deleted.
screen-capture.mp4
After:
capture.mp4
Checklist