because object may become stale if UI is used to delete it, leading to
stale pointer and segfault. storing guid is safer, and will return
null if budget is deleted.
Add an "Append" checkbox to the bottom of the "Generic import
transaction matcher" window to the left of the "Reconcile after match"
checkbox.
When ticked, this causes the imported Description/Notes to be appended
to the matched transaction Description/Notes respectively.
The selected ticked/unticked state of the "Append" checkbox is saved in
a key value pair for the import account, so the next import for that
account will automatically default it to the saved state.
As these mods are limited to the code for the matcher window, this
should work for all the imports that use it - ie ofx & csv file imports
(both tested) & aqbanking (cannot test).
Add latest Venezuelan revaluation of the Bolivar Soberano, following
the ISO notation replacing VES (which the Venezualan central bank is
keeping) with VED and the exchange code (ditto) with 926.
This can be used to keep both in sync in the period between
initial migration and eventual obsolence.
Note only non-obsoleted, migrated preferences are tracked.
We don't want to resync preferences that have been
obsoleted (reset). That would nullify the whole idea
of making them obsolete for future removal.
This commit only adds the mapping, synching will follow in a future
commit.
application - MacOS 10.15.7 (19H1419)
Destruction order problem: The SX template accounts can't be destroyed
until after the template splts and transactions are.
Register them before the transactions and splits, as destruction occurs
in reverse order of registration.
'deprecate' is technically a noop. It serves to remind maintainers
the 'deprecated' preference is to be obsoleted in the next major
release.
'obsolete' goes one step further in that it will cause gnucash to reset
the preference, effectively clearing the value stored in the preferences
backend. This is the final phase of a preference. Following this it
will be completely removed from the GSettings schema in the next
major release.
Notes
* 'deprecate' and 'migrate' are related. Both are a reminder the
preference is to be obsoleted in the next major release. 'deprecate'
does only that though while 'migrate' will also trigger a copy of
the old value to a new location in the databse.
* This commit readds a couple of preferences that had been removed
in the past to be able to properly obsolete them (and to test
the obsoleting code)
This commit mostly changes descriptions and variable names to
use the more generic terms 'transformations' or 'conversions'.
'migration' is only one possible transform, future commits will
add others.
There are no functional changes in this commit other than
a logic inversion in parse_one_release_node. It now checks
for nodes named 'migrate' rather than for nodes not named
'migrate' (the code is adapted accordingly to match this
logic change).
We had hardcoded HAVE_HTMLHELPW to always be true so the fallback
code that's only reached when it is false was never reached.
Time to drop this dead code.
This makes sure all schema changes are in effect before
the first consumer can query them. For example this will
prevent a one-time re-occurrence of the tip of the day dialog
the first time the new migrations are run.
