Mike Alexander brought this up with a test case that failed to round down
sufficiently; he found that reducing the rounding denominator by 2 sufficed
to make his test case pass.
In fact the sizing of the replacement denominator by shifting the larger of
the numerator or denominator by an arbitrary 62 bits was not correct most
of the time, so instead we begin with a shift of the full lower leg worth,
try to do the conversion, and if the conversion is still “big” shift the
larger value one more and try the operation again, repeating until the
result will fit in a GncNumeric.
Fixing Bug 779217 increased the maximum denominator by 10, and that led
to overflows when converting large numbers' denominators from 100 to the
new max.
Correct the cell save routine so that the "numeric" kvp is correctly
overwritten in all instances when an edit changes its value for both
credit and debit splits. The both part is accomplished by extracting the
overwrite function.
Also provide a scrub to correct all of the incorrect files.
Unfortunately the necessary calculation function is in app-utils so
running the scrub from the backend as usual isn't possible, so we run it
from gnc_post_file_open in gnome-utils/gnc-file.c instead.
This patch simplifies the previous patch so it does not care where the
file is opened from. If it is in the history list and does not exist,
the dialog advises of this and asks if it should be removed from the
list other wise the dialog displays file not found.
- cleanup whitespace
- add import-pending-matches.c to POTFILES.in
- convert asserts into g_return(_val)_if_fail
- handle the case where no matches are found (which can happen at least in the csv importer and I suspect in the OFX importer as well)
Track pending matches from the current import and display this information in
the match picker.
Conflicts:
src/import-export/gschemas/org.gnucash.dialogs.import.generic.gschema.xml.in.in
src/import-export/import-match-picker.c
https://bugzilla.gnome.org/show_bug.cgi?id=739571
Total Debits Issue re $0 Commodity Accounts and Price Source Mode Set to
"Nearest in Time" or "Most Recent"
There was a silent error from gnc-numeric-sub-fixed in
collect-unrealized-gains because a 0 value wasn't getting its
denominator set in the gnc-numeric-mul call in
gnc:exchange-by-pricedb-helper. While this is ultimately a flaw in
gnc-numeric, this commit works around it by forcing the value to the
correct denom in gnc:make-commodity-collector.
Unfortunately running glade-3 on this file will reorder it completely. So this
commit is only made ad interim to be able to isolate the actual change in the
subsequent one.
Remove incorrect week adjustments for determining n for nth weekday
from a recurrence date when day % 7 == 0. Adjustment is only needed
in nth_weekday_compare because that function then adds 7 to the result.
The symptom was that in 2017 the PDT->PST transition was set a week
late. The cause was that the timezone lookup function went the wrong
way, finding the *next* timezone rule instead of the desired one because
timezone rules are stored for the year that they start rather than when
they end. Fix reverses the search to find the correct timezone rule.
Commit includes new tests to detect the problem.
