Currently, when you delete an item, the timestamp column in deleteditems is
updated with current time. (This comes from an [unintentional] additional
update statement in DelItem.) It makes deletion time visible.
In the past, the marcxml was updated too at that moment, resulting in an
updated timestamp in biblioitems too. The timestamp in biblio was not touched.
If you delete a biblio however, the timestamps in deletedbiblio and
deletedbiblioitems do not reflect time of deletion. They still show the time of
last update before the record was deleted. This last update can be extracted
from MARC field 005 too.
This behavior is not consistent nor logical. I would suggest to add a statement
in DelBiblio to force updating the timestamp in deletedbiblio(items) too. It
makes the time of deletion visible in the record too. The time of deletion of a
biblio can be very useful for e.g. synchronizing purposes.
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
If the AcqCreateItem preference is set to "ordering" and the barcode for
the new item is already in use, no error is returned, but an invalid
itemnumber is saved in the aqorders_items table and the item is never
created.
This patch adds a duplicate barcode verification in neworderempty.pl
_koha_add_item is also modified so it won't return an invalid ID when
an item can't be added.
http://bugs.koha-community.org/show_bug.cgi?id=6963
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Test plan on second patch.
- all items attached to the order are deleted
- if there is no more items, and if the biblio is not in other orders and no subscriptions and no holds then the biblio is proposed to deletion
Now whe have 2 links : "delete order" and "delete order and catalog record", the second one appears only if the deletion is possible.
Note that if an hold is related to the item or if the item is unique for the biblio the link "Delete order" is canceled due to hold remaining.
On mouse over explanations are shown with count.
More lines of warnings with count are shown depending of the case.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Configuration:
AcqCreateItem = on order
Test cases and results:
1) Order new record with 2 items
a) From basket
- delete order: only deletes items, OK!
- delete order and catalog record: deletes record and items, OK
b) From shipment/receive
- delete order: only deletes items, OK!
2) Order 1 additional item for existing record with 1 item
a) From basket:
- delete order: works, existing item and record remain, OK
- Can't delete order and catalog record, 1 item left, OK!
3) Order new record with 1 item, title level hold on record
a) From basket:
- delete order: not possible, OK!
- delete orer and catalog record: not possible, OK!
b) From shipment/receive page
- Cancel: Deletes order, record and hold silently.
NO WARNING. NOT OK. See note below.
4) Order 1 additional item for existing record with 1 item,
item level hold on existing item
a) From basket:
- delete order: works, hold and existing item remain, OK!
- delete order and catalog record: not possible, OK!
b) From shipment/receive page
- Cancel: on order item is deleted, other item and hold remain.
5) Order new serial record, create subscription
a) From basket:
- delete order: works, record and subscription remain, OK!
- delete order and catalog record: not possible, OK!
b) From shipment/receive page:
- Cancel: Subscription and record are silently deleted. NOT OK.
6) Order additional item for existing record with other on order items
a) From basket:
- delete order: works, existing on order items remain, OK!
- delete order and catalog record: not possible, OK!
b) From shipment:
- Cancel: deletes order and ordered item. OK.
Changes made:
I changed the wording of the error messages a bit in the template.
I changed the message 'Can't delete order and catalog record' to not be
shown as a link, as the link does nothing. Tooltip still appears.
I attached a screenshot to the bug showing some of my changes.
Hope that's ok.
Necessary enhancements:
Cancelling orders when receiving items should work the same as from the
basket summary page. We need the same checks and messages there before
deleting records and items automatically.
I am signing off on this, but to go into Koha it needs a follow-up for the
order receive page.
Signed-off-by: Ian Walls <ian.walls@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Call LostItem() whenever item is lost.
LostItem() new arg - mark returned.
Disabled Lost Status on catalogue item edit.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
For follow up we need to explain how to hide the 952$1 (lost) from
the framework by putting it in the 'ignore' tab.
Signed-off-by: Ian Walls <ian.walls@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
When IndependantBranches syspref is enabled, a 'regular' user can only
delete items belonging to his/her library. But a superlibrarian should
have the permission to delete items from all libraries. He can't for the
time being. This is fix by this patch.
How to test?
- On a multi-libraries Koha, activate IndependantBranches
- Log in with a superlibrarian user
- Find a biblio with one item from another library than the user home
library
- Click on Edit > Edit Items
- On the list of items, all lines have Delete link
- If you try to delete an item from another library than the user home
library, deletion will fail.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Display links to parent biblios, show linked items in holdings, allow holds on
linked items. This uses MARC to maintain relationships.
Sponsored by the Mississippi Department of Archives and History and RapidRadio
Solution. Originally developed by Savitra Sirohi and Amit Gupta at OSSLabs, with
UNIMARC support added by Zeno Tajoli. Commits squashed and merge conflicts
resolved by Chris Cormack from Catalyst. Respect for NORMARC and some small
framework portability fixes made by Jared Camins-Esakov of C & P Bibliography
Services.
IMPORTANT NOTE: A bug in the 773 coding for MARC21 was corrected from the
original OSS Labs code. The 773s generated by the pre-release code did not have
the first indicator set to '0', which means that they were not supposed to
display. Going forward, the first indicator will be set correctly, but existing
records created with this code will no longer appear (they appeared before only
due to another bug). To correct this, you could globally (or, to make sure you
only modify records created with the Analytics tool, for records with 773$0)
change the first indicator of the 773 from blank to '0'.
== Background ==
An analytic record for an item is a more detailed, monographic biblio for an
item attached to a serial record . This is often used for special issues of a
journal that are released as books on their own (assigned an ISBN, as well as an
ISSN/volume/issue). It is important for researchers to be able to search for
these items both as issues of the serial, and as monographs. It is equally
important for the library to not have duplicate item records for the item in
question to have to keep synchronized.
== Establishing relationships ==
Analytical records are connected to items belonging to parent or host
bibliographic records. This can be accomplished by:
* From an analytical bibliographic record linking to an host item by providing
the item barcode as input
* From a host item by using option "analyze", this creates a new empty
bibliographic record with field 773 (MARC21) populated
* Running a new CLI script that establishes a relationship between the
analytical record and the host item identified by the barcode in the
analytical record's 773$o (MARC21)
== Connecting Records ==
The relationships are maintained in the MARC records, we have not used database
tables at all.
== MARC Representation ==
In MARC21/NORMARC we have used:
* 773$9 to store the Koha item number of the host item
* 773$0 to store the Koha biblio number of the host bibliographic record
The above fields are used to display the relationships in various screens in the
OPAC and the staff interface. Additionally, when populating field 773 with host
item's details, we have used following MARC 21 mapping:
* 'a' <= 100/110/111 $a (author main)
* 'b' <= 250$a (edition)
* 'd' <= 260$a, 260$b, 260$c (place, publisher, year)
* 'o' <= barcode
* 't' <= 245$a (title)
* 'w' <= (003)001 --> if no 001 is available, we can populate biblionumber
* 'x' <= 022$a (issn)
* 'z' <= 020$a (isbn)
In UNIMARC, this code uses:
* 461$9 to store the Koha item number of the host item
* 461$0 to store the Koha biblio number of the host bibliographic record
When populating field 461 in UNIMARC, the following mapping is used:
* 't' <= 200$a (title)
== Treatment of Holds ==
A key requirement was to allow holds to be placed on host items from the
analytical record. We have accomplished this by allowing holds on specific
copies only. Biblio level holds are not allowed. This ensures that holds are
placed on specific items that are relevant to the analytical record.
== Deleting host items with linked analytical records ==
As we have not used database tables to maintain relationships, we had to use
search to find out if any linked analytical records are present. If 1 or more
analytical are present, we do not allow deletion of items. This is similar to
what we see when we try to delete authority records.
== Importing analytical records ==
Analytical records can be imported using bulkmarcimport or the GUI tools. The
new CLI script can be executed after the import to establish relationships with
host items. The script will establish relationships using the host item's
barcode, the barcode must be present in 773$o of the analytical record.
== What if there are two or more copies of the host item? ==
The current design will require that there be two host (773) fields, one for
each copy.
== What if there is no barcode available for the host item? ==
It is still possible to establish a relationship, by populating 773$9 with the
host's item number. However the CLI script uses barcode in 773$o to establish
relationships so it won't work where barcodes are unavailable. Also from an
analytical record, it is possible to establish a relationship to a host item by
providing the barcode as input, this option will not be available as well.
Commits that added the following features were squashed by Chris Cormack (this
is not a list of every commit):
* Display links to host records from biblio detail screens
* Support for UNIMARC, respecting the system preference 'marcflavor'
* Support holds from the OPAC
* Ability to link to items belong to host records from a analytical record
* Display items belonging to host records in the moredetail page
* Ability to edit items belonging to host records, also ability to delink from
them
* Move get host items code into a C4 routine, also calling the new routine in
related perl scripts
* Move host field population to a C4 routine, all changes in pl files to call
new routine
* Allow only specific copy holds for analytical records plus changes to use new
C4 routines
* Support for holds on items linked via host records
* Storing bibnumber and itemnumber in subfields 0 and 9, plus other mapping
changes
* New command line script that establishes relationships between analytical
records and host items and bibs. The script looks for host field (MARC21 773)
in records, and based on barcode in subfield 'o' populates host bibnumber in
subfield '0' and host itemnumber in subfield '9'. The script can be run after
an import of analytical records, it can also be run in the crontab to maintain
the relationships
* Ability to create analytical records from items, to view linked analytics, and
prevent deletion of items that have linked analytics
* New template for catalogue/detail.pl (NOTE: not a new template file, just a
new way of displaying analytics), template displays linked analytics and
allows creation of analytical records
* New zebra index for item number in host fields. This index will be used to
display links to analytical records from host records
* Display title of host record instead of the phrase host record
* Using detail.tmpl for analytics tab instead of a new template file
* Improved qualification info prepration in Prephostmarcfield
* Check for linked analytics before deleting item
* Display link to host record and more meaningful anchor text for edit item link
* Analytical record: Unimarc index in record.abs and help in
create_analytical_rel.pl
* Adding a sys pref that controls display of options to create analytical
relationships
* Add host entry in XSLT stylesheet in staff item detail
* Added host record support to OPAC detail XSLT
* Adding 773$0 and 773$9 to all frameworks
* Adding 773 subfields 0 and 9 to default marc framework via updatedatabase.pl
* Display create analytics and used in links in catalog detail
* Fixed problem where analytical records not showing in OPAC search results
because GetMarcBiblio now needs a flag to add item records
* Fixed problem where analytics count was set to 1 for all records, not just
those with analytics
* Fixed catalogue detail page not to show analytics counts if count is 0
Conflicts:
installer/data/mysql/updatedatabase.pl
koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/addbiblio.tt
kohaversion.pl
Co-author: Savitra Sirohi <savitra.sirohi@osslabs.biz>
Co-author: Zeno Tajoli <tajoli@cilea.it>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Ian Walls <ian.walls@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
GetItemsInfo in Items.pm includes this join:
LEFT JOIN branches ON items.homebranch = branches.branchcode
This means that the branch URL (from the branches table) comes out
as the URL for items.homebranch, thus the URL in the holdings
output is the item's home branch even though the display might
be showing a different current location.
This patch changes the join to use items.holdingbranch. The join
was originally added to fix Bug 3702, and based on the description
of that feature I'm assuming this change is not harmful to other
usages. However, it does make the assumption that the item's
current (holding) branch is the branch we want to see information
about.
Signed-off-by: Nicole Engard <nengard@gmail.com>
Signed-off-by: Ian Walls <ian.walls@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
The date last seen field (952 $r) and replacement price date (952 $w) were being
ignored on import, being replaced with NOW() as a hardcoded value. This patch will
allow a value to be imported, but if none is, it will use the ISO date of import
as a default.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Signed-off-by: Ian Walls <ian.walls@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Bugfix for problems when shelving cart used without In Processing settings
To test, with InProcessingToShelvingCart off, NewItemsDefaultLocation blank,
and ReturnToShelvingCart on, create a new item. Check the contents of the
location and permanent_location fields in its item record -- the same value
should be in both. Then run the item through checkin, and look at those fields
again. The location field should now be set to CART while permanent_location
should still have the original value. After the cart_to_shelf cron job runs
with the proper timing, check the item record again. Both location and
permanent_location should again be identical.
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Do not misleadingly document or pass an unused second parameter
makes all calls use the single parameter call as the C4
routines already did
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Had effect of breaking item record changes when the
CatalogingLog system preference is on.
(Note to people reviewing patches - please do not modify the content
of patches that you are signing off on unless you are *sure* you
know *exactly* what you doing. The process of patch review should
not be introducing yet more bugs.)
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Remove the following routines which used to
handle embedding item data in the bibliographic record:
C4::Items::_replace_item_field_in_biblio
C4::Items::_add_item_field_to_biblio
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Signed-off-by: Claire Hernandez <claire.hernandez@biblibre.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
* no need to record full bib MARC when logging
change to an item record
* IDEA: set up a separate ItemLog syspref
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Signed-off-by: Claire Hernandez <claire.hernandez@biblibre.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
* when item changes
* when new item is added
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Signed-off-by: Claire Hernandez <claire.hernandez@biblibre.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
* Must signal both bibs to be reindexed
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Signed-off-by: Claire Hernandez <claire.hernandez@biblibre.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
This is a squash of four patches by Henri-Damien Laurent
starting work on removing the copy of item record information
in the 9XX field of bibliographic records. The reason
for doing this is primarily to improve performance, in particular,
the expense of having to add/modify the bib record whenever an
item changes. Now, whenever an item changes, the bib record is
put in the queue to be reindexed; when the bib is indexed, the 9XX
fields are inserted into the version of the bib that Zebra indexes.
Since rebuild_zebra.pl runs in a separate process, the processing of the
bib record will not delay (e.g.) circulation.
As part of upgrading to 3.4, the following batch script should be run:
misc/maintenance/remove_items_from_biblioitems.pl --run
This should be followed by a complete reindexing of the bib records, e.g.,
misc/migration_tools/rebuild_zebra.pl -b -r
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Signed-off-by: Claire Hernandez <claire.hernandez@biblibre.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Lists in the OPAC, and Cart on both sides, show the LOC code for items, rather
than the appropriate Description from Authorised Values. This is because the
code uses GetItemInfo, which is a very heavy-weight call to only retrieve some
of the desired information.
This patch introduces a new subroutine in C4::Items, GetItemsLocationInfo, which
returns the branch names for both home- and holdingbranches, the location code,
both opac and intranet location descriptions, itemcallnumber and cn_sort. This
should be used instead of GetItemsInfo in any case where the locational
information is all that's required, as it's much more streamlined and efficient.
In the OPAC Lists, this only applies if OPACXSLTResultsDisplay is 'off' (set to
'normal').
Signed-off-by: Jared Camins-Esakov <jcamins@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
The field was missing in Items.pm.
It will still act strangely if you enter a stocknumber that
already exists in the database. (see Bug 5860)
Adding/editing items with stocknumbers you have not used before
should work as expected.
[F. Demians] Was able to reproduce the bug on an UNIMARC DB. The patch works.
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Squashed commit of the following:
commit 66cdb8804136803a3f626d183c8f192f61f3c7b1
Author: Chris Cormack <chrisc@catalyst.net.nz>
Date: Fri Feb 4 12:55:10 2011 +1300
Bug 5691: Updating copyright statement
commit 79ef6c269afc9c644c51709a7657542a0fc6d7d6
Author: Chris Cormack <chrisc@catalyst.net.nz>
Date: Fri Feb 4 12:52:13 2011 +1300
Bug 5691 - Fixing a syntax error and tidying up some formatting
commit a66485dba113c05ed51a3b4ff19f788e335aa1f6
Author: Henri-Damien LAURENT <henridamien.laurent@biblibre.com>
Date: Tue Oct 5 17:23:55 2010 +0200
(MT #1365) Delete all items
Using DelItemCheck in cataloguing/additem.pl
when deleting all items
commit fe845fd48ab22ff82ad6d8971c468c327b49f3c4
Author: Christophe Croullebois <christophe.croullebois@biblibre.com>
Date: Wed Sep 22 11:39:28 2010 +0200
(MT #1365) Delete all items
Now if IndependantBranches is on and a user try to delete all items, only the items of his branch will be deleted.
A message explain this fact.
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Followup: (MT #1365) Fixing up the English idiom
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
MT3947: items.timestamp were not updated on edition
If items.timestamp is used in the framework and hidden
the fact that it is NOT deleted before update is done would input the previous timestamp,
which is not the desired behaviour.
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Squashed commit of the following:
commit f441094d5095d165eab18340c983a831cce8f6e0
Author: Henri-Damien LAURENT <henridamien.laurent@biblibre.com>
Date: Mon Jul 5 20:33:23 2010 +0200
bug4263 followup : Can't blank subfields
Previous bug4263 reintroduced bug 2466: fix clearing item field
This keeps bug4263 followup to be assigned (donot blank dateaccessioned)
But also allow to blank item subfields.
commit 92889b766c41b48bdd0e3a33ca4b183b1e259805
Author: Nahuel ANGELINETTI <nahuel.angelinetti@biblibre.com>
Date: Fri Apr 23 13:54:30 2010 +0200
(bug #4263) dateaccessionned is cleaned on item modification
Every item modification, date accessionned is cleaned, if there is no modification made, we must'nt reset to "undef" the value.
commit 5abb2db16b2564d32e84b7cc680acbc301d73179
Author: Nahuel ANGELINETTI <nahuel.angelinetti@biblibre.com>
Date: Tue Mar 2 09:57:33 2010 +0100
(bug #4263) fix the edition of items with repeatable subfields
The subfield management in item level is broken, fields are concatenated in one field, and if the librarian edit it, the values are not selected.
This big patch fix three things:
1) saving fields that are stocked in SQL(using koha2marc mapping) are now well cut and separated in _REAL_ subfields
2) loading records with repeatable subfields are now well returned
3) Editing items with repeatable fields works well
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Bug 4263 Removing extranious block of code
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Squashed commit of the following:
commit 105de81639cbac5084e4a5c099b19569043e69ff
Author: Nahuel ANGELINETTI <nahuel.angelinetti@biblibre.com>
Date: Tue Jul 13 11:58:01 2010 +0200
(bug #4931) fix forgottens input in buttons
the previous patch missed an hidden input in next buttons that break next page. This fix it.
commit db00295a6b9d1d36fc888ba6a0558011fd6884ba
Author: Nahuel ANGELINETTI <nahuel.angelinetti@biblibre.com>
Date: Fri Jul 2 15:27:59 2010 +0200
(bug #4931) add the ability to choose home or holding branch in stocktaking
This add radio box in stocktaking to base it on home or holdingbranch
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Bug 4391 Followup: Adding back lost declaration of $branchcode
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
This adds display of "Use restrictions" authorized values
to the OPAC and the staff client for available and
not-for-loan items.
Signed-off-by: Colin Campbell <colin.campbell@ptfs-europe.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Should fix any remaining warnings with 'podchecker'
Signed-off-by: Andrew Elwell <Andrew.Elwell@gmail.com>
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
if you have a marc field, mapped to items.stocknumber, it's not saved properly in items.stocknumber
Signed-off-by: Henri-Damien LAURENT <henridamien.laurent@biblibre.com>
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
* GetItemsInfo now includes a notforloan_per_itemtype key
with the value of the item type's notforloan setting, correctly
set based on the value of the item-level_itypes syspref
* Adjusted OPAC details item status display to use that
notforloan_per_itemtype key
NOTE: one of the assumptions of item-level_itypes is that
you can have either bib-level item types or item-level
item types, but not both in the same database. In particular,
it does not establish a hierarchy where Koha checks the
item-level itemtype first, then the bib-level.
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Also fix the barcode not found problem (due to empty lines)
Signed-off-by: Henri-Damien LAURENT <henridamien.laurent@biblibre.com>
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
This patch filters all non itemrelated fields in the marcrecord before making update
AddItemhad the same problem as ModItem
They would try and take fields which would not be item fields
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
The inventory tool was using itemcallnumber, title to sort; modified
Items.pm to use cn_sort, itemcallnumber, title so that call numbers
sorted on the padded sort field instead.
The default sort order for items attached to a title in staff mode is
items.dateaccessioned desc. This means that a particular library's holdings
will be scattered through the list -- a special problem when it comes to serial
issues. I've done a change to Items.pm that makes the sort order branch
description followed by dateaccessioned. Thus, a library's holdings will be
grouped together in the display.
* added POD
* removed optional $barcode argument - in all cases,
itemnumber is known, and we should stick with
itemnumber when retrieving an existing item
* use ModItem to do the update so that indexer
will know to reindex bib - otherwise, can't
do an accurate search of items that are on
the shelving cart.
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
Allows temporary locations corresponding to 'in processing' and 'shelving'
so that newly-created items, and newly-returned items do not show
immediately as a available. Three new system preferences govern the usage
of these features.
NewItemsDefaultLocation. If system pref NewItemsDefaultLocation is set to a location code,
all newly catalogued items will be set to the location set in this preference.
Location code must be a valid LOC authorized value type.
InProcessingToShelvingCart. if the system pref InProcessingToShelvingCart is turned on,
any items run through returns.pl with a location code for 'PROC', will be modified to
have a new location code of 'CART'.
ReturnToShelvingCart. If the syspref ReturnToShelvingCart is turned on,
all items returned other than confirmed holds will have a new location code of 'CART'.
Any item issued is automatically taken of the shelving cart.
Adds a cron script shelf_to_cart.pl which should be run hourly.
Updates all items with a location of CART to the item's permanent location.
The original location code is stored in the new items column 'permanent_location'.
Original Author: PTFS Contractor <dbavousett@ptfs.com>
This work co-sponsored by
Middletown Township Public Library, Middletown, NJ USA and
East Brunswick Public Library, East Brunswick, NJ USA
Signed-off-by: Colin Campbell <colin.campbell@ptfs-europe.com>
Signed-off-by: Galen Charlton <gmcharlt@gmail.com>
