test_suite_gncInvoice sets up the test suite. It's not part of the test
runtime, so stack variables in it have gone out of scope by the time the
tests are actually run. Making invoiceData static makes it permanent so
it exists at runtime.
First, save isn't necessary if the book is dirty, so don't... but that
means that the book has to be marked dirty after a session swap. No more
laziness.
Second, regardless of the outcome of inner_main_add_price_quotes the
session must be destroyed to remove the lock.
A couple of cleanups in QofSessionImpl::save as well: Rewrote the
descriptive comment to reflect how it really works when the backend has
gotten disconnected and removed the superfluous qof_book_set_backend
with the backend that we'd *just gotten from the book*.
Change all instances of bugzilla.gnome.org to bugs.gnucash.org, reflecting
our migration to a self-hosted bug tracker.
Inform the Translation Project Coordinator at release that this affects
translatable strings and that all message catalogs have been updated.
I think this crash is triggered because the 'account' variable
defaults to the first available AR account. If there's no AR account
it becomes null, and querying null's default book leads to segfault.
I guess I can fix segfault too by fixing gnc_account_get_book.
Change some plain string literals to std::string constants, which helps
avoiding typos and also saves some string constructors/destructors
in the KVP lookup. Nevertheless the functions in Account.cpp do not
contribute that much to the overall UI speed, but whatever.
The function qof_book_use_split_action_for_num_field gets called quite a
lot in each register display refresh (due to sorting all splits from
Split.x's xaccSplitOrder function), but it always used to use a KVP
lookup, which is rather expensive compared to accessing a gboolean member
variable.
To get rid of this cost, I had to remove the KVP lookup in this
simple-looking function. The pattern is this: A gboolean cache variable is
introduced, along with an isvalid flag. The lookup makes the expensive
KVP lookup once, then caches the value. The GObject property mechanism
offers a callback for when the setter was called, which is used to mark
the cached value as invalid. A parallel setter method (here:
qof_book_set_option) also just marks the cache as invalid. This covers
all setters, and the getters will use the cached value except for their
first invocation.
The NUM_FIELD_SOURCE feature was introduced in 2012 by the very large
commit 7cdd7372 and apparently its costs never were a problem
until the KVP lookup became more costly due to the std::vector
construction and destruction.
Turns out that the on-the-fly conversion from const char* (the KVP_OPTION_PATH
constants) to std::string with their immediate deletion afterwards is
a quite costly operation. Avoiding this is surprisingly easy: Just keep
local std::string objects at hand, and they don't have to be created
and deleted anymore.
The more optimized solution might be to turn the std::vector<std::string>
into a std::vector<GQuark>, but this commit at least improves the picture for now.
First change is to ensure gncEntry rounding is consistent. Internally
calculated values in the entry are never rounded. Consumers of
gncEntry's calculated values can request them either rounded or not.
Next use a pragmatical approach for calculating values on invoices based on
the entry values: do the rounding such that we never
create an unbalanced transaction while posting
That means
- round each entry's net value before summing them in net total
- accumulate all tax totals on invoice level per tax account before rounding
and round before before summing them in a global tax total
Hopefully this will catch a few more rounding issues in this area.
A complete solution can only offered if we allow users to manually correct
tax entries. This requires changes to user interface and data format
so that's not going to happen in gnucash 3.x.
strptime/strftime supports various modifiers to their parameters.
'E' and 'O': alternate locale-specific formats
(used in default format for Persian, Oriya, Azerbaijani)
'-': padding
(used in default format for Czech)
GnuCash passes dates as integer y/m/d without using locale-specific
formats, so we need to strip out 'E' and 'O' from the format when
scanning dates or determining separators in gnc-date.
None of '-', 'E', or 'O' are supported by boost (and '-' causes
errors), so strip them out from formatters in gnc-datetime as well.
See https://bugzilla.gnome.org/show_bug.cgi?id=795247.
This will probably need more refinement because the multiplications
are still missing rounding methods, but the changes in this commit
will already allow guile code to correctly create entries.
This commit contains another round of cleanups in the
timespec to time64 conversion. There were a number of
false assumptions that time64 = 0 would be a bad date
in the xml parser. This commit corrects enough of them to
eliminate the bug. Further cleanup is probably advised but
can be done at a later stage.
Also Bug 791825 - Accounting Period dates off by 1.
The DST start/end dates were reversed *and* the DST offset had the wrong
sign in Windows, resulting in the effective timezone always being one to
the west off (i.e. PDT was -9 and PST was -8).
Bills and invoices that are posted and subsequently unposted again still store their
posted account internally as a convenience to the user (upon reposting the old
account will be offered by default) so it's not a reliable test for the posted state.
The posted transaction on the other hand is guaranteed to only exist when the invoice is
posted. This should fix a slew of small and perhaps larger side effects, such as
a posted bill still appearing as editable, critical warnings when creating new bills/invoices
and so on.
An odd corner case: BST apparently came off of DST at 23:00 26 Oct 2014,
so midnight that day was ambiguous about being DST or not; that causes
the local_date_time constructor to throw in spite of the tm.is_dst element
being 0 (meaning pick standard time).
Instead of just failing in that case, try constructing a local_date_time
three hours later then adjust it back three hours. If *that* doesn't work
then throw a std::invalid argument.
After much thrashing this turned out to be caused by a date string
with a 3-digit year and that caused an unexpected boost::bad_cast
exception from boost::posix_time::time_from_string().
To prevent that and anything like it, pre-parse the string with
regular expressions to classify them and split out the timezone
if there is one. If neither (perhaps eventually none) of the
regexes match throw std::invalid_argument. The C function will
catch this and return 0.
