Documentation for Notifier lane API class
Documentation for Notifier lane API class
Work in progess: electronic signature capture
New RepeatAgain flag. This is to allow a single tender operation
to move through multiple confirmation screens if needed.
Overhaul of prodUpdate compression and archiving:
New task replaces three existing CompressProdUpdate tasks
New ID columns all over the place
With schema updates, prodUpdateArchive can be deprecated. After
database updates, running the new task manually* may be a good
idea. It needs to rebuild prodPriceHistory and prodDepartmentHistory
from scratch to assign foreign keys correctly.

* command: php FannieTask.php ProdUpdateMaintenanceTask
BUGFIX: wrong variable in new produpdate task
HOTFIX: lane tender report test page wrong variable name
HOTFIX: lane tender report test page wrong variable name
HOTFIX: lane tender report test page wrong variable name
Semi-implemented description field for lane-side houseCoupons table
Corresponding houseCoupons.description update, fannie-side
Updated DB structure for product changelog tables
Deprecating table vendorLoadScripts
Cleaning up database cruft. Got rid of:
* fannie.op.AdDates
* fannie.op.batchMergeLC
* fannie.op.batchMergeProd
* fannie.op.CashPerformDay_cache
References to these tables are mostly gone from the code base.
Cashier performance data will be cached in either
CashPerformDay or CashPerformDay_cache depending which is actually
a table. Ditto for the report that uses that data.

SQLManager has a new isView() method and I tweaked the adodb library
to correctly detect mysql views.
Deprecating batch priority views. The idea of sales batch priority
may still be useful in a multi-store environment, but enforcing
the priority rules via five cascading views is not the right
approach. These were not actually being used AFAIK. The references
in the nightly.batch.php job were on the MSSQL side.
Deprecating batchowner. Updated model adds an 'owner' column directly
to the batches table. The separate table isn't necessary with
the better update mechanism. Data is migrated automatically.
Batch tools work with either schema.
Departments table expanded to include margin and salesCode columns
instead of using deptMargin and deptSalesCodes table. Editors maintain
both tables. Dependency removal in other reports and tools not
done yet.
BUGFIXES: cache task/job had an incorrect DB variable,
ditto for prodUpdate, batch report had a stray reference to
batchowner
Finished removing references to deptSalesCode and deprecated it.
I actually remembered to update the sample data this time.
FanniePage::readinessCheck as a method to see if any prerequisite requirements
for a page are not met. There are some cases where verifying data
has been entered is helpful. It could also be a place to do things like:
* Table X does not exist. Click here to go create it.
* Table Y needs to be updated. Click here to do so.