Re: [kmymoney4] [Bug 360500] Unable to enter the same value in the No. field for more than 1 transaction.
On 14/03/16 18:45, Christian David via KDE Bugzilla wrote: https://bugs.kde.org/show_bug.cgi?id=360500 Christian David changed: What|Removed |Added CC||christian-da...@web.de --- Comment #3 from Christian David --- In void TransactionEditor::slotNumberChanged(const QString& txt): Why do you use loadText() and not setText() in you patch? There are two separate routines involved, and one was using loadText() and the other setText(). I couldn't see any reason for the difference, and just decided to use loadText(). However, the loadText() seems unnecessary to me. In the routine you refer to, then, yes, it does seem unnecessary, but not so in void TransactionEditor::assignNextNumber(). The first one there is necessary. Allan
[kmymoney4] [Bug 360500] Unable to enter the same value in the No. field for more than 1 transaction.
https://bugs.kde.org/show_bug.cgi?id=360500 --- Comment #4 from allan --- On 14/03/16 18:45, Christian David via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=360500 > > Christian David changed: > > What|Removed |Added > > CC||christian-da...@web.de > > --- Comment #3 from Christian David --- > In void TransactionEditor::slotNumberChanged(const QString& txt): > > Why do you use loadText() and not setText() in you patch? There are two separate routines involved, and one was using loadText() and the other setText(). I couldn't see any reason for the difference, and just decided to use loadText(). > However, the loadText() seems unnecessary to me. In the routine you refer to, then, yes, it does seem unnecessary, but not so in void TransactionEditor::assignNextNumber(). The first one there is necessary. Allan -- You are receiving this mail because: You are the assignee for the bug.
Re: Review Request 127108: Changed way of saving files which should fix some bugs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127108/ --- (Updated March 14, 2016, 9:32 p.m.) Review request for KMymoney. Bugs: 356399 http://bugs.kde.org/show_bug.cgi?id=356399 Repository: kmymoney Description --- Fixed potential memory leak during saving A pointer was not deleted before throwing exceptions in KMyMoneyView::saveFile. Also renamed the pointer. Changed way of saving files which should fix some bugs The save operation seems to fail every time - it never changed the orginal file and never reported any issues. I did not find the exact reason for this bug but I am quite sure it was caused by an incorret usage of QSaveFile (under some circumstances close() instead of commit() was called). Now KMyMoney creates its own temporary file to write to (if needed). This also works using KGpgFile, which should fix Bug 356399. The remove() and rename() operations are not atomic which is not so good as this could result in dataloss if the first operation fails. However, this is the best OS independet process I could find. Errors during writing of compressed files may not be detected. I think this issue should be fixed upstream. BUG: 356399 FIXED-IN: 5.0 REVIEW: 127108 Fixed bug while saving GPG encrypted files A call to QSaveFile::commit() was missing. So QSaveFile always assumed an error and discarded the changes. Used this fix for minor clean-ups. Diffs - CMakeLists.txt a82d70eed87c5f8a8052b969c0a8a17d82ef8b1d kmymoney/views/kmymoneyview.h c4a769c2bf88083ea56283d683d7f0f7f0466875 kmymoney/views/kmymoneyview.cpp 284bd6a2657982c25790b2428730f279fc86504c libkgpgfile/kgpgfile.cpp b1870be92edb833ed30f369e3e0ca0f320fe147b Diff: https://git.reviewboard.kde.org/r/127108/diff/ Testing (updated) --- I saved a file several times using the compressed, uncompressed and anonymous format. I could not test the GPG part because none of my keys is currently shown by the save dialog. New: I tested it with GPG encrypted files. Brand new: Tried to saved in locations I have no write premissions for, to non-existing folders, and write protected files. I tried hard to reproduce bug 256750 - everything seems to be alright. Thanks, Christian David
Jenkins-kde-ci: kmymoney master latest-qt4 » Linux,gcc - Build # 60 - Failure!
GENERAL INFO BUILD FAILURE Build URL: https://build.kde.org/job/kmymoney%20master%20latest-qt4/PLATFORM=Linux,compiler=gcc/60/ Project: PLATFORM=Linux,compiler=gcc Date of build: Mon, 14 Mar 2016 19:23:17 + Build duration: 46 sec CHANGE SET Revision d49b90d99cee61182efd0982516bdac4d02419ea by scripty: (SVN_SILENT made messages (.desktop file) - always resolve ours) change: edit kmymoney/plugins/weboob/kmm_weboob.desktop
Jenkins-kde-ci: kmymoney frameworks kf5-qt5 » Linux,gcc - Build # 50 - Failure!
GENERAL INFO BUILD FAILURE Build URL: https://build.kde.org/job/kmymoney%20frameworks%20kf5-qt5/PLATFORM=Linux,compiler=gcc/50/ Project: PLATFORM=Linux,compiler=gcc Date of build: Mon, 14 Mar 2016 19:23:17 + Build duration: 2 min 30 sec CHANGE SET Revision 0b66ce1ed339b6704f93f3516a4da6cea06a7acc by christian-david: (Coding style and replaced some const return values by non-const) change: edit kmymoney/kmymoney.h change: edit kmymoney/views/kmymoneyview.cpp change: edit kmymoney/kmymoney.cpp Revision 067b08757f954f5b694911a18c6d84943e3015a8 by christian-david: (Removed usage of kfiledialog:// urls) change: edit kmymoney/kmymoney.cpp Revision 1cf2e47b56163d0fb67c310a22f01e3bf2091ad2 by christian-david: (Removed any KDE4support dependencies from KBanking plugin) change: edit kmymoney/plugins/kbanking/widgets/chiptandialog.cpp change: edit kmymoney/plugins/kbanking/views/CMakeLists.txt change: edit kmymoney/plugins/kbanking/dialogs/kbpickstartdate.h change: edit kmymoney/plugins/kbanking/widgets/chiptandialog.h change: edit kmymoney/plugins/kbanking/dialogs/kbmapaccount.h change: edit kmymoney/plugins/kbanking/widgets/kbjoblist.cpp change: edit kmymoney/plugins/kbanking/widgets/CMakeLists.txt change: edit kmymoney/plugins/kbanking/dialogs/kbmapaccount.ui change: edit kmymoney/plugins/kbanking/dialogs/CMakeLists.txt change: edit kmymoney/plugins/kbanking/dialogs/kbmapaccount.cpp change: edit kmymoney/plugins/kbanking/CMakeLists.txt
Review Request 127376: Improved kgpgfile's cmake file
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127376/ --- Review request for KMymoney and Cristian Oneț. Repository: kmymoney Description --- Removed unnecessary commands. Added commands which might be needed. Patch is untested because I do not have access to an windows enviroment. The changes are partly based on an inspection of https://quickgit.kde.org/?p=kdewin.git&a=blob&h=54d8881dd060cef58663854222187cdc01d2839d&hb=817dc9f454d2a65a7b80e203ab34052cd07294e8&f=cmake%2Fmodules%2FKDEWinConfig.cmake.in KGpgfile should be KDE4support free. Feel free not to answer to this review request for a long time. I just wanted to put it somewhere. Diffs - libkgpgfile/CMakeLists.txt a41a6a408e3da8769308dae75d4f514aa969dc87 Diff: https://git.reviewboard.kde.org/r/127376/diff/ Testing --- Compiled on Linux. Thanks, Christian David
[kmymoney4] [Bug 330952] Incorrect interest value in a loan account
https://bugs.kde.org/show_bug.cgi?id=330952 Christian David changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||christian-da...@web.de Resolution|--- |INVALID --- Comment #25 from Christian David --- The date can be set on the "details" sheet. Changing it in the last step may change other settings from other steps. So deactivating it should be okay. As you requested I mark this bug resolved. Please feel free to reopen it if necessary. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360129] CSV Importer doesn't recognize sell operation in Polish
https://bugs.kde.org/show_bug.cgi?id=360129
--- Comment #16 from NSLW ---
(In reply to allan from comment #15)
> > > I know no Polish financial terms. If the Buy list contains a correct
> > > Polish
> > > term, then that I presume was added by the translator. A possible
> > > explanation is that at line 161 (in my version) of investprocessing.cpp
> > > the
> > > following appears - "m_buyList += i18nc("verb", "buy"); //
> > >
> > > some basic entries in case rc file missing". It may be that that was when
> > > the translation for Buy was added. However, the next line is similar for
> > > the Sell operation, and that was not translated apparently.
> >
> > All terms are and were translated.
>
> In the rc file snippet you attached, only Buy and Reinvdiv have content.
That's right and that also shows that KMM has bug inside.
Please see translation progress of KMM to Polish to know that it is translated
fully
http://l10n.kde.org/stats/gui/trunk-kf5/team/pl/extragear-office/
Please read also what I wrote you about the bug I'm seeing
> > After the patch my csvimporterrc is
> > filled out automatically with all the data whereas before the patch only
> > BuyParam and ReinvdivParam were filled out.
And finally please see into code of investprocessing.cpp
BuyParam and ReinvdivParam are assigned like this
QStringList list = profilesGroup.readEntry("BuyParam", QStringList());
if (!list.isEmpty()) {
m_buyList = list;
}
whereas other parameters and it includes SellParam is assigned like this
m_sellList = profilesGroup.readEntry("SellParam", QStringList());
and that's the reason why you don't see SellParam in rc file and not the
missing translation.
--
You are receiving this mail because:
You are the assignee for the bug.
[kmymoney4] [Bug 360500] Unable to enter the same value in the No. field for more than 1 transaction.
https://bugs.kde.org/show_bug.cgi?id=360500 Christian David changed: What|Removed |Added CC||christian-da...@web.de --- Comment #3 from Christian David --- In void TransactionEditor::slotNumberChanged(const QString& txt): Why do you use loadText() and not setText() in you patch? However, the loadText() seems unnecessary to me. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360129] CSV Importer doesn't recognize sell operation in Polish
https://bugs.kde.org/show_bug.cgi?id=360129
allan changed:
What|Removed |Added
Status|UNCONFIRMED |CONFIRMED
Ever confirmed|0 |1
--- Comment #15 from allan ---
(In reply to NSLW from comment #14)
> (In reply to allan from comment #13)
> > What I'm not sure about just now is whether, once the user has chosen to
> > make a substitution, that new term is added to the resource file
> > automatically. It's a few ears since I wrote that code.
>
> That's worth checking. That might be a second bug.
I'll check.
>
> > I know no Polish financial terms. If the Buy list contains a correct Polish
> > term, then that I presume was added by the translator. A possible
> > explanation is that at line 161 (in my version) of investprocessing.cpp the
> > following appears - "m_buyList += i18nc("verb", "buy"); //
> > some basic entries in case rc file missing". It may be that that was when
> > the translation for Buy was added. However, the next line is similar for
> > the Sell operation, and that was not translated apparently.
>
> All terms are and were translated.
In the rc file snippet you attached, only Buy and Reinvdiv have content.
>
> > I would suggest that you include both noun and verb versions for Sell in
> > your resource file.
>
> I already have them and it works for me.
>
> > > As it is now was also misleading to me, to today although I'm an fresh
> > > KMyMoney user :) and translator, so maybe another suggestion will sound
> > > better to an layman:
> > > "Type of operation as in financial statement"
> > >
> > That does sound more understandable, although it would have to be added to
> > every transaction type.
>
> I think you're right, is there any problem for it to be added to every
> transaction type?
Only in terms of bloat. However, if I create a single string, I can refer to
that instead of using the full version.
>
> > > > So, apart from the fee query, are you now in business?
> > >
> > > After manually editing csvimporterrc file, fee is imported just right for
> > > all operations. What do you mean by me being in business?
> >
> > Apologies for that. I'm extremely impressed by the general level of
> > knowledge of English shown by the users, and developers, and I forget myself
> > sometimes and lapse into the vernacular. "being in business" is used to
> > indicate that a problem has been solved and normal service may be resumed.
> > I hope it didn't cause offence.
>
> No, none at all. You've suggested me a workaround and it worked for me as
> expected.
>
> > So far as your suggested patch is concerned, I'm not sure of its purpose.
> > The Subject is "[PATCH] Read operation's type explicitly as QStringList",
> > and in it you add a number of QStringList definitions, which are already
> > included in investprocessing.h, c. line 164.
>
> I think that after my patch, every variable is defined anew locally, which I
> think is not clean way to do this and doesn't remove the source of the
> problem, but it works flawlessly. After the patch my csvimporterrc is
> filled out automatically with all the data whereas before the patch only
> BuyParam and ReinvdivParam were filled out.
> I tell you what, I'm going to see into the problem once again soon and I
> will try to find its source, cause I really want it to see it fixed.
>
> > Oh, and just as a post script, I've added "in Polish" to the bug heading, as
> > the import operation is otherwise as expected.
>
> I would say "in non-English"
Well, we don't know of any other problem, and it seems to depend on
translation, so I think I'll stick with the current version. It can always be
edited if needed in the future.
>
> Łukasz
--
You are receiving this mail because:
You are the assignee for the bug.
[kmymoney4] [Bug 360129] CSV Importer doesn't recognize sell operation in Polish
https://bugs.kde.org/show_bug.cgi?id=360129
--- Comment #14 from NSLW ---
(In reply to allan from comment #13)
> What I'm not sure about just now is whether, once the user has chosen to
> make a substitution, that new term is added to the resource file
> automatically. It's a few ears since I wrote that code.
That's worth checking. That might be a second bug.
> I know no Polish financial terms. If the Buy list contains a correct Polish
> term, then that I presume was added by the translator. A possible
> explanation is that at line 161 (in my version) of investprocessing.cpp the
> following appears - "m_buyList += i18nc("verb", "buy"); //
> some basic entries in case rc file missing". It may be that that was when
> the translation for Buy was added. However, the next line is similar for
> the Sell operation, and that was not translated apparently.
All terms are and were translated.
> I would suggest that you include both noun and verb versions for Sell in
> your resource file.
I already have them and it works for me.
> > As it is now was also misleading to me, to today although I'm an fresh
> > KMyMoney user :) and translator, so maybe another suggestion will sound
> > better to an layman:
> > "Type of operation as in financial statement"
> >
> That does sound more understandable, although it would have to be added to
> every transaction type.
I think you're right, is there any problem for it to be added to every
transaction type?
> > > So, apart from the fee query, are you now in business?
> >
> > After manually editing csvimporterrc file, fee is imported just right for
> > all operations. What do you mean by me being in business?
>
> Apologies for that. I'm extremely impressed by the general level of
> knowledge of English shown by the users, and developers, and I forget myself
> sometimes and lapse into the vernacular. "being in business" is used to
> indicate that a problem has been solved and normal service may be resumed.
> I hope it didn't cause offence.
No, none at all. You've suggested me a workaround and it worked for me as
expected.
> So far as your suggested patch is concerned, I'm not sure of its purpose.
> The Subject is "[PATCH] Read operation's type explicitly as QStringList",
> and in it you add a number of QStringList definitions, which are already
> included in investprocessing.h, c. line 164.
I think that after my patch, every variable is defined anew locally, which I
think is not clean way to do this and doesn't remove the source of the problem,
but it works flawlessly. After the patch my csvimporterrc is filled out
automatically with all the data whereas before the patch only BuyParam and
ReinvdivParam were filled out.
I tell you what, I'm going to see into the problem once again soon and I will
try to find its source, cause I really want it to see it fixed.
> Oh, and just as a post script, I've added "in Polish" to the bug heading, as
> the import operation is otherwise as expected.
I would say "in non-English"
Łukasz
--
You are receiving this mail because:
You are the assignee for the bug.
[kmymoney4] [Bug 360500] Unable to enter the same value in the No. field for more than 1 transaction.
https://bugs.kde.org/show_bug.cgi?id=360500 allan changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED Version Fixed In||4.8 Latest Commit||dc5109988fbf1f732525e6a6ec1 ||93903b472b632 --- Comment #2 from allan --- I think the intention in clearing the cell contents may have been to assist the user to enter the required value, perhaps. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360500] Unable to enter the same value in the No. field for more than 1 transaction.
https://bugs.kde.org/show_bug.cgi?id=360500 --- Comment #1 from allan --- Created attachment 97898 --> https://bugs.kde.org/attachment.cgi?id=97898&action=edit Fix for bug 306500 This is a trivial patch, and with developer time being scarce, I see no point in going via reviewboard. Unless I hear to the contrary, I propose to push it in about a week, in order to, hopefully, make it into rev 4.8. -- You are receiving this mail because: You are the assignee for the bug.
Re: precision in currency dialog for BTC accounts
Hi, You probably configured BTC to have two decimal places. The currency conversion dialog will represent the destination amount with the precision permitted by the destination currency. Regards, Cristian [1] https://docs.kde.org/stable4/en/extragear-office/kmymoney/details.currencies.html#details.currencies.newcurrency 2016-03-12 13:13 GMT+02:00 Felix Leimbach : > Hi, > > when transferring money between accounts with different currencies the > kcurrencycalculator.cpp dialog insists on rounding the target amount to two > decimal places. This is a problem for BTC accounts where higher precision is > required. > > In the global settings I've already set the precision to 8 decimal places. > Interestingly that does work for XAU denominated accounts, but not others. > > I'm running the latest stable (4.7.2) and have added the BTC currency as per > [1]. > I've tried the account types "Checking" and "Savings" for the BTC account but > it makes no difference. > > Is there a way to increase the precision? > > Thanks > Felix > > [1] https://bugs.kde.org/show_bug.cgi?id=307138
[kmymoney4] [Bug 360500] New: Unable to enter the same value in the No. field for more than 1 transaction.
https://bugs.kde.org/show_bug.cgi?id=360500 Bug ID: 360500 Summary: Unable to enter the same value in the No. field for more than 1 transaction. Product: kmymoney4 Version: 4.7.2 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kmymoney-devel@kde.org Reporter: bo...@yahoo.com v4.7.2 now requires to enter different values in the No. field for different transactions. This is annoying when the No. check field is used for other purposes than incremental cheque numbers, e.g. method of payment or the date for a deferred debit card. Now when entering a same value KMM asks whether to increment this value. If the answer is NO, the field is automatically erased and the transaction is entered with an empty No. field. In v4.6.6 I was able to enter the same value in different transactions, thus when I answered NO the field was not blanked out. Reproducible: Always Steps to Reproduce: 1. Enter a transaction with "XXX-01" in No. field 2. Enter a new transaction with same "XXX-01" in No. field 3. Actual Results: User will not be allowed to validate the 2nd transaction with the same "XXX-01" No. field. The No. field will either be erased or set to "XXX-02". Expected Results: User should be allowed to enter whatever he likes in the No. field if he decides not to use this field as an incremental cheque number field. That was the case in older versions of KMM. Please leave the options for No. field as they were in v4.6.6. I couldn't find any workaround to enter different transactions with a same value in the No. field. -- You are receiving this mail because: You are the assignee for the bug.
