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

Configure Allowable Item Statuses for Different Request Types

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Draft (View Workflow)
    • Priority: P4
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Template:
      UXPROD features
    • Potential Workaround:
      Hide
      Cate Boerema: Rely on hard-coded mappings/whitelist currently in place. If an institution wants to further limit the kinds of requests a patron can make they can limit the options available through discovery (e.g. only allow discovery to initiate holds or recalls). Training can be used to limit the types of requests staff create. Finally, request policies will also limit the requests that can be made . In discussion with the RA SIG, this seemed like an approach many could live with until we had custom item states (see comments below).
      Show
      Cate Boerema: Rely on hard-coded mappings/whitelist currently in place. If an institution wants to further limit the kinds of requests a patron can make they can limit the options available through discovery (e.g. only allow discovery to initiate holds or recalls). Training can be used to limit the types of requests staff create. Finally, request policies will also limit the requests that can be made . In discussion with the RA SIG, this seemed like an approach many could live with until we had custom item states (see comments below).
    • Epic Link:
    • Front End Estimate:
      Medium < 5 days
    • Back End Estimate:
      Large < 10 days
    • Confidence factor:
      Low
    • Estimation Notes and Assumptions:
      Hide
      Assumes none or very limited changes to check in decision making relating to requests (e.g. between in transit and awaiting pickup)
      Assumes setting will be provided either by a new interface in mod-circulation-storage or by standard interface in mod-circulation
      Assumes no changes to the way status is defined (remain as text, no migration to controlled vocabulary)
      This is likely at the very top of the large estimate window for the backend work
      Show
      Assumes none or very limited changes to check in decision making relating to requests (e.g. between in transit and awaiting pickup) Assumes setting will be provided either by a new interface in mod-circulation-storage or by standard interface in mod-circulation Assumes no changes to the way status is defined (remain as text, no migration to controlled vocabulary) This is likely at the very top of the large estimate window for the backend work
    • Development Team:
      Prokopovych
    • Calculated Total Rank:
      83
    • PO Rank:
      67
    • PO Ranking Note:
      Hide
      2020-10-04 - CB: Making my PO rank same as the calculated total rank for now.
      2019-07-12: Per SIG discussion, most could live without this until we had custom statuses. The go-live ranking don't seem to have been updated so I lowered using PO ranking
      Show
      2020-10-04 - CB: Making my PO rank same as the calculated total rank for now. 2019-07-12: Per SIG discussion, most could live without this until we had custom statuses. The go-live ranking don't seem to have been updated so I lowered using PO ranking
    • Rank: Chalmers (Impl Aut 2019):
      R4
    • Rank: Chicago (MVP Sum 2020):
      R2
    • Rank: Cornell (Full Sum 2021):
      R2
    • Rank: Duke (Full Sum 2021):
      R1
    • Rank: 5Colleges (Full Jul 2021):
      R4
    • Rank: FLO (MVP Sum 2020):
      R1
    • Rank: GBV (MVP Sum 2020):
      R2
    • Rank: Grand Valley (Full Sum 2021):
      R2
    • Rank: hbz (TBD):
      R2
    • Rank: Hungary (MVP End 2020):
      R1
    • Rank: Lehigh (MVP Summer 2020):
      R2
    • Rank: Leipzig (Full TBD):
      R1
    • Rank: MO State (MVP June 2020):
      R4
    • Rank: TAMU (MVP Jan 2021):
      R2
    • Rank: U of AL (MVP Oct 2020):
      R2

      Description

      Some institutions allow holds on available items and other do not. Some allow holds on on order items while others don't. The purpose of this feature is to enable tenant level configuration of which requests types are allowed for which item statuses (availability). Per SIG, this feature becomes particularly important when we have implemented custom statuses. I have linked that feature up as related to this one (UXPROD-1535)

      Until this feature is implemented, the allowed item states for holds, recalls and page requests will be hard-coded as shown in the request whitelist document.

      Notes added after estimates:

      1. When working out the design for this feature, we need to determine whether some institutions may want to have different request to item status configurations by location and how that would be handled.
      2. Also need to consider whether the other item states ("needed for" and "process") may need to factor into requestability

      Initial wireframe: https://drive.google.com/file/d/1kBS0rJqqEVR1FB9nTT-YNbM5uDD0K-xE/view?usp=sharing

        TestRail: Results

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                brookstravis Brooks Travis
                Reporter:
                cboerema Cate Boerema
                Front End Estimator:
                Michal Kuklis Michal Kuklis
                Back End Estimator:
                Marc Johnson Marc Johnson
                Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                  Dates

                  Created:
                  Updated:

                    TestRail: Runs

                      TestRail: Cases