...

Currently neither edge_rtac nor edge_patron are able to fulfill the requirement.!!!!!!

Solution approaches

When designing edge_rtac and edge_patron, an attempt was made to avoid overlaps between the interfaces. As demonstrated in the example
above, this cannot be sustained.
In this paragraph we discuss where/how the missing connection between the user's characteristics and those of the medium can be mapped.

Introduction of an additional interface (For example edge_patron-rtac)

It is obvious to outsource functions that cannot be directly assigned to a separate interface. On the other hand every new interface brings new
complexity. Such an additional interface would obviously have a lot of overlaps with edge_rtac and edge_patron. To avoid duplicate code, the
existing interfaces would have to be reworked as well.

Extension of the availability information (edge_rtac)

To consider properties of a reader edge_rtac would have to know the login data. On the other hand, edge_rtac must also work without login. This
would result in two different working modes for edge_rtac: "Without login vague information" vs. "With login exact information". The second mode
would correspond to the third interface discarded above, but would be clearer to assign.
For a search interface, such an approach had only the disadvantage that existing availability information (hit list) would have to be reloaded after a login.

Extension of the user interaction (edge_patron)

In contrast to edge_rtac, edge_patron always knows the ID of the copy and the reader. Accordingly, a two-step workflow would be conceivable: 1.
fetch the exact availability information; 2. order according to the obtained information.
The first step would again correspond to the third interface (or the 2nd mode for edge_rtac), would be logically most inappropriate assigned to
edge_paron.Split

Partitioned expansion of both interfaces

The non-overlapping design of edge_rtac and edge_patron can be preserved if both interfaces are slightly extended in their context.edge

* edge_rtac

...

extends the basic availability

...

by information about restrictions

...

of the availability, partly as a list for
different user groups.

For this extension edge_rtac does still needs not need to know the ID of the reader. It is sufficient if the interface becomes more talkative and outputs as much loan
relevant information as possible.

* edge_parton offers the possibility of a

...

mock order, to query the individual patrons state,
individual restrictions (lock, ...) and individual options (pickup location, ...).

The concept of a blind mock order can be adopted from the basically comparable interface PAIA. The procedure is as follows:1.

1. If the reader wishes to place an order/reservation, this is requested without additional information (collection location, ...). This triggers a
   test order in the library system. This test order does not lead to any change in the loan status. But, as with a 'normal' order, all borrowing
   rules are evaluated to determine any and restrictions/options. (restricted list of possible pickup locations, list of possible delivery options,
   info on individual restrictions, ...).

...

1. With the result of the query, the search interface generates a dialog box in which:

   ...

   1. 1. the reader is informed why the order/registration is not possible for you. (E.g.: Blocked due to too many open charges).

   ...

   1. 1. the reader has the possibility to select order parameters. (pick-up location, delivery option, cost transfer, ...)

   ...

   1. The search interface sends the order/reservation with selected parameters to the interface. In the library system, this triggers a regular
      order attempt.

   ...

   1. The search interface informs about the success of the order.

   The current behavior of edge_patron is already similar. Currently To place a hold currently at least the parameter 'pickupLocationId' (pickup location ) id' is expected for an
   order/registration. If this is missing . Without edge_patron reacts with an error message. At this point a blind an mock order could also be triggered, which returns the
   lists of possible options. to do a full evaluation.
   (Currently such a blind mock order is not yet supported, bur requested -> Tickets).

   Summary
   

   Even though they are possible in principle, the first three possibilities seem incossistentinconsistent.

   • An additional interface would confuse more than help.
   • The extension only of 'edge_rtac', would disturb the flow in the search interface
   • Extending only 'edge_patron' would blur the clear separation to edge_rtac.

   In contrast, the split partitioned extension of the both interfaces fulfills the requirements of the example without any problems and without logical breaks.

   Appendix

   More application examples

   Of course, there are many other framework conditions besides the example above that need to be covered with the approach discussed above. In the
   following, further basic examples are outlined and it is examined whether the solution described above is sufficient.

   
   Remote locations 1

   ...

   Environment

   ...

   1. A library has two library locations.

   ...

   1. Local stock should not be able to be ordered.

   ...

   1. Stock from site 'A' should be able to be ordered to site 'B'.

   ...

   1. Stock from site 'B' should be able to be ordered to site 'A'.

   ...

   1. The library has a search interface that does not require registration for research.

   Discussion

   This example has two aspects:1.

   • edge_rtac
     The

   ...

   • discovery system needs the information that local ordering

   ...

   • is limited by place.

   ...

   • edge_patron
     

   ...

   • The mock order returns only issue pickup locations from other locations like that of the specimen. (a use case of UXPROD-2689)

   Remote locations 2

   Framework

   ...

   1. In a departure from the previous example, there is a privileged group that is also allowed to order locally.

   ...

   1. Additionally, there is a third group that is allowed to order locally for a handling fee.

   Discussion

   1. edge_rtac
   The orderability constraint should be specified as a property of the group.{"limitations":[
   {"place" [
   {"normalos": "reading room only"},
   {"privileged": "in-houseonly"}
   ]}
   ]}
   Exampl
   e
   {"limitations":[

   
   

   
   {"duration" [
   {"normalos": "shortened loan, 3d"},
   {"privileged": "shortenedloan, 7d"}
   ]}
   ]}
   Exampl
   e
   2. edge_patron
   The pickup locations are filtered by readerandcopy. In the 'payer' group, the interface can ask whether to order locally for a fee. The
   amount of the fee is supplied like the list of pickup locations from the blind mock order.
   

   Reading room

   ...

   Environment
   

   
   1. A library has a collection order for an area. Media that have been procured for this purpose may not leave the building, but can be viewed.
   2. Some of the media are stored in a closed magazine. For reading, these can only be ordered to special reading rooms. There the media can
   be used exclusively during the loan period.
   3. Additionally, there is a trusted group that is allowed to order to other pickup locations in the house.

   
   Discussion

   1. edge_rtac
   The orderability constraint should be specified as a property of the group.
   2. edge_patron
   The pickup locations are filtered based on readerandcopy.

   
   Short-term loan

   ...

   Environment

   1. For some media (blank book collection) shortened lending times apply from the usual standard

   Discussion

   1. edge_rtac
   To allow the interface to indicate shortened lending times. The restriction should be specified as a property of the group.
   2. edge_patron
   The pickup locations are filtered based on readerandcopy

   {"limitations": [
   {"duration" [
   {"normalos": "shortened loan, 3d"},
   {"privileged": "shortened loan, 7d"}
   ]}
   ]}
   Example