There was nothing in the duplicate file that was different
from the original one except for the plugin_page parameter
initially passed in. Turns out we don't need anything
from the plugin_page except for the very generic GtkWindow
which is actually a member of the generic GncPluginPage
base object. So pass that window instead and avoid the
need for differentiation.
Bug 725296 reports that setting LANG=sv_SE fails to set the language.
This turns out to be an error in gettext, but it can be worked around
by setting LANG=Swedish_Sweden. That broke looking up the localized
account directory, so this special-cases "Swedish_Sweden" and
"Swedish_Finland" when looking up the account directory.
It's possible for OSX to create locales that while legal aren't
supported by setlocale, and we have account trees for some of these.
Retrieving the locale from NSLocale ignores the fixup done in
gnucash-bin to ensure that a reasonable and supported locale is used.
This commit adds code to check & repair that removes the read only status of the bogus transactions so the user can go in the AP/AR account and delete these bad transactions.
Translators: this commit introduces a new translatable string.
When auto-completing a transaction that was originally created in another
account with a different currency the balancing code will try to apply
conversions in the wrong direction if one edits the transaction. Explicitly
setting the transaction currency to the current register's currency
prevents the conversions being applied and allows the transaction to
balance correctly.
When a transaction with existing splits had its currency changed, the
function would change the values to use the new currency's denominator
without changing the actual value. The balancing code would then apply
the price of the the new "other" split to the amount, changing it as
well. Changing the transaction currency back would convert the value in
the other split correctly so that it would equal the amount that the
balancing code wouldn't change anything. I actually detected this bug
when I wrote the test but didn't recognize it as a bug.
The new code first calculates a new price and then applies it to each
split so that the transaction balances correctly in the new transaction
currency. This also round-trips correctly
This is a follow-up commit to fix the core of the issue.
With this commit gnucash is more liberal at accepting
counter formats. It will accept either li, lli, I64i and
whatever is defined for G_GINT_64 or PRIx64 on the user's
platform. Internally the code will always convert the
specifier set by the user with PRIx64, which should always
be the correct one on any platform.
Additionally a few extra tests were added to stress the
counter format code a bit more.
even if bill is already posted and results in extra $ posted to A/P
This adds a test in gncInvoice to return NULL it already posted.
Adds checks in dialog-invoice to test for already posted invoices. Messages
user and refuses to post entire selection if more than one selected.
Translators: This adds a message string.
If the user doesn't tab out of the price window before pressing return
or clicking OK gnc_xfer_price_update_cb isn't called, but it does call
gnc_xfer_update_to_amount, which does get called by
gnc_xfer_dialog_response_cb.
There were two problems: First, if there were multiple prices in the database
for a particular day only one would be displayed. Second, if one manually
created a second price on a day in the price editor the first wouldn't
be removed.
On recent builds of gentoo, apparently because the supplied webkit dislikes
that we output xhtml in a file called foo.html. Make the header say that
we're using HTML4.
Whenever recent 2.6.x versions of gnucash store bayesian data
in the old format (full account name based), gnucash 2.7+
should perform a conversion the the new format (guid based)
on subsequent opening of the file.
This will be set by future versions of gnucash (2.7+) when
they save bayesian data using GUID's instead of full
account names. The flag will prevent older versions
(2.6.11 and older) from opening data files with such data.
This looks a rounding error caused by not setting the denominator to an
appropirate value. I've set it to 100x the currency fraction.
For some reason I removed the call to gnc_numeric_convert() in commit
564b987457 I shouldn't have done that. I should have adjusted the denom.
