Uploaded image for project: 'UX Product'
  1. UX Product
  2. UXPROD-1530

Implement Needed for in the Three-Part Item State

    XMLWordPrintable

Details

    • New Feature
    • Status: Draft (View Workflow)
    • P3
    • Resolution: Unresolved
    • None
    • None
    • None
    • Using dummy patrons to place requests or using check in notes to indicate where to send an item.
    • XL < 15 days
    • Low
    • XXL < 30 days
    • Hide
      No bulk editing of needed for
      Significant changes to check in process
      Show
      No bulk editing of needed for Significant changes to check in process
    • Prokopovych
    • 1
    • 93.1
    • R4
    • R4
    • R4
    • R1
    • R2
    • R1
    • R4
    • R2
    • R1
    • R2
    • R1
    • R1
    • R2

    Description

      Current situation or problem:

      Libraries need a way to indicate that an item is needed for staff workflows. Many libraries are used to doing this with features like check in / check out notes, or with fake patrons, but those are difficult to manage and tend to have a high rate of error because they must be maintained manually.

      In scope

      • Allow FOLIO users to create a list of "Needed for" values for their library.
      • Allow a FOLIO user with appropriate permission to assign one or more "Needed for" values to an item record.
      • Allow a FOLIO user with appropriate permissions to include a note with assigned Needed for values on an item record.
      • Allow a FOLIO user with appropriate permissions to remove a Needed for value from an item
      • Allow applying a "Needed for" value to trigger a recall if an item is out on loan
      • Display of those values across different apps
      • logic at Check In
        • Alert user when there is at least one of these values on an item
        • if there is at least one of these values on an item, change item status to In process when checked in (as opposed to Available)
        • if there is at least one of these values on an item and a patron request, require user to choose whether to fulfill patron request or not at check in

      Out of scope

      • Behavior in Check-in app (separate feature needed)
        • Alert to Needed for values when Checked in;
        • Change to appropriate item status at Check in (if different from Available)
        • Handle scenario with 1 or more patron request and 1 or more Needed for on same item
      • Behavior in Requests app/with requesting (separate feature needed)
      • Behavior in Orders app
      • Behavior in Requesting app

      Use case(s)

      • A library wants to send an item for binding at an outsourced binding company;
      • A library wants to indicate that an item needs to be sent to their preservation staff for physical repair;
      • A library wants to indicate that an item needs to be digitized to support availability of the item in an online collection;
      • A library wants to indicate that an item needs to be digitized to support controlled digital lending;
      • A library wants to indicate that an item needs to be pulled for original cataloging;
      • A library wants to indicate that an item needs to be pulled to be sent to an outsourced cataloging firm;
      • A library wants to indicate that an item needs to be prepared to be placed on exhibition;
      • A library wants to indicate that an item needs to be put on course reserve;
      • A library wants to indicate that an item needs to be pulled for a temporary themed collection;
      • A library wants to indicate that an item needs to be pulled for review and possible weeding;
      • A library wants to indicate that an item needs to be pulled for a mediated request process (e.g., special collections, locked stacks, etc.)
      • A library wants to indicate that an item is being planned for move to another location ("Move to Annex")

      Proposed solution/stories

      • General development approach
        • Settings page
        • Inventory
          • Item UI updates
          • Search filters
          • Instance display (holdings accordion)
        • Request whitelist behavior - hold, page, recall
        • Check in behavior - allow, allow/warn, prohibit
        • Check out behavior - allow, allow/warn, prohibit
        • Inventory search
        • Data import behavior
        • Data export behavior
        • Bulk edit behavior
        • Circ log updates - new events to capture, new filters, update existing filters
        • Canned reports
          • in transit items (inventory)
          • overdue loans, claim returned, cash drawer reconciliation, financial detail, refunds to process manually (users), hold shelf clearance (requests)

      TBD: Receiving app

      Links to additional info
      Examples and some additional details:
      https://docs.google.com/presentation/d/11BE_G1o-yBNg1ki8HyaDTdmkrP03_cR7KGjiXQviwuQ/edit#slide=id.g8b76928899_0_70
      https://wiki.folio.org/display/AppInt/Item+status+%28item+state%29+subgroup

      Questions

      TestRail: Results

        Attachments

          Issue Links

            Activity

              People

                Unassigned Unassigned
                dbranchini Darcy Branchini
                Michal Kuklis Michal Kuklis
                Marc Johnson Marc Johnson
                Votes:
                0 Vote for this issue
                Watchers:
                10 Start watching this issue

                Dates

                  Created:
                  Updated:

                  TestRail: Runs

                    TestRail: Cases