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

CRUD service points



    • Large < 10 days
    • XL < 15 days
    • XL < 15 days
    • New endpoint for processing centers, potentially new endpoint for the relationship/association. An an indicator on the loan for processing center used so it can go in the Loan actions table
    • Prokopovych
    • R1
    • R1
    • R1
    • R1
    • R1
    • R1
    • R1
    • R1
    • R1


      Ability to CRUD a list of service points for the tenant. I think we can probably use the UX pattern we've used for Loan policies. There will be a name and some metadata (description etc). Service points are a conceptual center of Operations. These may NOT have loan rules directly applied to it.

      These service points will be used in a variety of ways:

      • You will be able to set up a workstation (e.g. a circ desk) so that it is associated with a "service point" (UXPROD-260) CB: Actually going to do this differently, see notes below
      • You are then able to limit users' permissions to specific service points. So users may have different permissions depending on the workstation they are working from. (UXPROD-37) CB: After further discussion, the RA SIG doesn't think this is a top priority. See notes below.
      • We may want to associate users with a service point (UXPROD-4)
      • There may be different versions of the institutional calendar for the various service points (UXPROD-72)
      • We need a way to associate service points with locations so you know which circ desk, for example, covers
      • Circ desks need to be associated with physical locations in such a way that, when an item is checked in, the system knows whether it is “home” or if it needs to go in transit back to the physical location it calls home. (UXPROD-270)
      • Etc...

      April 5, 2018

      There were some questions about where service points should "live" architecturally. I have some information that might help inform that decision. Tagging jakub, marcjohnson, kurt here. Please tag others if I missed anyone.

      There is no need to filter by service points in the FOLIO UI, but we will want to be able to generate lots of reports with service point data. For example, items loaned at a service point, holds at a service point that have expired, which locations are associated with service points etc.

      Some service points will not be circulation-related (e.g. binderies) so if there is a scenario in which a folio tenant doesn't have circulation enabled (not sure this makes sense in reality), we want service points to still be available functionality.

      I also have more information about how service points are associated with transactions. We will not be attempting to tie workstations to service points as initially discussed. Instead, we need a way to to set the allowed service points for a FOLIO operator (staff user) as well as a default for that user. Then, when that user logs in, the service point is automatically set to their default. They can then change to another as long as it’s in their list of allowed service points.

      There was also some further discussion as to whether we need to support limiting the scope of a FOLIO operator's permission by service point. Apparently this is something systems offer, but it didn't seem like a top priority to the RA SIG and we need to have more conversations with other SIGs about permission scope limits and what is really needed. We might end up doing permission scope limiting by locations instead (or some component of a location like libraries).

      TestRail: Results


          Issue Links



                cboerema Cate Boerema
                cboerema Cate Boerema
                Cate Boerema Cate Boerema
                Jakub Skoczen Jakub Skoczen
                Jakub Skoczen Jakub Skoczen
                0 Vote for this issue
                2 Start watching this issue



                  TestRail: Runs

                    TestRail: Cases