Add vertical-align top.
Previously, text fields would have vertical-align:default = centre. This means long transaction descriptions would cause all other fields to be vertically centred. This amendment will ensure the transactional report text are aligned from the top.
This is half of the work to align the cmake and autotools generated dist tarballs.
What's missing in the cmake dist tarball on my system are all the files generated
or installed by running autogen.sh. I can't test this because cmake can't run
my version of automake (1.15), or at least our CMake configuration prevents this from happening.
Payment dialogs sort to beginning of day and do not honor NUM field for
custom sorting.
Do a two-step, first retrieving a GDate from the date_edit then use
gdate_to_timespec to convert it to a time64: gdate_to_timespec calls
gnc_dmy2timespec_neutral while gnc_date_edit_get_date_ts gets a
begining-of-the-day time.
Price and that already exists in the Price DB
Should have crashed regardless: The pricedb takes ownership of the
price object and unreffing it is going to cause trouble eventually.
tock Split Assistant crashes GnuCash if you enter a New Price and that
already exists in the Price DB
Relax the account type change restrictions again. In the new implementation
account types can't be changed for an account with splits:
- if the change woud force a commodity change (to/from normal accounts from/to stock related accounts)
- for immutable accounts
At the time of this commit the following account types are considered immutable:
- Accounts Receivable
- Accounts Payable
- Trading accounts
There is now a separate GNC_COMMODITY_NS_ISO_GUI label to be used
everywhere the users needs to read 'Currency namespace'. It's currently
set to 'Currencies' and can be translated. It may change in to future
to better describe this namespace is restricted to ISO4217 defined
currencies as opposed to all the non-formal currencies in vogue today
(like bitcoin and friends).
Fixes a bug reported on the mailing list wherein a date of 0000-00-00
in a MySql database would crash GnuCash. Such dates may come from a bad
conversion of 1970-01-01 or from a crash.
This commit will further improve the styling of the table element used for foreign
currencies in any report with foreign currencies or stocks. Adds non-breaking space
between foreign currency/stock and report currency.
Null tip_list after freeing it the first time to prevent double-free,
then don't iterate over it if contents is NULL. Don't even try to open
dialog if tip_count < 1. Protect from dereferencing a NULL tip_list in
gnc_new_tip_number.
Bug 776396 - Foreign currency reports, amounts are not aligned correctly
This commit will improve the styling of the table element used
for foreign currencies in the Balance sheet report so they
end up aligned with the other currencies.
The biggest problem was that a pointer to an out of scope struct tm was
passed to the wrapped function. With opt level 2, clang doesn't bother
setting the contents of the struct since it goes out of scope without being
used. This caused the transaction report to never report anything since
the start and end times it got were ridiculous.
Also most functions that take a struct tm pointer can change the contents
of the struct (if only to normalize it) so pass the new values back to Scheme.
Finally all calls to gnc_localtime and gnc_gmtime from Scheme leaked a struct tm
and calling gnc_tm_free from Scheme is a really bad idea so don't wrap it.
In order to allow to revert the newly introduced behaviour of putting
transaction text in front of the extracted purpose, the feature can now
be disabled through the preferences dialog.
Some banks include additional purpose information for a transaction in
non-swift-section 17 (aka transaction text). If available, this
transaction text is put in front of the other purpose texts to provide
full transaction information.
While the final solution is still under discussion. This change is a
first low-impact implementation backported and distilled from the work
discussed in gnucash/gnucash#139.
Fixing Bug 779217 increased the maximum denominator by 10, and that led
to overflows when converting large numbers' denominators from 100 to the
new max.
Correct the cell save routine so that the "numeric" kvp is correctly
overwritten in all instances when an edit changes its value for both
credit and debit splits. The both part is accomplished by extracting the
overwrite function.
Also provide a scrub to correct all of the incorrect files.
Unfortunately the necessary calculation function is in app-utils so
running the scrub from the backend as usual isn't possible, so we run it
from gnc_post_file_open in gnome-utils/gnc-file.c instead.
