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

Title level request: Future enhancements

    XMLWordPrintable

Details

    • Umbrella
    • Status: Draft (View Workflow)
    • TBD
    • Resolution: Unresolved
    • None
    • None
    • None
    • Not Scheduled
    • Vega
    • 0
    • R1
    • R2
    • TBD

    Description

      Current situation or problem: Title level requests (complete) was implemented in R1 2022 Lotus and R2 2022 Morning Glory. This feature is to collect enhancement requests for future development.

      Enhancements:

      • Item look-up by title (Title level requests offers title look-up tool. Folks want it for item level requests too)
      • Accordion heading "Open - Not yet filled" should be changed so that it does not match the request status, open - not yet filled
      • The publication field in Request details is populated by dateOfPublication. Because dateOfPublication allows for alphanumerics, if there is a date like "c1964", it will not display and "-" will show instead. To fix this we should use publicationPeriod. For more details, see comments in UIREQ-801
      • Identify orphaned requests - those that were submitted but are not able to be filled, either because no item records exist, or the associated patron is not eligible to request any of the items on the instance.
        • Identify TLR where the item status have changed since the TLR was placed that makes them ineligible for TLR.
      • Only show the request type(s) that can be fulfilled in the request page drop down. At the moment, the User must choose from the dropdown.
      • Improvment of the loans display.
        When a user placed a TLR, that should be visible in the Open loans displays of all current borrowers. Right now, you don't find any indication about the TLR there. Only when you try to renew an item, you receive a message. In the Open loans display the Value in Column “Request” is “0” for the item, because there is no request on THE SPECIFIC ITEM. But the value for each borrowed item of the title should be “1”  to improve useability.
        • Use case:
          A user is asking a staff member, why she/he cannot renew items. The staff member wants to check in the loan display if a TLR is placed and causing the declined renewal. In case that the user has many open loans, and does not remember which item she/he could not renew, it is absolutely necessary, that the staff member finds some useful information there.
      • TLR: Move page request when item is not found.

      Tested with page and hold allowed. You have two copies of a book, one checked out and one available (copy X). TLR results in page on copy X. When you look for the paged copy you can’t find it on the shelf. You mark copy X as missing/long missing/or something else.

      Expected result: Page is automatically transformed into a hold (or page on another copy if there would have been other available items). Alternatively, you can manually use “move the request” and change it to a hold when there are no items with status available.

      In scope

      Out of scope

      • We need the item call number in the display of the result list of requests (middle pane). This would help us managing our requests workflow especially in the stacks. Could this be included or worked on? https://issues.folio.org/browse/UIREQ-735 "Include call number in display of result list of Requests App" See UXPROD-3761
      • The receiving app should display that the instance has unfulfilled requests, as it currently does. Now there is no indication that the received item should be handled with urgency. It must first be checked in, which we normally don't do with newly received items as we want them to keep status In process. See UXPROD-3936
      • Disallowing title level requesting for items in certain locations (or libraries.) Use case: A single FOLIO institution has several general collection libraries and one library that has special collections. The general collection libraries want to have title-level requesting; the library with special collections does not.   See UXPROD-3980
      • Implementation of circ rules (either existing or new) to allow for prevention of requests if patron is not eligible. E.g. if instance A has items X, Y and Z, and the patron is not eligible to place an item level request on X, Y or Z, than they should not be able to place a title-level request on instance A.
        • Limit what items can be have a TLR placed on them based on a key in the Request policy. See UXPROD-3981

      Use case(s)

          • Circ rules use cases*

      As a staff member I want to restrict what items can have a TLR placed on them. Examples:

      • We want to allow requests on monographs but not serials or thesis.
      • We do not want to allow TLR on items in specific locations; such as new book shelf or new and note worth, but still allow TLR on copies in the regular stacks.
      • We may not want to allow undergraduates, or resident cards to place TLR requests but allow all other User groups.
      • If an instance record has a mix of item types, some allowing TLR and some ILR, this should be recognized by the system. If a patron is allowed via the policy to place a TLR it should be allowed, but only include those items that are TLR eligible. 
      • If an items status changes to so that it is TLR eligible this should be recognized by outstanding TLRs for that instance record.

      Proposed solution/stories

      Links to additional info

      Questions

      TestRail: Results

        Attachments

          Issue Links

            Activity

              People

                stephaniesbuck Stephanie Buck
                stephaniesbuck Stephanie Buck
                Votes:
                0 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                  Created:
                  Updated:

                  TestRail: Runs

                    TestRail: Cases