When either weeding or finding individual items that should be removed
from the collection, circulation staff need an easy and efficient way
to mark items for discard/weed so that they can be sent to cataloging
staff for further resolution. Currently, only staff with cataloging
permissions can change an item status to discard/weed. As a result,
current workflow for circulation staff is to either mark items as
missing in order to place it in a status where it is invisible in the
public facing OPAC and not holdable, and/or to put items in a copy
bucket for later processing by cataloging staff. This enhancement
will provide the ability for circulation staff to directly mark an
item discard/weed similar to the process to mark an item missing or
damaged.
The following list outlines the changes proposed to make the above
possible. These changes include a few alterations to current behavior
when marking items as Missing or Damaged in order to make these
actions safer and to enhance consistency.
1. Add a Discard/Weed option to all Action and right-click menus
where Mark Item Missing and Mark Item damaged appear. This
command will allow those staff with the MARK_ITEM_DISCARD
permission to mark an item for Discard/Weed, i.e. change the
item's status to that of Discard/Weed.
The Mark Item options presently occur in menus on both the list
and detail views of Item Status, the Holdings View, Check in and
Renew Items, Record Holds, the Patron Holds list, the Pull List
for Holds Requests, and Holds Shelf.
2. A staff member will be permitted to mark an item's status as
Discard/Weed via this new menu option if they have either the
MARK_ITEM_DISCARD or UPDATE_COPY permission at the item's owning
library. This behavior is consistent with the current code for
changing an item's status via Mark Item Missing or Mark Item
Damaged. It is also consistent with the current back end code for
marking items in general.
3. If the item to be marked Discard/Weed is checked out to a patron,
a dialog will be presented to staff to allow them to cancel or to
continue with the operation. If staff choose to continue with the
operation, the item will be checked in before being marked
Discard/Weed.
Evergreen does not presently show a warning dialog to staff when
marking a checked out item as Missing or Damaged. Items marked as
Missing are not checked in before having their status changed, but
items to be marked Damaged are checked in. It is not the
intention of this development to change these aspects of marking
items Missing or Damaged.
4. If the item is in transit at the time it is marked Discard/Weed,
the staff will again be presented with a dialog prompting them to
continue or to cancel the action. If staff continue, the transit
will be aborted and the item's status changed to Discard/Weed.
As with checked out items, Evergreen does not currently prompt
staff before marking an item as Missing or Damaged. Furthermore,
the behavior is inconsistent with either of these statuses. If
and item to be marked Missing is in transit at the time, the item
has its status changed to Missing and the transit remains in
place. If staff attempt to mark such an item as damaged, the
attempt to mark the item silently fails.
Unlike with checked out items, this development does propose
changing the behavior of making items in transit as Missing or
Damaged to be consistent with that proposed for marking the item
Discard/Weed. The reason being that the leftover transits can
stick around in the system for quite a while, and if the item's
status ever changes back to available (which they do with more
frequency than one might wish), these transits can cause problems
for staff.
5. Should the item to be marked Discard/Weed be the only copy that
can fill one or more holds, a confirmation dialog will prompt
staff to continue or to cancel the operation. Should staff
continue, the item will be marked Discard/Weed. The holds will be
left for the hold targeter to deal with. This means that they
will likely go untargeted for some time until they reach
expiration. The holds should not be immediately canceled as a new
item could be added to fill the holds, or this item's status could
change in the future if staff decide that marking it Discard/Weed
was an error.
6. As marking an item Discard/Weed is one step away from deleting the
item, staff will be prompted for an override when they attempt to
mark an item that does not meet one of the previous criteria and
is in a status that has the restrict_copy_delete field set to
true. Marking the item's status will fail unless the staff person
has the COPY_DELETE_WARNING.override permission.
7. Items in other statuses, and that do not meet any of the criteria
in the previous points, will be marked Discard/Weed without any
additional prompts or conditions.
It is important to note that this proposal does not affect the ability
of staff to change an item's status via the Volume/Copy Editor or
other interfaces in Evergreen.
This development is sponsored by PINES.
While working on this today, I came up with some thoughts on the back
end code for marking items in the various statuses. The following
statements are all my opinion and the direction I am taking with the
code. If anyone disagrees, then please chime in.
1. Any item that is checked out, should be checked in before having
its status changed. Currently this only happens for marking an item
damaged.
2. All of the back end functions should accept and deal with the
handle_checkin argument. If the handle_checkin parameter is not
supplied, or is a false value as far as Perl is concerned, a new event
will be thrown: ITEM_TO_
3. If an item is in transit at the time its status is changed, then
the transit should be aborted before the status change. Currently,
this is not done for any status changes via the mark item back end.
4. A new handle_transit parameter will be added to the mark item
family. It will function in a similar manner to the handle_checkin
change mentioned in list item #2. The new event for this will be
ITEM_TO_
5. This is not a change in behavior, but a clarification: If the user
lacks any of the permissions to perform the mark item or any
associated actions, then an appropriate event will be returned. There
will be no chance to override this event.
6. The code for handling checkins and marking an item damaged actually
run before the user's permission to mark the item are checked. This
may not be a problem since everything is done in a transaction, but
this code will be moved below the check for the appropriate
permissions.
NOTE: This marks a departure from my original plan to not make as many
changes to the current behavior of marking items damaged or missing.
After starting on this, I decided that the users and the code would
benefit from more consistent behavior.