Scheduled Transactions dead list

[Josh Sled]

On Thu, 2006-05-04 at 19:41 -0400, Andrew Duggan wrote:
> Josh Sled wrote:
> > 
> > Oh, what're you thinking?  I'm planning on re-writing most of the SX
> > stuff in the next month or two, so we might want to coordinate now,
> > before things diverge too much...
> 
> Basically I was thinking of checking every new tx as it goes into (by 
> entry) a register against a book-level (hopefully that's the right term) 
> set of sx instances, and if there is a match ask the user if that tx is the 
> sx due on $date, and if they answer "yes" then update sx with the last 
> occurred date and the new number of occurrences left.

Oh, interesting...  not having the SX engine create the transactions,
but match user-created transactions against the SXes ... to see which
ones are allowable or "admitted" by the SXes.


Yeah ... the SX list is at the book level.  The API could be something
of the form....

  GList* gnc_sx_fitting_transaction(Transaction *txn);

... since, presumably, more than one SX could fit the pattern.  



> That way even if I've not run ActionsSinceLastRunAction in a while, but 
> I've been still paying my bills, I don't have a mess of /stale/ sxn to deal 
> with. That behavior would probably need to be controlled by a preference, 
> since I'm sure it would annoy some if not everyone else besides me. :-) I 
> guess I spent too many years using that consumer "Q" product. The matching 
> criteria I think would be pretty straight-forward, everything that is *not* 
> controlled by a variable in the sx except for the date and "number" and 
> maybe notes would have to match, although it would have to be agnostic 
> regarding the order of the splits.

That sounds about right.  There's no actual ordering to the splits
anyways.

Given that the user-entered transactions might not be *exactly* on the
same schedule, it might be reasonable to have some sort of "fuzziness"
parameter on the lookup, too.  Maybe just an integer "window_days".


> I have already gotten the GList of sxn and can spin through those and 
> getting the end and endPlusReminder dates is easy, then its just a matter 
> of calling generate_instances() (which already does the heavy lifting) for 
> each sx and then spinning through the instanceList and remindersList lists 
> to count the number. (or so I guess at this point) Then I all I should have 
> to do is free all of the GList stuff and return the counts.

You might want to, instead, factor this out of
dialog-sxsincelast.c:gnc_ui_sxsincelast_dialog_create().  It's already
setup to return an integer along these lines, though the present code
will have the nasty side effect of actually creating the ui as well.

But we should certainly have only one copy of that creation code ...
this is a particular area I wanted to strengthen in the redesign. The
main focus of my efforts is going to be to extricate all the
not-UI-related SX manipulation logic from the ui code.  The
since-last-run dialog is the worst offender. :/


> find ~/devel/gnucash -name \*.[ch] -exec grep -H $LOOKING_FOR {} \;
> 
> has been my best friend lately,

Indeed. :)  cscope is pretty useful, as well ... particularly,
cscope-find-functions-calling-this-function and
cscope-find-global-definition (which is like TAGS).

-- 
...jsled
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`