stockrotation.pl
--[a]dmin-email An address to which email reports should also be sent
--[b]ranchcode Select branch to report on for 'email' reports (default: all)
--e[x]ecute Actually perform stockrotation housekeeping
--[r]eport Select either 'full' or 'email'
--[S]end-all Send email reports even if the report body is empty
--[s]end-email Send reports by email
--[h]elp Display this help message
Cron script implementing scheduled stockrotation functionality.
By default this script merely reports on the current status of the stockrotation subsystem. In order to actually place items in transit, the script must be run with the `execute` argument.
`report` allows you to select the type of report that will be emitted. It's set to 'full' by default. If the `email` report is selected, you can use the `branchcode` parameter to specify which branch's report you would like to see. The default is 'all'.
`admin-email` is an additional email address to which we will send all email reports in addition to sending them to branch email addresses.
`send-email` will cause the script to send reports by email, and `send-all` will cause even reports with an empty body to be sent.
This script is used to move items from one stockrotationstage to the next, if they are elible for processing.
it should be run from cron like:
stockrotation.pl --report email --send-email --execute
Prior to that you can run the script from the command line without the --execute and --send-email parameters to see what reports the script would generate in 'production' mode. This is immensely useful for testing, or for getting to understand how the stockrotation module works: you can set up different scenarios, and then "query" the system on what it would do.
Normally you would want to run this script once per day, probably around midnight-ish to move any stockrotationitems along their rotas and to generate the email reports for branch libraries.
Each library will receive a report with "items of interest" for them for today's rota checks. Each item there will be an item that should, according to Koha, be located on the shelves of that branch, and which should be picked up and checked in. The item will either: - have been placed in transit to their new stage library; - have been placed in transit to be returned to their current stage library; - have just been added to a rota and will already be at the correct library;
In the last case the item will be checked in and no message will pop up. In the other cases a message will pop up requesting the item be posted to their new branch.
To understand this, you will need to know a little bit about the design of this script and the stockrotation modules.
This script operates in 3 phases: first it walks the graph of rotas, stages and items. For each active rota, it investigates the items in each stage and determines whether action is required. It does not perform any actions, it just "sieves" all items on active rotas into "actionable" and "non-actionable" baskets. We can use these baskets to perform actions against the items, or to generate reports.
During the second phase this script then loops through the actionable baskets, and performs the relevant action (initiate, repatriate, advance) on each item.
Finally, during the third phase we revisit the original baskets and we compile reports (for instance per branch email reports).
When the script is run without the "--execute" flag, we perform phase 1, skip phase 2 and move straight onto phase 3.
With the "--execute" flag we also perform the database operations.
So with or without the flag, the report will look the same (except for the "No database updates have been performed.").
undef = execute($report);
Perform the database updates, within a transaction, that are reported as needing to be performed by $REPORT.
$REPORT should be the return value of an invocation of `investigate`.
This procedure WILL mess with your database.
my $full_report = report_full($report);
Return an arrayref containing a string containing a detailed report about the current state of the stockrotation subsystem.
$REPORT should be the return value of `investigate`.
No data in the database is manipulated by this procedure.
my $email_report = report_by_branch($report, [$branch]);
Returns an arrayref containing a header string, with basic report information, and any number of 'per_branch' strings, containing a detailed report about the current state of the stockrotation subsystem, from the perspective of those individual branches.
No data in the database is manipulated by this procedure.
my $branch_string = _report_per_branch($branch_details);
return a string containing details about the stockrotation items and their status for the branch identified by $BRANCHCODE.
This helper procedure is only used from within `report_by_branch`.
No data in the database is manipulated by this procedure.
my $string = _print_item($item_section);
Return a string containing an overview about $ITEM_SECTION.
This helper procedure is only used from within `report_full`.
No data in the database is manipulated by this procedure.
undef = emit($params);
$PARAMS should be a hashref of the following format: admin_email: the address to which a copy of all reports should be sent. execute: the flag indicating whether we performed db updates send_all: the flag indicating whether we should send even empty reports send_email: the flag indicating whether we want to emit to stdout or email report: the data structure returned from one of the report procedures
No data in the database is manipulated by this procedure.
The return value is unspecified: we simply emit a message as a side-effect or die.
Alex Sassmannshausen <alex.sassmannshausen@ptfs-europe.com>