Scheduled Transactions dead list

[Andrew Duggan]

Josh Sled wrote:
> 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 seems pretty good to my gnucash-novice eyes.

> 
>> 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".
> 
> 

Yes, especially on the 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.

I think then I am on the right track, since that's what I did.  Plus I've 
just gotten it to work - at least through a couple of rounds of initial 
testing :-)  Now I can just look at the tool bar and see how many pending 
txn/reminders I have, click the button and run them. :-)

I had erroneously thought I should free the lists etc that I ended up 
creating, but after digging a little deeper, (and my testing confirms this) 
that I should not do that, since the sxlist (as QOF collection gets stashed 
in the book->hash_of_collections as GNC_ID_SXTT.  As we all know, "stuff" 
don't like having its data structures de-allocated out from underneath it :-/

The code is still rough, and I think I need to move it to around a little, 
I'm not sure my initial choice of "where" to add it is right.

> 
> 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. :/
> 

Well, I can't speak to that, other than to say, if I could hack my way 
through it, it can't be all-that-bad. :-)

> 
>> 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).
> 

Thanks for that hint I will have to start playing with that, it will 
certainly help me get a better grasp of the overall "flow".

Andrew