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.
This issue arises every time a pending transaction is deleted (it does not arise if blank splits are deleted)
This PR fixes the issue by calling gnc_split_register_redraw once the pending transaction has be deleted.
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.
None of these gnc-modules have any particular construction or destruction
code except for loading the modules they depend on. These dependencies
are all loaded anyway in other ways so for these libraries the gnc-module
wrapper code brings no benefit.
To make this work, I had to add the right head and make a change to the CMakeLists file.
The ofx code used to have a static int to count imported transactions, which was a bit hacky.
I replaced it with a structure that's passed to all the callbacks. The structure has
the transaction count, as well as a list of statement balances information.
This list is used after the import of the ofx file to do the reconciliation.
NOTE: I wouldn't need a list since the current code only process one ofx at a time. However
I have another PR for importing several ofx files in one shot, so this PR is ready for that.
The reconciliation code is modeled after what's done in aqbanking.
goodvibes2
John Ralls
jean
Christopher Lam
Geert Janssens
Frank H. Ellenberger
c-holtermann
milotype