creating a template register

[Joshua Sled]

Scheduled transactions desire a template register.  This is a register
which will contain _template_ Splits/Transactions which can be
_instantiated_ to actual transactions, perhaps with user input, at the
appropriate time.

It is expected that the scheduled transaction editor will contain a
general ledger, allowing the user to create transactions between the
appropriate accounts.  As the General Ledger cannot be used to create
stock transactions, a separate register will need to be created for
that purpose.

[ Within the UI, I expect that the lower-half of the
scheduled-transaction editor will be a notebook with two tabs: one for
the general ledger, and one for a Portfolio ledger.  To get around one
of the most annoying problems with using notebooks to conserve screen
real-estate, the tabs for the pages will include the number of
transactions in the ledger for that page, allowing the user to easily
get an idea of what's going on. ]

The user wants to create a template that can be modified into the
transaction with little/no intervention at that time.  However, some
fields are disallowed by definition.  I've been thinking that these
columns will just not show up in the template version, but maybe the
better thing is that they do [for consistency with their normal mental
model of the ledger], but they are visibly and otherwise disabled... ?

Template transactions should still reference the accounts which the
Splits [will] belong to, but some other fields are handled differently
or not handled at all; the ledger/register behavior differences are
really based on the type of cell:

. date_cell
  . goes away, as this is encoded in the frequency of recurrence
. num_cell
  . It may be cool if this was "auto_increment" or "next available",
    but I don't think we can implement that...
. {desc,notes,actn}_cell
  . stay as-is, and are copied to the instantiated transaction.
. recn_cell
  . By definition, a transaction in the future cannot be known as
    reconciled... of course, the instantiated version will have this
    cell, but I don't think it's part of the template transaction
    [unless I can be convinced otherwise].
. {mxfrm,xfrm}_cell
  . As per conversations with you, this data shouldn't go into the
    Splits they way it normally would.  The idea is that an engine
    invariant is "An Account gotten from a Split is valid, and the
    Account will contain that Split", which won't be true for these
    Splits.  So, handling of these fields will be modified to place
    the account [GUID] in the kvp-data for the Split.
. {cred,debt}_cell
  . The amount of the template transaction...
    . May be known [fixed, recurring payments]
    . May not be known
      . Maybe: derivable via simple formula.
      . Probably: User input is required at instantiation time
        [read-as: a formula with one variable to query from the user].
      . In any case, it's not a numeric value.
  . Handling probably places both types of values in the kvp-data, as
    well.  . {baln,sharbaln,tsharbaln}_cell
  . By definition, unknowable...
. {tcred,tdebt}_cell
  . If the Splits are all numeric, this is the same.
  . If the Splits contain formulas, then this gets weird...
. shrs_cell
  . Like debt/cred, it may be the case that the number of shares are
    either fixed, or derivable from the price at the time of
    instantiation... however, in that case, the amount put toward the
    purchase of shares may be variable/based on user input.  I'm not
    exactly sure what to do here, other than to say that -- like
    {debt,cred}_cell -- it should be in the kvp-data, and be either a
    number or a formula.
. tshrs_cell
  . Same problem as the {tcred,tdebt}_cell.
. pric_cell
  . Likely, this looked-up at the time of instantiation... so this
    field goes away.



My proposal is to subclass the MultiLedger/SplitLedger/splitreg
components in the following way:

. ADD xaccLedgerDisplayTemplateGeneralLedger(...)
  . This will create a GeneralLedger, and place it in "template" mode.
  . This may require an extra argument to xaccLedgerDisplayInternal.

. ADD xaccLedgerDisplayTemplatePortfolioLedger(...)
  . ditto

[ In "template mode", the following 'view'
  function pointers will be replaced: ]

. REPLACE xaccSRGetEntryHandler
  . This will return the data for the cell type in the appropriate way
    described above [i.e., for [m]xfrm_cells, this will get the
    account GUID from the kvp-data].
  . Otherwise, hand off the the supercla... er...
    xaccSRGetEntryHandler. :)

. REPLACE xaccSRConfirmHandler
  . A more lenient version which doesn't check for the reconcile flag
    [which is all this does, right now].
  . I haven't thought about it enough to determine if the template
    ledger wants it own confirmation policy, but this will become
    apparent soon enough.

. REPLACE xaccSRSaveRegEntry
  . This is the other half of the fun. :) This will save those
    aforementioned cell contents into the correct place.
  . Otherwise, hand off to xaccSRSaveRegEntry.

[ And the following changes to the register/ will need to be made: ]

. MODIFY splitreg.c
  . cell_sample_strings
    . changed in the template case iff used for cell-width
      determination.
  . configLayout
    . null-cell filling remains the same
    . most registers change based on the template option, but it may
      be just disabling the cells/column.
  . mallocCursors
    . number of columns changes based on template option [unless the
      columns can be disabled in some way].
  . xaccInitSplitRegister
    . cell descriptions probably change