> On Oct. 20, 2013, 7:27 p.m., Allan Anderson wrote: > > File Attachment: Part 2 - 0001-BUG-319801 REVIEW:113143 - Fix losing track > > of check numberB.patch > > <http://git.reviewboard.kde.org/r/113143/#fcomment123> > > > > This is the second patch, for which I did an 'add file', and which > > possibly I should not have done.
when I added this comment, I did not get the 'publish' option, so tried again. - Allan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113143/#review42035 ----------------------------------------------------------- On Oct. 20, 2013, 7:15 p.m., Allan Anderson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/113143/ > ----------------------------------------------------------- > > (Updated Oct. 20, 2013, 7:15 p.m.) > > > Review request for KMymoney. > > > Bugs: 319801 > http://bugs.kde.org/show_bug.cgi?id=319801 > > > Repository: kmymoney > > > Description > ------- > > If a user's sequence of check numbers is broken by, say 'ATM' or an invoice > number such as 'No 123-001 ABC', the next check number produced will be '1', > entries containing alpha or punctuation characters not being saved. > The fix corrects this by saving the complete entry, and uses any entered > numeric part to calculate the next number in sequence. If an existing > numeric entry is edited, this entry will be taken into account for the next > number. > > There are some quirks. If the entry which led to the current 'next number' > is deleted, it is not possible to revert to the previous, now forgotten, > 'next number', so the produced 'next number' is likely to leave a 'gap', and > may need editing. Also, there is no check that a new 'next number' does not > already exist. For instance, if there is the erroneous sequence 23,23,24, > the 'next number' will be the expected 25. However, if the user corrects the > error by changing a 23 to 22, the new 'next number' will be 23, which also > already exists. I'm not sure if such issues, which exist also in the current > release, are worthy of fixing for a fairly unimportant area, without becoming > more involved. > > > Diffs > ----- > > kmymoney/dialogs/transactioneditor.h f07dafb > kmymoney/dialogs/transactioneditor.cpp 71d94ec > kmymoney/kmymoneyutils.h f64a55e > kmymoney/kmymoneyutils.cpp 7058557 > > Diff: http://git.reviewboard.kde.org/r/113143/diff/ > > > Testing > ------- > > Many manual entries checked, including coping with all values in the unit > tests. The unit test runs OK. > > > File Attachments > ---------------- > > Part 2 > > http://git.reviewboard.kde.org/media/uploaded/files/2013/10/20/7aac2cee-e36f-466f-995f-d80c526094c3__0001-BUG-319801_REVIEW113143_-_Fix_losing_track_of_check_numberB.patch > > > Thanks, > > Allan Anderson > >
_______________________________________________ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel