(Actually, xaccAccountInsertSplit is #def'd to xaccSplitSetAccount().)
Accounts no longer manage their Split lists. The Account split lists
should only ever be modified from within xaccTransCommitEdit(). This
simplifies some of the operations on Accounts, since they can now be
expressed in terms of operations on Splits.
Also, the consolidation of two operations (RemoveSplit and InsertSplit)
into one operation (xaccSplitSetAccount) means that it's no longer
possible to orphan a Split.
Incidental:
Fix a leak of a KVP frame.
Don't recompute the account balance if we're shutting down.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@13462 57a11ea4-9604-0410-9ed3-97b8803252fd
Broken out just for clarity.
Note: There's one piece that I didn't change that I think is conceptually
awkward. It has to do with how/when we would discover that another
user has deleted the transaction we're currently editing. I think it makes
more sense to detect and handle this case in xaccTransCommitEdit() instead
of xaccTransRollbackEdit(), because (a) we don't actually have to do the
rollback if we just destroy the trans, (b) some rollbacks are not backend-
induced, but rather voluntary, (c) we need a generalized mechanism
anyway for detecting and handling deleted transactions even when
we're not editing them.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@13461 57a11ea4-9604-0410-9ed3-97b8803252fd
One simplification in xaccTransScrubImbalance() to always find the root
AccountGroup from the Transaction's book.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@13460 57a11ea4-9604-0410-9ed3-97b8803252fd
edit-blocks should work, and why.
Converts the very important xaccTransCommitEdit function to use the
qof_commit_edit_part2() function instead of something that is 90%
similar.
Transactions have a Split list that keeps track of Splits during the edit.
During edits, this list only grows and never shrinks. Splits that
have been destroyed or reparented to other transactions remain in
the list, along with pre-edit Splits and newly added Splits. Only after a
successful commit does the Split list drop reparented or destroyed
Splits. A couple out-of-engine users (mainly the register) call
xaccTransGetSplitList() an work from the Transaction's split list,
but they expect to be working with only the Splits that would still be in
the Transaction if the in-progress edit would be committed. So, we
provide the function xaccTransStillHasSplit(t, s) to allow users to query
the in-edit state of the Transaction's Split list.
xaccTransRemoveSplit() and xaccTransInsertSplit() have been replaced by
xaccSplitSetParent().
The new xaccTransCommitEdit tries to take a more conservative approach
to event generation, too. Instead of generating every possible event for
any commit, it should generate only events that indicate a change to an
engine object or relation.
Move some of the financial-constraint-enforcing functions closer to the
relevant data-structures. (from Scrub.c)
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@13459 57a11ea4-9604-0410-9ed3-97b8803252fd
The engine used to have functions that made it possible to orphan a Split.
As this is no longer possible, we can't test anymore.
Incidental:
Fix three or four small leaks in the test functions.
Allow test-period to be randomized based on optional command-line arg.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@13458 57a11ea4-9604-0410-9ed3-97b8803252fd
The Split <-> Account and Split <-> Transaction relationships are now
treated as properties of the Split. In terms of the BeginEdit/CommitEdit
block, Splits are subordinate to Transactions. There is no public
BeginEdit/CommitEdit block for Splits; changes to Splits should be wrapped
in their Transaction's Edit-block.
In the case of the Split <-> Account relationship, the call to
xaccSplitSetAccount() will be immediately visible from
xaccSplitGetAccount(), but the Account does not learn about the
Split until and if the edit is committed.
In the case of the Split <-> Transaction relationship, calling
xaccSplitSetParent() will immediately add the Split to the
Transactions split list. This is because the Split's Transaction
owns the reference to the Split. However, see the Transaction.c
patch for how to distinguish pre-edit state from in-edit state.
In both cases, events are not generated until the edits are committed.
Most of this new logic is in an engine-private helper xaccSplitCommitEdit(),
which is called from xaccTransCommitEdit().
Incidental:
Increased error-checking in xaccSplitSetValue().
Internalize a Transaction Begin/Commit edit-block in every setter func.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@13457 57a11ea4-9604-0410-9ed3-97b8803252fd
gnc:transaction-map-splits, both unused.
Remove g-wrapped versions of functions being removed:
gnc:account-fix-split-date-order,
gnc:trans-fix-split-date-order
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@13456 57a11ea4-9604-0410-9ed3-97b8803252fd
(default ':') and set it with an accessor function at startup and when
it is changed in the preferences/gconf. Eliminate unnecessary passing
around of the account separator character.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@13435 57a11ea4-9604-0410-9ed3-97b8803252fd
thousands/decimal point characters to use unicode functions. This
should allow multi-byte unicode characters to work as these separators
on input.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@13434 57a11ea4-9604-0410-9ed3-97b8803252fd
thousands separator and decimal point characters when printing
numbers.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@13433 57a11ea4-9604-0410-9ed3-97b8803252fd
dialog validation code into a single routine. Fixes 117812.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@13429 57a11ea4-9604-0410-9ed3-97b8803252fd
Apply a re-work of Titi Ala'ilima's patch to apply payments
directly to invoices. This fixes bug #121420.
* src/business/business-core/gncInvoice.[ch]:
Add argument to the ProcessPayment API to allow the caller
to specify an invoice to post to first.
* src/business/business-gnome/business-gnome-utils.[ch]:
Create an invoice-select API that lets you select an invoice
based on an owner (or not). I.e., you can limit the invoice
search based on a selected owner. If you change the owner
it invalidates the invoice search.
* src/business/business-gnome/dialog-payment.[ch]:
Change the API from ..new_with_value() to ..new_with_invoice().
Pull the default amount from the invoice (if one exists).
Allow the user to select an invoice and apply payments there.
If the user changes the owner, invalidate the invoice.
* src/business/business-gnome/business-options-gnome.c:
use the new invoice-select API instead of calling general_search
API directly.
* src/business/business-gnome/dialog-invoice.c:
call the new dialog-payment API. No need to compute the initial
value here; the payment dialog will compute it from the invoice
(instead of computing it from the invoice here).
* src/business/business-gnome/glade/payment.glade:
Add invoice-selector label and box.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@13411 57a11ea4-9604-0410-9ed3-97b8803252fd
