Comment 4 for bug 1779467

3/4) Cancelling transits. Remember that this development is for circ staff
to place items in discard/weed to then be deleted from the database by
cataloging staff, whether lost in transit or still in transit on the shelf.
Items lost in transit would be found with a report and would be handled
differently from those found on the shelf in transit, to be weeded. Either
way, the copy is to be deleted by cataloging staff and would no longer be
in the database and checking in would do no good if it did make it's way
back. I think the important thing with this is that the status of transit
is removed from the item to be placed in discard/weed, and that transaction
closed, so that cataloging staff can delete the item, without having a
transaction that would otherwise not be completed, hanging around in the
database.

J. Elaine Hardy
PINES & Collaborative Projects Manager
Georgia Public Library Service/PINES
1800 Century Place, Ste. 580
Atlanta, GA 30045

404.548.4241 Cell
<email address hidden>
Helpdesk: http://help.georgialibraries.org

On Tue, Jul 17, 2018 at 10:42 AM, Mike Rylander <email address hidden> wrote:

> Hi Jason,
>
> Regarding the points in comment #1:
>
> 1) I think this is probably correct /except/ for marking an item Lost.
> In that case, we're "blaming" the patron and it should stay on their
> items out list.
>
> 2) +1, that seems it will provide the flexibility to deal with future
> UIs where we might want to /not/ force a checkin -- and even provide a
> hook for a YAOUS to specify that behavior for existing UIs (as in, a set
> of "don't check in on marking BLAH" YAOUSen).
>
> 3) I disagree with canceling transits generally, not just for the
> feature you're working on. Since we have the barcode value available,
> then especially for marking discard/weed, but also for other statuses, I
> don't understand why we aren't simply changing the copy_status field on
> the transit. Then the transit will either naturally finish, and the copy
> will get the new status and trigger the routing event at checkin, or the
> barcode can be checked in if the copy is in hand. It's an extra step in
> the case of a copy that has disappeared while in transit, but it also
> avoids throwing out state information about the copy's location (on a
> truck). All that said, the deciding evidence would be whether it is
> more common for a copy to be lost in transit than to simply still be in
> transit. If lost-in-transit is more common, then I see the argument for
> canceling the transit. Otherwise, it just seems wrong -- the right
> thing will happen at the right time when the copy shows up.
>
> 4) Is this meant to allow editing of action.transit_copy.copy_status
> rather than canceling, or just to prevent the action via an event in the
> face of an outstanding transit? If the former, +1. ;)
>
> 5) Thanks
>
> 6) +1
>
> Thanks!
>
> --
> You received this bug notification because you are subscribed to
> Evergreen.
> Matching subscriptions: <email address hidden>
> https://bugs.launchpad.net/bugs/1779467
>
> Title:
> Enhance Mark Item Discard/Weed Functionality
>
> Status in Evergreen:
> In Progress
>
> Bug description:
> 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.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1779467/+subscriptions
>