I have been entering bank interest into my savings account from the statement. The form prepopulates date but when I go from say 30/09/2015 it changes 31 back to 30 but I am trying to enter 31/10/2015 which is a valid date. Reproducible: Always Steps to Reproduce: 1. Enter a transaction into Transaction Input Form dated 30/09/2015 2. Enter 31 into the date field and note that it is changed back to 30. Expected Results: Validation for days in month below 31 should not be done until day and month entered or prepopulated date data confirmed. I use dd/mm/yyyy format.
*** Bug 354935 has been marked as a duplicate of this bug. ***
This is an underlying KDE function, not KMM, but I believe it is behaving correctly. The date displayed always needs to be a valid date, so if you have year 2015 and month 9, then 31 is not a valid day. The widget does not know you are planning on changing the month. If it let you set the date to 31, you might then hit OK, which would not be valid. I think most users would rather have to change the year or month first, rather than get an "invalid date" popup when they hit OK. I suppose this could be changed to a wishlist, but I'm not sure how the widget could assume an invalid day means a pending change to month or year, and how long to wait for such a change before either reverting or popping up an error. I also have not idea what this widget has been replaced with in the move to frameworks.
(In reply to Jack from comment #2), short but no disrespect intended. > This is an underlying KDE function, not KMM, . The source is irrelevant - it is part of the program. I could I raise this to the KDE function area but I am sure that they would consider it an inappropriate function for a day first format anyway. (BTW Where would I raise it, I would like to ask them to change their documentation.) > but I believe it is behaving correctly. . Clearly not - as I have described. It is just not a valid validation technique for a day first date. > The date displayed always needs to be a valid date . Agreed. > so if you have year 2015 and month 9, then 31 is not a valid day. The widget does not know you are planning on changing the month. . Then the widget has the wrong assumption built in - a bug. > If it let you set the date to 31, you might then hit OK, which would not be valid. . I agree if OK or enter was executed then an invalid date would be entered but there are other ways of moving on within the date field which would not involve entering an invalid date. > I think most users would rather have to change the year or month first, rather than get an "invalid date" popup when they hit OK. . I agree, but no users with a day first format accept this. Change your configuration and try it on 10 end on month transactions such as interest payments - I'm sure you will agree. Maybe a configuration option is required to change validation (or disable) for a day first format. (Like saying most people are shorter than 180 cm so we can have a laser beam set to 180 cm height - sucks for the exceptions.) > I suppose this could be changed to a wishlist, . No it is a bug because it does not process the date that I am entering correctly but I accept that it is not a priority > but I'm not sure how the widget could assume an invalid day means a pending change to month or year, and how long to wait for such a change before either reverting or popping up an error. . See above - validate after date entered. > I also have not idea what this widget has been replaced with in the move to frameworks.
The problem here is caused by the fact that class kMyMoneyDateInput which provides this widget used internal QDateEdit and QDateEdit does not support entering invalid dates. To fix this issue I think a refactoring or reimplementation of class kMyMoneyDateInput is required. It probably will use internal a QLineEdit instead of the QDateEdit and needs to perform the date validation checks by itself. The public api is listed below: class KMM_WIDGETS_EXPORT kMyMoneyDateInput : public KHBox { explicit kMyMoneyDateInput(); ~kMyMoneyDateInput(); QDate date() const; void setDate(QDate date); void setMaximumDate(const QDate& max); void loadDate(const QDate& date); void resetDate(); QWidget* focusWidget() const; void setRange(const QDate & min, const QDate & max); void markAsBadDate(bool bad = false, const QColor& = QColor()); }
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Someone else will have to test this. This issue was so frustrating I moved to other software. Just set date to dd/mm/yy and enter day 31.
Created attachment 153524 [details] Widget showing invalid date is possible The current master branch supports that as you describe it. The feedback now is to draw a red frame around the widget to identify that the value currently in the widget is invalid as shown in the attached screenshot.