Bug 317543 - Validity of transaction date not recalculated on change of date
Summary: Validity of transaction date not recalculated on change of date
Status: RESOLVED WORKSFORME
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: git (master)
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-29 14:00 UTC by Ian Neal
Modified: 2014-07-31 08:13 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Neal 2013-03-29 14:00:19 UTC
If you try to enter a transaction with a date prior to account opening, the date turns red (correctly) and won't let you proceed but changing the date to one later than account opening does not make the date turn non-red.

Reproducible: Always

Steps to Reproduce:
1. Open KMyMoney
2. Go to Ledger and select an account
3. Make a note of account opening date (e.g. 1st Jan 2013)
4. Start entering transaction into account (date gets populated with today's date)
5. Alter the date to 1st Dec 2012 (does not turn red yet)
6. Enter payee/payer and category (date turns red after category entered)
7. Alter the date to 1st Feb 2013 (does not turn non-red)
Actual Results:  
Transaction cannot be entered despite date being a valid one.

Expected Results:  
Transaction can be entered.

Date validity only seems to be recalculated when the category is changed, this means that transactions that should be valid cannot be entered and ones that are not valid, can be.

Workaround is to go to category field, delete a single character and re-enter it, date validity is then recalculated.
Comment 1 Cristian Oneț 2014-07-31 08:13:24 UTC
I can't reproduce this anymore since the date turns red and back immediately after I cross the account creation boundary back and forth. This must have been fixed in the meantime.