To maintain compatibility with any existing document link entries the
old 'assoc-head' and 'asooc_uri' entries will be used for the gsetting
and KVP entries.
The headers were made up from two parts, 'Tot' which was translated and
'Debit/Credit' which was not. Traced to some missing brackets around
the returned dflt_acct_debit_str and dflt_acct_credit_str.
Formerly would update progress bar every 100 splits. With scrub being
slow, it's nicer to update every 10 splits. Also remove
the (percentagefunc)(NULL, 0.0) which seems an error -- it would reset
the progressbar back to zero immediately.
When compiling with -Werror, GNUCash fails to build due to various error: missing sentinel in function call.
This patch resolves the issue by passing nullptr instead of C-style casting NULL.
The account tree page didn't have a "finish" function normally used to verify a page can close.
I added one, along with two flags that indicate whether a scrubbing operation is currently ongoing
and whether we should quit when the scrubbing is done.
The result is: If a user attempts to quit while scrubbing isn't done, an alert pops up asking whether the
user wants to abort the scrub. If so, the scrub is aborted (safely) and GC quits.
If not the app does not quit.
I have to say, I'm not sure this is the right way to do this. In my view, the right way would be:
- Disable the "quit" menu when scrubbing is happening (for some reason gnc_suspend_gui_refresh() does
not cause the quit menu to be grayed) so there's no chance of quitting while scrubbing is ongoing
- If needed, add an abort scrubbing button to the main window. Not sure whether that's desirable or not.
Let me know what you think: is what I have what we need, or would the above be better.
No point in generating 320 transactions or running the test 10 times
for a simple does-it-crash test. Do it once with 32 transactions so
it takes less than one second instead of 16.
A new per-account preference is added to let the user decide whether the interest transaction dialog should be
opened automatically before the reconcile. This preference is only enabled for certain types of accounts and
the code that decides that was moved to Account.h as is it now used in two separate place.
For clarity. In so doing found the backend behavior a bit inconsistent
so it's modified to do what the enum values indicate.
In the course of changing the various calls I found some implementation
errors in the back end and corrected them.
It's more descriptive and less likely to be confused with the book:id value
in XML files that is the book's GUID.
Also changed the QofSessionImpl::begin new_uri parameter from std::string to
const char*. There's no point in allocating a string just to call
new_uri.c_str() all over the place.
It causes GnuCash to crash if g_log is called without having set
G_LOG_DOMAIN.
Also extract a singleton getter function to ensure that the static
root module has been created before use.
To accomplish that we separate creating a book and creating a session;
gnc_get_session no longer automatically creates a book if one isn't
connected.
We also add an initially_insensitive GtkAction array to
gnc-plugin-basic-commands with a call to make its contents insensitive
at plugin load so that the save button on the toolbar isn't lighted when
there's nothing to save.
The previous fix didn't calculate the comparison time correctly and
ended up in the wrong day because the GMT time is before the local time.
In the course of checking the corner-case timezones (Midway and
Kiritimati) I found an error in the GncDateTime calculation of the
neutral time, so fixed that too.
Reported for Invoices on gnucash-user. Checked all other uses of
xaccTransSetPostDateSecs(), fixed the ones that weren't passing an
already normalized time64. For Invoices change the post_date to also be
normalized so that it stays the same as the transaction post_date. That
also protects it from the displayed date changing depending on timezone.
The python binding invoice post_time test had to be changed to match.
This fixes 3 bugs:
- Set a monthly recurrence on the 10th with a start date on the 20th of this month.
The editor correctly shows the next occurrence to be on the 10th of the following month.
The schedule transaction summary dialog incorrectly shows the next occurrence to be on the 10th of this month
(before the start date!)
- Set a monthly recurrence on the 19th, with a start date on the 20th of this month. The editor's
calendar marks incorrectly show the next occurrence to be on the 19th of this month (before the start date).
- Set a monthly recurrence on the 18th, with a start date on the 20th and an end date on the 17 of the following
month. The calendar should show no mark, but fails to erase the marks that were present.
They were intended to test whether a gnc-module could be loaded
correctly. However several were not even properly implemented
and for the others the gnc-modules have been converted to
ordinary libraries. Testing whether a library can be linked to
is not a useful test. Link issues are triggered at build time
already.
This also drops the python wrapper for gnc-module. As for the guile wrappers,
python should use other means of loading our shared libraries.
This commit required a few tweaks to the dependency chain as some units
inherited dependency information from gnc-module's public dependency
interface.
