The conversion assumed there were only three levels to bayes import
map kvp: IMAP token, user-supplied token, GUID/account name. In
actuality, since user-supplied tokens could have the delimiter in them,
there could be several. This fix takes that into account like so:
IMAP token, potentially several user-supplied tokens, GUID/account name.
The import map is undergoing two conversions at the same time: account names
to guids and an hierarchical representation to a flat representation in KVP.
The bayes data are stored in the KVP store. Before this commit, they are
stored under /import-map-bayes/<token>/<account guid>/count (where count
is the datum that "matters" in bayes matching).
The problem with this is that any token including the kvp delimiter
(currently '/') gets divided, and is not found correctly during bayes
kvp searching. The quickest solution to this is to replace all "/"
characters with some other character. That has been done, along with a
re-structuring of the bayes matching code to take advantage of c++
features to make the code more concise and readable.
Also modified some test functions to fix leaks and double-frees: the
same kvp value can't be in the kvp tree twice.
Also, when I added code to clean up after the tests, some things started
breaking due to double-delete. Apparently const_cast was hiding some
programming errors. Really? You don't say? When giving a GUID* to KvpValue,
the latter takes ownership of the former.
The nested representation was very noisy. Now, the string representation
shows one line per value with the full prefix which is also more
expressive than the old version.
The template avoids the need to cast to and from void*, and adds flexibility to
the targeted function's signature.
test-stuff.h defines a macro, "failure" which is used as an identifier
in the standard IO library, so I moved any inclusion of test-stuff.h to
the last include position so that "failure" wouldn't be defined before
the IO library was included.
Since Account.c is now Account.cpp, the function signatures look a bit
different internally. The tests rely on function signatures in error
messages. Instead of trying to figure out what the exact
function signature might be, I use a substring matching strategy to
ensure that the correct error was issued.
The preference schema migration collects all schema mutations that can occur
when upgrading to a newer gnucash version. The old gconf to gsettings conversion is
integrated in this system as well. Newer schema mutations will happen based on version
number upgrades though.
The preference that got replaced is "use-theme-colors". Based on discussion in bug 746163
(https://bugzilla.gnome.org/show_bug.cgi?id=746163) and gnucash-docs PR#105
(https://github.com/Gnucash/gnucash-docs/pull/105) this has been replaced with
"use-gnucash-color-theme" with inverted meaning. The old option is kept around for one or
two major release cycles to allow seamless conversion.
as it doesn't load proper backend.
The cause was that the libdbi-driver path in CMakeLists.txt was wrong
and GNC_DBD_DIR was being set unconditionally in etc/gnucash/environment
with an invalid path.
