Leave it to users to categorize their non-currency commodities. In the
QIF importer default non-classifiable commodities to
GNC_COMMODITY_NS_NONCURRENCY.
test arguments, deprecated as well as new mode arguments
test creating a session with a new xml file using __init__()
and begin(). Test raising exception when opening nonexistent
file without respective mode setting.
The previous fix didn't calculate the comparison time correctly and
ended up in the wrong day because the GMT time is before the local time.
In the course of checking the corner-case timezones (Midway and
Kiritimati) I found an error in the GncDateTime calculation of the
neutral time, so fixed that too.
Reported for Invoices on gnucash-user. Checked all other uses of
xaccTransSetPostDateSecs(), fixed the ones that weren't passing an
already normalized time64. For Invoices change the post_date to also be
normalized so that it stays the same as the transaction post_date. That
also protects it from the displayed date changing depending on timezone.
The python binding invoice post_time test had to be changed to match.
This switches swig to use python 3 specific features when generating the
bindings, switches the build over to python 3 and makes the neccesary
python 2 to 3 conversions in the bindings and tests.
unittest_support.py is in ${CMAKE_SOURCE_DIR} for a tarball build
and ${CMAKE_BINARY_DIR} for a vcs build. Look for it rather than
assuming it's in ${CMAKE_BINARY_DIR}.
Where possible in the Python SWIG code use the builtin SWIG conversion
code over custom code. This ensures appropriate overflow/type checking.
With this I have enabled GncNumeric from longs and tested for correct
overflow handling.
Note: This could be extended to GUILE but I am not familiar enought to
safely enable this.
At current the Python GncNumeric has issues with type conversion eg.
* GncNumeric(1.3) = 1.00
* GncNumeric("1.3") is OK but any future methods error
This behaviour was relied on for the Account tests to pass as it used
GncNumeric(0.5) == GncNumeric(1.0) but this is not what many users would
expect.
This fix alows GncNumeric to be constructed from a (int, int)
numerator/denominator pair or int/float/str where double_to_gnc_numeric
and string_to_gnc_numeric from C is used.
It is split into
- /libgnucash (for the non-gui bits)
- /gnucash (for the gui)
- /common (misc source files used by both)
- /bindings (currently only holds python bindings)
This is the first step in restructuring the code. It will need much
more fine tuning later on.
