With XCode 14 or newer CMake tries to use the "new build system" which has a
requirement that if two targets depend on the same generated file one of them
must depend on the other. This commit adds reduntant dependencies to satisfy
this requirement.
Handle template transactions that don't have any splits with empty credit
and debit strings and those having no set transaction account.
Set the concrete transaction commodity to the first found of:
The template transaction's commodity
The commodity of the first split with a credit or debit string
The commodity of the first split.
Test these scheduled transactions:
* 2 splits with fixed amounts "123"
* 2 splits with fixed amounts "0"
* 2 splits with empty amounts ""
Verify that automatically created scheduled transactions exist.
This scrubbing function calls xaccTransRollbackEdit which is
leaky. Instead of trying to fix xaccTransRollbackEdit which requires
superhuman skills, it's easiest to track the changes separately in a
GList, and use xaccTransBeginEdit/xaccTransCommitEdit only if
necessary.
Found via `codespell -q 3 -S *.po,./po,*.min.js,./ChangeLog*,./NEWS,./borrowed,./doc/README*,./AUTHORS,./libgnucash/tax/us/txf-de*,./data/accounts -L ans,ba,cas,dragable,gae,iff,iif,mut,nd,numer,parm,parms,startd,stoll`
Separate the "All noncurrency" convenience category in the commodity
selector and the default non-commodity namespace proposed by the QIF
importer because they have different functions.
Also remove the namespace guessing code from qif-dialog because with
only one default non-currency namespace there's nothing to guess.
The changes 09296dfb96, 1373233cd0 and 189db58e6 had caused
inconsistencies. Best restore original guile variable names using
underscore, bound to strings instead of functions returning strings.
When Gnucash is run in Hebrew which is a RTL language, on the accounts
page the tree view is displaying the required number as the following...
TreeView entry is '1,500.00 ₪' or '-1,500.00 ₪'
TreeModel string is '₪ 1,500.00' or '₪ 1,500.00-'
This seems to be down to the GTK 'Unicode Bidirectional Text Algorithm'
which is changing the representation of the model string based on the
first strongly typed character, in this case the Israeli shekel sign.
To fix this, when creating the displayed monetary amount insert a BiDi
ltr isolate uni-character at the start of the string.
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.
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.
'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.
The rules for migration are read from an xml file. This file was
prepared in a previous commit. Future settings 'data model' changes can
reuse this code by simply adding migration rules in the xml file.
This replaces the hardcoded rules that were currently in place to
migrate a few settings from 2.6 and older to 3.0. These rules are no
longer meaningful as we require users to migrate from one major release
series to the immediate next one. So by the time the new migration rules
in this commit are applied by users they should already have run gnucash
3.x at least once. That run should have taken care of the pre-3.0
migration actions.
This was ported from GConf, but GSettings doesn't work that way.
Settings locations are defined at compile time and can't be
relocated at run time (unless you make all of the settings
explicitly relocatable. That however is not how GSettings is meant to be
used.)
The latter is the prefix format prescribed by gsettings itself. The former never
was an issue until flatpak decided to not accept the shorter prefix when
requesting a settings migration from host system to flatpak sandbox.
In order to allow for migration, keep the old schema around in
org.gnucash.GnuCash.deprecated.gschema.in
While we're at it, make the new prefix an internal implementation detail.
There's no need for it to be visible to the rest of the gnucash code.
