SX splits and regular splits have different requirements for Kvp. A
regular split's Kvp contains information that applies to that one split
alone so it would be a mistake to propagate it into SX. Meanwhile the SX
split puts its formulas in Kvp, and we certainly don't want those going
into regular splits.
Add an option to the File->Properties dialog to select a Currency Accounting Method, and to specify the book-currency and a default gains/loss policy if the 'book-currency' method is selected.
Revert some changes made in prior commits. Other than storing and retrieving the
book-currency and policy in book KVPs, the behavior of gnucash has not been
affected by these changes. The changes made are:
engine/policy.c & .h - define valid policies and their descriptions
and hints; define functions gnc_get_valid_policy_list and
gnc_valid_policy
engine/engine.i - include policy.h; define 'CURRENCY-ACCOUNTING',
'BOOK-CURRENCY', and 'DEFAULT-GAINS-POLICY' as option names
engine/test/utest-Split.cpp - revert prior commit that modified test
function for trading accounts
engine/test/utest-Transaction.c - revert prior commit that modified test
function for trading accounts
libqof/qof/qofbookslots.h - revert prior commit that defined Currency
Accounting Method; modify definitions of Currency Accounting and Book
Currency; add definition of default gains policy; keep the previous
Trading Accounts definition
libqof/qof/qofbook.cpp & .h - reverted function to determine currency
accounting method; add function to get book-currency, revert
previously committed changes to function to determine if book uses
trading accounts; add function to get gains policy; modify gobject
properties accordingly
libqof/qof/test/test-qofbook.c - revert prior modification to test
function for trading accounts; define tests for book-currency and
default gains policies
app-utils/options.scm - define make-currency-accounting-option and
required support functions
app-utils/options-util.c & .h - make support functions of
make-currency-accounting-option available in c code
app-utils/test/test-options-util.c - include tests for using book-currency
app-utils/gnc-ui-util.c & .h - define gnc_book_use_book_currency,
gnc_book_get_book_currency and gnc_book_get_default_gains_policy
functions
app-utils/test/test-gnc-ui-util.c - set up tests for new gnc-ui-util
functions
app-utils/test/test-app-utils.c - include test-gnc-ui-util.c
app-utils/test/Makefile.am - include test-gnc-ui-util.c
app-utils/app-utils.scm - define and export book options for Currency
Accounting, Book-Currency and Default Gains Policy; export required
currency-accounting-option support functions
app-utils/business-prefs.scm - replace the Trading Accounts boolean option
with a currency-accounting-option and rearrange the order of the
options
gnome-utils/dialog-options.c - define functions for set-ui-widget,
set-ui-value, and get-ui-value for 'currency-accounting' option and
various other support functions
New behaviour is that each time a bill is (re)posted
all the needed exchange rates will be asked.
If an exchange rate was already known, it is suggested
to the user, so s/he can simply confirm it if still ok.
The payment dialog was inconsistent in interpreting amounts and values.
By clicking on documents the document's amount is added to the Payment field
suggesting it's in the owner's currency. However the post-processing code
took that amount as being the amount in the transfer accounts currency
and calculated the rest backwards.
This will now become: the amount fields are interpreted in the owner's currency
and the exchange rate asked will be from owner's currenty to transfer
account's currency.
There was a C++11 compilation bust in
date_time/local_time/custom_time_zone.hpp, which was fixed in that
version. Since we also require C++11, that makes it the minimum
necessary.
Work around a bug in libsecret. Under certain conditions
libsecret will silently fail to find a password even though
it is stored. The workaround uses another interface call
to force unlocking the secret store which works around the bug.
This workaround should be removed once a fix for
https://bugzilla.gnome.org/show_bug.cgi?id=748625
will be commonly available.
If libsecret is available use it to search for both
libsecret based passwords as gnome-keyring based ones.
This catches the situation where a password was stored
earlier using gnome-keyring, while the user is now trying
to retrieve it on a system that only has libsecret available.
This used to fail because gnucash depended on gnome-keyring
to be present in that situation.
