Re: problem with csv export in master
On Dienstag, 8. August 2023 00:53:11 CEST Jack via KMyMoney-devel wrote:
> While trying to debug the problem recently reported on Discord about
> the 5.1.3 csv exporter truncating stock prices to 2 decimal places, I
> noticed that the master branch csv export always seem to export the
> same account, which is NOT the one I selected. In playing with that
> further, if I pick an investment account in the account dropdown, and
> then change the separator from tab to comma, I get the popup that the
> account is invalid because it doesn't have any items. In trying to
> figure out why that happens, I put a qDebug at the beginning of
> CsvExportDlg::checkData which prints out the selected account. When I
> select the account (any account) with the dropdown, the correct account
> name is printed. However, if I make or change the separator
> selection, a DIFFERENT account name is selected. So - it turns out I
> can export the selected account only if I choose the separator first,
> and then the account.
>
> Further, looking at CsvExportDlg::CsvExportDlg, I find the last three
> connect commads are:
>
> connect(ui->m_accountComboBox,
> qOverload(::currentIndexChanged), this, [this](int idx) {
> checkData(ui->m_accountComboBox->itemText(idx));
> });
> connect(ui->m_separatorComboBox,
> QOverload::of(::currentIndexChanged), this, [&](int
> index) {
> m_separator = m_fieldDelimiterCharList[index];
> } );
> connect(ui->m_separatorComboBox,
> qOverload(::currentIndexChanged), this, [this](int idx) {
> checkData(ui->m_accountComboBox->itemText(idx));
> });
>
> Commenting out the third out seems to fix the problem of the wrong
> account. This might make sense as it looks like that call is
> connecting a change of the separator combobox to to calling checkData
> with an incorrect account name (using the index of the separator
> combobox, not of the account combobox. However, I'm not sure how (or
> even if) calling checkData with the "wrong" account name can actually
> change which account gets exported, although it is perhaps by selecting
> the splits to be exported based on the wrong account.
>
> This post
> (https://stackoverflow.com/questions/16794695/connecting-overloaded-signals-and-slots-in-qt-5)
>
> related to the connecting of overloaded functions states that with
> C++11 you need QOverload<>::of(...) but with C++14 you need
> qOverload<>(...). This makes it look like our code has a mixture of
> both types of calls, and I wonder what subtle bugs this may have
> introduced.
This should better read "... but from C++14 on you can use qOverload<>(...)".
I noticed the mixed versions myself, but they don't hurt.
> I'll wait for some feedback before I actually try to fix this, while I
> continue to track down why the number of decimal places is truncated to
> 2 for prices and is too large for prices (which seems to be the same in
> 5.1 and master.)
I noticed the same yesterday when trying to figure out the decimal places
problem. I (mostly) rewrote the export dialog to fix all the problems. Once
I had this working, I noticed another problem with the csv exporter (at
least with investments): it seems to not add multiple fees/interest splits
thus giving false numbers in the export.
I did not have the time to finish the changes on the export dialog yesterday
but will commit it to the repo soon.
Since you already analyzed the old code you can now take a look at how
things are/can be done with the actual code base.
The decimal places code has another problem because prices are always written
with a precision of 6 digits. I leave it to you to change that to get the
security from the account and take the price precision defined for it.
--
Regards
Thomas Baumgart
-
My friend couldn't afford to pay his water bill.
So I sent him a 'get well soon' card.
-
signature.asc
Description: This is a digitally signed message part.
[kmymoney] [Bug 351535] Lost payee information when matched
https://bugs.kde.org/show_bug.cgi?id=351535 Bug Janitor Service changed: What|Removed |Added Resolution|WAITINGFORINFO |WORKSFORME Status|NEEDSINFO |RESOLVED --- Comment #4 from Bug Janitor Service --- This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 473128] New: Fetching currency conversions from fx-rate.net is broken
https://bugs.kde.org/show_bug.cgi?id=473128 Bug ID: 473128 Summary: Fetching currency conversions from fx-rate.net is broken Classification: Applications Product: kmymoney Version: 5.1.3 Platform: Ubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kmymoney-devel@kde.org Reporter: itors...@gmail.com Target Milestone: --- SUMMARY Cannot fetch currency conversions STEPS TO REPRODUCE 1. Run "Update stock and currency prices" from the menu OBSERVED RESULT Produces the following output: Fetching URL https://fx-rate.net/CAD/USD... Identifier found: 'CAD/USD' Date found: 'Mon. Aug. 7 2023' Unable to update price for CAD > USD (no price or no date) SOFTWARE/OS VERSIONS Linux (Ubuntu 23.04) KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 ADDITIONAL INFORMATION I tried looking at the regex contained at line 584 in "webpricequote.cpp". The problem seems to be that the output from fx-rate.net doesn't put a space inside the br tag. I think that adding a "*" after the "\s" in the br tag in the regex should fix the issue, but I haven't recompiled the source to make sure. -- You are receiving this mail because: You are the assignee for the bug.
problem with csv export in master
While trying to debug the problem recently reported on Discord about
the 5.1.3 csv exporter truncating stock prices to 2 decimal places, I
noticed that the master branch csv export always seem to export the
same account, which is NOT the one I selected. In playing with that
further, if I pick an investment account in the account dropdown, and
then change the separator from tab to comma, I get the popup that the
account is invalid because it doesn't have any items. In trying to
figure out why that happens, I put a qDebug at the beginning of
CsvExportDlg::checkData which prints out the selected account. When I
select the account (any account) with the dropdown, the correct account
name is printed. However, if I make or change the separator
selection, a DIFFERENT account name is selected. So - it turns out I
can export the selected account only if I choose the separator first,
and then the account.
Further, looking at CsvExportDlg::CsvExportDlg, I find the last three
connect commads are:
connect(ui->m_accountComboBox,
qOverload(::currentIndexChanged), this, [this](int idx) {
checkData(ui->m_accountComboBox->itemText(idx));
});
connect(ui->m_separatorComboBox,
QOverload::of(::currentIndexChanged), this, [&](int
index) {
m_separator = m_fieldDelimiterCharList[index];
} );
connect(ui->m_separatorComboBox,
qOverload(::currentIndexChanged), this, [this](int idx) {
checkData(ui->m_accountComboBox->itemText(idx));
});
Commenting out the third out seems to fix the problem of the wrong
account. This might make sense as it looks like that call is
connecting a change of the separator combobox to to calling checkData
with an incorrect account name (using the index of the separator
combobox, not of the account combobox. However, I'm not sure how (or
even if) calling checkData with the "wrong" account name can actually
change which account gets exported, although it is perhaps by selecting
the splits to be exported based on the wrong account.
This post
(https://stackoverflow.com/questions/16794695/connecting-overloaded-signals-and-slots-in-qt-5)
related to the connecting of overloaded functions states that with
C++11 you need QOverload<>::of(...) but with C++14 you need
qOverload<>(...). This makes it look like our code has a mixture of
both types of calls, and I wonder what subtle bugs this may have
introduced.
I'll wait for some feedback before I actually try to fix this, while I
continue to track down why the number of decimal places is truncated to
2 for prices and is too large for prices (which seems to be the same in
5.1 and master.)
Jack
[kmymoney] [Bug 473101] New: Payee Grouping Feature
https://bugs.kde.org/show_bug.cgi?id=473101 Bug ID: 473101 Summary: Payee Grouping Feature Classification: Applications Product: kmymoney Version: 5.1.3 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: kmymoney-devel@kde.org Reporter: ham...@yahoo.com Target Milestone: --- SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION It would be useful to have a capability/feature to group payees. Currently there is no mechanism that I'm aware of to either make explicit groups for payees or organize them logically using specific payee tags. This feature would be useful to generate reports/view payee groups like list of all tenants, certain business groups/vendors, utilities providers, health providers etc. -- You are receiving this mail because: You are the assignee for the bug.
