If the original date is an end-of-month date, we take it as an
indicator they always want monthdelta dates to be end-of-months.
This works for monthly/quarterly/halfyearly/annual.
Addendum to commit 65bfeaf5de which was
deemed to be an incomplete fix.
Also I'd forgotten to activate a test in test-date-utilities. Enable it.
the option lookup mechanism will dynamically translate option
names. warn the user if this takes place so that the report writer may
use new option names.
If a saved-report with e.g. relative date, multichoice option is
unknown, the report would crash, and the Report-Options would
segfault. This commit fixes both: report-date defaults to 'today',
multichoice-options defaults to default-value.
Following this commit, if a report loads a saved-report or .gcm from a
future version, a gnc:warn will be emitted and the report will not
crash; it will use relative-date today. Multichoice will remain the
default value. Report Options will not segfault.
The user will be notified via a gnc:gui-warn dialog
Instead of recursing the date, we calculate the next month using an
index-based multiplier, and apply modulo/remainder as appropriate to
determine the next month/year.
Then we attempt to create new mktime, and if the resulting mktime's
month is not as expected, reduce the mday by 1 until resulting month
is correct. This fixes monthly intervals for end-of-month days.
Test via monthly/quarterly deltas, and also includes leapyear
calculation.
This involves renaming 3 functions:
gnc_uri_get_protocol -> gnc_uri_get_scheme
gnc_uri_is_known_protocol -> gnc_uri_is_known_scheme
gnc_uri_is_file_protocol -> gnc_uri_is_file_scheme
The *_protocol variants are marked as deprecated.
Additionally a number of local variables have been renamed from
protocol to scheme to support this change.
- gnc_uri_get_components will now return NULL as protocol if the input is a normal
file system path instead of a uri (it used to return 'file')
- gnc_uri_get_protocol will now return NULL if the input is a normal
file system path instead of a uri (it used to return 'file')
- gnc_uri_is_file_protocol now returns FALSE if protocol is NULL (it used to return TRUE)
- gnc_uri_is_file_uri now returns FALSE if input is a normal file
system path instead of a uri (it used to return TRUE)
- a new function gnc_uri_targets_local_fs will return TRUE only if its input
is either a file uri or a normal file system path. This function is now mostly
used instead of gnc_uri_is_file_uri in the current code base
- a new function gnc_uri_is_uri is added to check whether its input
is a valid uri (has protocol, path and hostname for non-file uris)
There are a very few left that need deeper study, but this gets
rid of most of the noise. For the most part it's just getting rid of
extra variables or removing an assignment that is always
replaced later but before any reads of the variable. A few are
discarded result variables.
Use a variant of xaccParseAmount that allows to ignore the locale's positive_sign character
or the + sign if locale doesn't define a positive_sign character.
In a future redesign it would probably be better to replace use
of xaccParseAmount with some variant of the gnc-expression-parser
but that would require more that a few tweaks to get right.
When the preference dialogue is loaded and options are set, the ones
with registered callbacks fire causing parts of Gnucash to be updated.
This was observed with gnc_split_register_load being executed 5 times
for each open register when the preference dialogue was loaded.
To overcome this, a couple of functions have been created to block and
unblock all registered prefs and used while the preference dialogue is
loaded.
The core issue was that the delete visitor was never called because its parameter
type (char *) didn't match the boost::variant type (const char *).
Fixing the visitor's parameter type also require a const_cast
back to char * because that's what g_free takes as argument.
The rest of this commit is merely fixing KvpValue instantiations that
tried to create a char* KvpValue from a stack based const string instead
of a heap allocated one. That would bomb out on calling the
delete visitor.
This report had renamed "Action" to "Charge Type". For consistency,
let's rename it back, and add migration path in options.scm for
saved-options. 2 fewer strings for translation.
With the options dialogue open when Gnucash is closed this error is
logged in the trace file, gnc_close_gui_component() component not found.
This is fixed by reversing the components list found for session so the
options dialogue is closed before the report window.
Anticipating that some users might prefer to see exact prices,
add a preference to General>Numbers to configure whether prices
are rounded to decimals or are displayed as exact fractions.
When printing numbers convert them to a new decimal denominator with
rounding if the passed-in print info specifies that they should be
forced and rounded.
Make the default price settings forced and rounded.
Pass the price currency to gnc_default_price_print_info and
use the currency's fraction * 100 to determine the round-to
denominator and the number of decimal places to display.
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.
1. Don't even check for price/exchange rate on template transactions,
there's no point.
2. Extract function get_transaction_currency:
a. Check all split commodities are valid, abort transaction creation if
not.
b. If the template transaction's currency isn't used by any of the
splits set the new transaction's currency to the first-found currency if
there is one, otherwise to the first-found commodity.
3. Fix a minor typo in a comment.
Limit the range of the random value to 1..1000 to prevent overflows,
particularly in number-of-periods or number-of-years variables.
While we're at it, g_random_int and g_random_int_range return ints so
piping the result through gnc_double_to_numeric() doesn't make much
sense. That's removed, we just construct a gnc_numeric.
Clearer syntax helped find flawed test - while set-tm:mday directly
accepts 1-31, set-tm:mon accepts 0-11 to represent 1-12, therefore
must minus 1. set-tm:year accepts 92 to represent 1992, therefore must
minus 1900.
We want to sanitize render-options-changed, therefore it must return
an html-object. Unfortunately this is not accessible to
app-utils/options.scm. If we move this function to
report-system/html-utilities.scm, it can access html-objects.
Also rename it to gnc:html-render-options-changed
The swig 3.0 generated python wrappers trigger a warning converted into an error issued
by gcc 8.0 for using strncpy as follows:
strncpy(buff, "swig_ptr: ", 10);
The reason is this call will truncate the trailing null byte from the string.
This appears to have been fixed in swig master already but that's not released yet
so let disable the warning when compiling the swig wrappers until it is.
Take 3: Catch encoding exceptions from trying to read a string into
Scheme using scm_from_utf8_string and try again using
scm_from_locale_string. If that throws too, give up and log a
warning.
The mingw-w64 toolchain bizarrely substitutes scm_to_locale_string()
for scm_to_utf8_string(). This results in latin1 (yeah, "locale" is
a lie) instead of utf8 which causes an assertion in
g_utf8_collate_key().
Perhaps equally bizarre, the compiler doesn't make the substitution
with scm_to_utf8_stringn(), so use that instead.
When accounts are deleted that have an open register window a component
not found error is triggered. After the account is destroyed, a call to
'gnc_resume_gui_refresh' calls 'gnc_gui_refresh_internal' and this then
calls 'find_component_ids_by_class' which is used in order resulting in
'register-single' being unregistered before 'GncPluginPageRegister' and
hence 'ld' being freed but the register not knowing this. Reversing the
list fixes this.
Replacing libgncmod-python, libgncmod-core-utils-python, and
libgncmod-app-utils-python with _sw_core_utils and _sw_app_utils.
The latter two are the modules that init.py wants to load and with
Python3 Swig appears to no longer make them available via libgncmod.
Note that there may still be some problems with actually using the
console, but it at least loads at startup without complaint.
Christopher Lam
Alex Aycinena
John Ralls
Geert Janssens
Robert Fewell
Yuri Chornoivan
luc14n0