One-time task to put IDs onto archived transaction values.
Actual update queries are commented at the moment until
I verify it works correctly.
Fixed checkdigit bug in default vendor catalog import tool
Updated related documentation with info about required/optional
fields and formatting.
Work in progress: Advanced item search with many options
Advanced item search: added tax, foodstamp, discountable, and local filters
Added editor links to the output. Output still needs lots of work to
feed multi-item results sets into other tooling
Wider advanced search output with more fields displayed
startAt URL paramater for batch tool to immediately load the given batchID
First tool corresponding to advanced search. Create sale or price
change batch from selected search results. Some boilerplate here
could probably be refactored up into a page class.
Added link exposing advanced search to users
WFC BUGFIX:
incorrect case in special order action string
prev/next links in plugin version of PI
broken delete option in eval scores
SEMI-BUG: Pressing enter on markup/down helper tools would instantly
finalize the batch. Trapping the keypress so the user has to actually
click the submit button is probably better
BUGFIX: Obscure issue relating to repeatedly creating and deleting
shelftags for the same UPC on the same day
Added second advanced search driven tool to edit multiple items
BasicModel maintains a status flag indicated whether values have
changed. The flag is set to true whenever a column's setter function
alters the instance's value for that column. The flag returns to
false upon a successful load() or save() call at which point
the instance should once again match the database's record.

I added a corresponding "ignore_updates" property for columns. Changing
columns with this property will *not* flip the status flag to true.

I'm not concerned about the miniscule performance implications of
issuing an UPDATE query that doesn't actually change anything. The
status flag is only in use in the ProductsModel class and the
motivation is to handle timestamps and audit trails correctly.
Right now if someone loads an item in an editor, changes nothing,
and saves the result is going to be an UPDATE query that changes
the value of products.modified and nothing else plus a new
record in prodUpdate. The audit trail record is pointless clutter
and the change to products.modified is downright misleading.
The item was not modified in a meaningful sense.
Refactored FannieReportPage::preprocess to handle a bunch of common,
boilerplate tasks rather than having each child class redefine
the method. Department Movement revised as example.
Reports revised to use FannieReportPage::preprocess()
Refactor: renamed FannieDispatch::go FannieDispatch::conditionalExec
Also cleaned up stack trace output and added an optional parameter
to disable stack traces
Refactor: all class-based Fannie pages that were not using FannieDispatch
to draw themselves are now using conditionalExec. I disabled the
built-in stacktrace for these ones so functionally nothing should
change for end-users.
BUGFIX (maybe): when canceling a price override on a zero-priced
item, UPDATE the trans_type of the record to make it a log record
instead of DELETEing the record from the transaction. Deletion
causes gaps in trans_id.
Handful of simple pages missing an FannieAPI include
SCHEMA: added "saleCost" column to vendorItems to capture temporary
special prices. All code should work fine with or without the new
column. This feeds into requested options on Advanced Item Search