A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Request Title | request_description | productVersion | Request ID | Complexity Points | Total Votes R1 | Total Votes R2 | ||||||||||||||||||||
2 | Add “Conditional” to RapidILL | Sometimes libraries need to communicate things to each other that aren't citation issues. For instance, if a library has an HTML version of an article instead of a PDF with page numbers or a different edition of a book than the one listed in the request, that library might want to ask the borrower if that's an okay version for the patron. Right now the only way to communicate between libraries is through Bad Citation, and that doesn't allow libraries to respond to such queries. Adding a "Conditional"� status that allows libraries to ask and answer questions that aren't citation problems would help patrons get the items they need instead of requiring libraries to guess at whether what they have is sufficient. | RapidILL | 8558 | 8 | 878 | 1741 | ||||||||||||||||||||
3 | Configuration option for mandatory fields in the Rapido request form | Currently, there is no option for customers to set fields in the Rapido request form as mandatory (mark them with a red asterix, form can only be sent when field is not empty). However, it is not possible for libraries to fulfill requests where certain information is missing (e.g., no page numbers in digitization requests). We would appreciate if customers would become able to set any field in the form as mandatory such as it is already the case in the GetIt request forms in Primo VE. | Rapido | 8484 | 10 | 912 | 1577 | ||||||||||||||||||||
4 | Prevent multiple requests from a same borrowing library within a short period of time | Within a same day, we sometimes receive (in Alma) several RapidILL requests coming from a same institution for a same book or journal issue (native electronic materials or scans from physical materials): usually one request per book chapter, one request per article, etc., but sometimes, some of these requests are for multiple chapters or significant portions of a work. We assume that in most cases, these multiple requests come from a same requester, associated to the borrowing library. In addition to copyright issues that multiple request raise, it is unreasonable to expect a lending library to expend spending a lot of time to scan significant portions of a work. We don't expect any systematic mediation from borrowing libraries. This would increase the turnaround time, make the process heavier and slower for end-users and be in contradiction with encouraged integrations like Alma/RapidILL and Alma/Rapido. Instead, we would like lending libraries to have the possibility to limit the number of requests they receive from a same borrowing library for a same book or journal issue within a given (short) period of time. Example of configuration: "Maximum XX requests in YY hours for a same book or journal issue from a same borrowing library"�, where 'XX' and 'YY' would be numeric values to select from a drop-down list. Possible values for XX and YY should be defined in collaboration with the RapidILL and Rapido WGs. In case the values for XX or YY would be reached: 1) Any new request matching the limits should be assigned to another lending institution that owns the requested material. 2) The borrowing library should be informed that there is a risk of multiple requests from a same requester. The library could reach the requester, explain the resulting copyright issues and/or decide if possible to acquire the highly demanded material. 3) If no other library can provide the material, request should be cancelled and associated with a new 'Request Cancellation Reason' code in Alma. It is important that Resource Sharing requests that would be cancelled for such reasons explain the requester that requesting a too large part of a journal issue or book is not without consequences or risks. | RapidILL | 8530 | 20 | 587 | 1551 | ||||||||||||||||||||
5 | Ability to query RapidILL lending library from Alma | Sometimes we need to contact the library that supplied a RapidILL request to query the copy they provided. For example, supplementary material that was requested was not included, or the incorrect article/chapter was uploaded and sent to our user. At the moment, we need to find out the institution and send them an email. It would be much more efficient if we could query the 'completed' request via Alma to the Library. This functionality should update the request status and record the communication with the request. There is a Resupply request feature included in Rapido but is not currently possible within Alma Resource Sharing, so a similar solution would be useful. | RapidILL | 8487 | 10 | 486 | 1446 | ||||||||||||||||||||
6 | RapidILL: Option to include title/verso pages in chapter requests | Some RapidILL member libraries prefer to receive book chapter requests including the Title page and Verso (Copyright) page to provide additional context for referencing. To facilitate this, please could an additional checkbox be added to the Alma Resource Sharing form, appearing once the chapter or specific pages checkbox has been checked. This could be positioned directly below the chapter or pages checkbox, or below the form field for pages. A corresponding checkbox could be added to the Request Attributes section of the Lending Request General Information tab. Alternatively, could a configuration setting be added, which enables libraries to default the choice to have Title and Verso pages included in their chapter borrowing requests? Or, if it is deemed important for all members to provide Title and Verso as standard, could the RapidILL terms of service be amended to make this a mandatory step for member libraries when providing book chapters in answer to RapidILL lending requests? | RapidILL/Rapido/ALMA RS | 8481 | 11 | 371 | 1170 | ||||||||||||||||||||
7 | Rapido to parse all volume formats for multivolume works | Currently, when requesting volumes of multivolume works, the Rapido tile can only parse the following volume formats from the item description: "3" (digits only) "v.3" (no space) "v. 3" (with space) This affects the Refine Offer function: if the patron inputs a string that Rapido cannot parse (for example, "XII", "Jan", "Bd. 3" as written in the item description), it disregards that volume information. This usually gives a positive result (terms are displayed disregarding the volume's availability), places the request on title level (whole multivolume work) without linking the wanted volume (item) to the Rapido request. In such cases, the availability displayed by the Rapido offer is not entirely reliable, as the system does not identify the correct volume (item) but placed the request on the whole title (whole multivolume). For example, if the volumes' sequence is "Bd. 1", "Bd. 2", etc. - entering only "1" works. But entering the string "Bd. 1"; does not, and ends up in placing a request on the whole title (Rapido cannot parse the "Bd." string). Another example is for Multivolume works that do not have a digital sequence, but only with letters (A, B, C...), or even text ("Textbook"...). Rapido cannot parse these information so the request will always be placed on the whole title, disregarding the availability of the volumes. In such case, the patron can even send the request entering a volume that does not exist if the string contains an unrecognised format. We would like Rapido to consider other formats. For example with an "intuitive"parsing (e.g. as much "Bd. 3" as "Textbook", or "Vol. 3", "Volume 3", "A", Roman Numerals "I" etc.), or by displaying a dropdown menu with options based on what is filled in the items' description. | Rapido | 8513 | 15 | 713 | 1166 | ||||||||||||||||||||
8 | Rapido Closing Periods: Due Dates & Renewals | We noticed that Rapido does not consider closing periods entered in the calendar of the library. The due dates of Rapido requests are therefore not based on that calendar, while the due date of the loaned temporary item is. Consequently, a mismatch occurs, which in addition interferes with the renewals. We would like that: - Rapido considers the closing periods entered in the library calendar in Alma. - Rapido synchronises the borrowing and lending requests due dates. | Rapido | 8533 | 30 | 725 | 1106 | ||||||||||||||||||||
9 | Alma/Rapido notes: Reason for rejection should be passed on through RapidILL | Currently, the only notes passed on in a RapidILL-Alma integration are notes given as part of the Bad Citation workflow. When a lender rejects a Rapid request via ALMA, they can choose various reasons, such as in use on loan, lacks copyright compliance, etc. These rejection reasons do not currently show up on the Borrowing Request. Borrowing libraries need to be able to notify patrons with the reason their request was rejected. We propose that reasons for rejection are carried over into the notes of the Borrowing requests in ALMA. | RapidILL/Rapido/ALMA RS | 8494 | 8 | 431 | 1062 | ||||||||||||||||||||
10 | Reservations can be placed for digitization requests (RapidILL) | When a physical item is already on loan with a first patron, and a second patron wants to request the digitization of that same item, there should be an option to reserve the item for the second patron, so that when the physical item is returned by the first patron, it can immediately be scanned and sent to the second patron. | Rapido/RapidILL | 8539 | 45 | 745 | 862 | ||||||||||||||||||||
11 | Possibility to re-loan an item after the max. renewals possible at the pick-up library | We would like to have a parameterization option that allows the following: Items requested with Rapido that have reached the maximum renewal possibilities can be re-loaned at the pick-up library without having to be returned to the owning library - if there is no other reservation on that specific item. That means: Rapido should check if there is a reservation on that specific item. If yes, Rapido sends a warning message. This creates unnecessary inconvenience for users and the restriction doesn't exist in Alma RS. Increasing number of pod renewals is not a suitable solution in this scenario, we need to be able to manually override the limit when required. It would be particularly useful for an institution using Rapido to fulfil postal delivery/courier requests. See also the voting in Idea Exchange: https://ideas.exlibrisgroup.com/forums/935112-rapido/suggestions/46854874-possibility-to-re-loan-an-item-after-the-max-rene | Rapido | 8518 | 25 | 713 | 772 | ||||||||||||||||||||
12 | User identifier should be visible in requests for the lending library (for both Rapido and RapidILL) | Rapido/Consortia request: Some libraries would like to have the ability to share patron information with the lending libraries. Although, this is atypical in a traditional interlibrary loan approach due to privacy regulations, it would make sense for those using Rapido for consortial loans. We propose that libraries are able to OPT IN to sharing patron information (identifier/name/email) through a Rapido Resource Sharing Configuration setting. This enhancement would be integral for consortia with Network Zones, where lending libraries are forced to enquire for information from borrowing libraries on reciprocal end-users. User Case: We have 490 libraries in our consortia and we use restricted PODs that are limited to libraries within the consortia. It is important for both, physical and digital because with both formats libraries reported often needing to request for more information from patrons and patron information is shared across the entire country but Rapido hides it for the lending library. | Rapido | 8534 | 13 | 735 | 750 | ||||||||||||||||||||
13 | View requests that activated the Borrowing Copyright Rule | In Rapido, we have configured a copyright borrowing rule to prevent unmediated digital requests for more than one request from the same resource by a patron. When the rule is triggered on a new request, the request status is set to Pending Approval. For staff to decide whether to approve or cancel the request, they need to be able to see the previous request/s from the patron that activated the Borrowing Copyright Rule. Currently, they must search across all borrowing requests and determine which request activated the rule. This can be a time-consuming process. We would like an easy way to see the request/s that activated the rule. For example, the Pending Approval status could be hyperlinked, and when clicked on, the triggering requests display alongside the new request. On the patron side, we would like Primo to alert them that their request requires mediation. The alert could also take them to their request history in Primo and filter to the previously submitted requests that triggered the mediation. This would be beneficial in scenarios where they have placed a duplicate request, and they could potentially download the previously supplied request immediately. | Rapido | 8485 | 20 | 522 | 734 | ||||||||||||||||||||
14 | Resource sharing form: Pickup location field should only show on physical resource sharing requests | Users should not have to choose a pickup location for articles/book chapters that will be emailed to them. Current problem: In order to mandate users to fill out the field "pickup location" for physical resource sharing requests, we have to also require patrons to fill that field out for article and book chapter requests, which will be delivered digitally. We're running all digitization requests through the Rapido digital offer tile, not the Digitization function in Alma. The goal is to cut down on the amount of buttons/options our users have to choose from. The pickup location field is in the Resource Sharing Request form (Alma Config >Discovery>Resource Sharing Request). The problem is that this Resource Sharing Request form isn't smart enough to tell between a physical and a digital request. The "Pickup Location" field is in the "Delivery Fields" section, which applies to every request, regardless of format. In order to mandate our users to pick their preferred pickup location for physical requests, we have no other option than requiring them to fill out this form for article/book chapter requests too. This is an issue for multi-branch libraries who do not assign primary campuses to their patrons. As a large community college whose patrons take classes at multiple campuses, we do not have a way to assign a default pickup location in our user records. We are likely in the minority with this setup where our users can swirl between libraries and are not automatically tied to one campus, but this is a real pain point for us. Impact: Users will not have to select a pickup location for requests that will be delivered digitally. This will reduce confusion. | Rapido | 8562 | 8 | 385 | 585 | ||||||||||||||||||||
15 | Support issue and article-level linking | Rapid should support issue-level requesting. We would love our lending requests to come in with accurate issue level data. When RAPID provides a link to owned/licensed material for a document delivery request, we get journal-level data. But, it would be ideal if the link generated were for article-level links through the link resolver. When ILLiad performs the Rapid Holdings Lookup, Rapid returns a URL. Example of how the URL is formatted: http://rapid.exlibrisgroup.com/redirect?hash=NkM1MjZCMkExQzcxMTQxNDcwRUVCNTU5M0Y4RTJCNDk= The URL directs to the journal's landing page, not the article being requested. So, I am asking that RapidILL return article-level links for resources when a holdings lookup is performed. User story: As an institution using RapidILL's ILLiad integration, I want to receive article-level links to resources that Rapid has identified in our electronic holdings, so that staff spend less time searching electronic holdings and so that students are able to deliver requests without intervention from full-time staff. Related, we use 360 Link, also owned by Ex Libris, so perhaps there is an opportunity for cross-walking these products? | RapidILL | 8501 | 20 | 408 | 383 | ||||||||||||||||||||
16 | Offer the option to reactivate a Rapido request when it has been accidentally double scanned. | RAPIDO does not offer the option to reactivate a request when it has been accidentally double scanned on the lending side. This is available in classic resource sharing and the feature is helpful and saves time. We would like to see the base functionality available in ALMA Resource Sharing carry over to Rapido concerning the reactivate function. The reactivate function should stop the request from moving on to the next partner to avoid receiving multiple copies. | Rapido | 8077 | Solution provided | 1008 | |||||||||||||||||||||
17 | Populate the partner_code XML field in Resource Sharing Shipping and Return slips with Alma library code (Rapido) | Situation: We are using a 3rd party logistical company to deliver Rapido requests. After the shipping or return slips are printed in Alma, libraries are filling in the logistical details in the 3rd party system by picking the destination library from a list of libraries. We have around 500 libraries in our network and sometimes the names are similar. This leads to mistakes. Currently, the value in the XML field notificationdata/partnercode is always filled in with the name of the library and not its code. Idea: We would like the XML field notificationdata/partnercode in the Resource Sharing Shipping Slip and Resource Sharing Return Slip for Rapido requests to be populated with the alma library code. That way librarians can easier, quicker, and with more precision find the destination library in the 3rd party system. https://ideas.exlibrisgroup.com/forums/935112-rapido/suggestions/46650235-populate-the-partner-code-xml-field-in-resource-sh | Rapido | 8541 | Solution provided | 733 | |||||||||||||||||||||
18 | Elimination of the temporary Rapido items | Rapido was designed as a classic interlibrary loan tool. The developers have therefore also adopted the tradition of temporary copies for each interlibrary loan item. In SLSP (Swiss library service platform), however, we mainly use Rapido for direct lending (via courier or postal delivery) to our users. Thanks to a shared catalogue (network zone), shared terms of use, lending and item policies, as well as a shared user pool for the entire SLSP, this was already possible with Alma RS. Users ordered a copy directly to a desired pick-up library or by mail to their private address without a diversion via a "lending library", as was the case with classic interlibrary loan. With the introduction of Rapido, this direct route to the customer was abolished. With the creation of temporary records for each Rapido order, which reach the customer via a Rota, numerous problems arise. Here is a (non-exhaustive) list: - The temporary Rapido items inherit only some of the attributes of the original copy. For example, holdings that cannot be borrowed are offered for loan via Rapido because the copy guidelines of temporary copies (e.g. course reserves) are not passed on correctly. - Closing dates are not taken into account by the Rapido items. - The temporary item receives an artificial barcode that only exists in the system, but not as a real barcode/RFID tag. This makes many "scan in" or RFID functions impossible or leads to incorrect manipulations. - When creating the temporary Rapido records, there is asynchrony between the Rapido item and the original item. This leads, for example, to different loan periods and renewal options. - Rapido records are suppressed, but they still cause confusion in internal processes, e.g. in acquisitions. - When generating statistics and analytics reports, Rapido copies often do not appear or appear twice, so that many reports and statistics have to be regenerated and closely checked. - Due to the additional detours of the temporary item via the lending library, the borrowing library cannot see the name of the user to whom the copy was lent. This complicates many existing processes (user service, reminders, fines, replacements). We therefore ask for the elimination of these temporary items and dummy records, in favour of direct lending to users within the network zone, even beyond the various institution zones, while maintaining the improved transparency of fees and the easy ordering option in the Rapido Tile of PrimoVE. As eliminating temporary Rapido items would not suit all customers, this would need to be an opt-in feature which could be implemented if suitable. See also the voting in Idea Exchange: https://ideas.exlibrisgroup.com/forums/935112-rapido/suggestions/46892236-elimination-of-the-temporary-rapido-items | Rapido | 8517 | Not Applicable | 725 | |||||||||||||||||||||
19 | Items allowed for courier, personal delivery and document delivery for specific user groups (Rapido and RapidILL) | There are items which are only available for Rapido requests or document delivery (RapidILL) for specific user groups. There should be the possibility to provide selected items only for selected user groups. For courier/personal delivery (Rapido): The possibility to integrate a filter rule for specific user groups in "edit participating item section" could be a solution. Rapido lacks flexibility in that the items can be either requested by everyone or no one. In a consortia environment it is necessary to be able to restrict lending requests to specific user groups. | Rapido | 8537 | 60 | 720 | |||||||||||||||||||||
20 | Allow RapidILL requests for theses and dissertations | Currently RapidILL supports only requests for book chapter and journal articles, requiring an ISBN or ISSN standard number. We have identified a need and opportunity for RapidILL to also allow for requests for digital copies of entire theses and dissertations to be fulfilled by its borrowing/lending queues. For example, when a user is on the Proquest Theses and Dissertations Global database and finds a resource that is not available via an institution's subscription, the user is able to request the item via the "Get it" link resolver. This brings up the Resource Sharing form in Primo VE, which is used by RapidILL for document delivery requests. However, since RapidILL does not support dissertation requests, the system does not accept the dissertation standard number and the request is declined by RapidILL due to incorrect/unsupported citation information. Adding functionality to support dissertation document delivery requests would reduce the number of unfulfilled requests for users who discover theses content that is not included in an institution's licensed agreements. | Rapido/RapidILL | 7620 | Not Applicable | 492 | |||||||||||||||||||||
21 | Alma Borrowing Request Note | The Alma Borrowing Request Note should appear on all Rapid Lending requests: Rapid interface, Alma ISO and all other platforms. User Case: Israeli libraries submit Borrowing requests to RapidILL via Alma. However, the Request Notes (as submitted by our patrons) are not carried over to RapidILL, or to other systems, such as ILLiad or Tipasa. These Notes frequently include important information such as the necessity of Figures / Plates / EndNotes that could help a Lender accurately and successfully fill the request. As a work around, we add them to the Pages field or the Article Title field (which have a limited number of characters). Proposed Solution: We would like to see the "Borrowing Request Note" field in the "Request Attributes" section carry over to the RapidILL request. We suggest that these Notes appear in the Lender's Tasks' List on the lending side. Request notes should also be imported from other ILL systems into RapidILL and exported in kind. | Rapido/RapidILL/ALMA RS | 8512 | Not Applicable | 435 | |||||||||||||||||||||
22 | |||||||||||||||||||||||||||
23 | |||||||||||||||||||||||||||
24 | |||||||||||||||||||||||||||
25 | |||||||||||||||||||||||||||
26 | |||||||||||||||||||||||||||
27 | |||||||||||||||||||||||||||
28 | |||||||||||||||||||||||||||
29 | |||||||||||||||||||||||||||
30 | |||||||||||||||||||||||||||
31 | |||||||||||||||||||||||||||
32 | |||||||||||||||||||||||||||
33 | |||||||||||||||||||||||||||
34 | |||||||||||||||||||||||||||
35 | |||||||||||||||||||||||||||
36 | |||||||||||||||||||||||||||
37 | |||||||||||||||||||||||||||
38 | |||||||||||||||||||||||||||
39 | |||||||||||||||||||||||||||
40 | |||||||||||||||||||||||||||
41 | |||||||||||||||||||||||||||
42 | |||||||||||||||||||||||||||
43 | |||||||||||||||||||||||||||
44 | |||||||||||||||||||||||||||
45 | |||||||||||||||||||||||||||
46 | |||||||||||||||||||||||||||
47 | |||||||||||||||||||||||||||
48 | |||||||||||||||||||||||||||
49 | |||||||||||||||||||||||||||
50 | |||||||||||||||||||||||||||
51 | |||||||||||||||||||||||||||
52 | |||||||||||||||||||||||||||
53 | |||||||||||||||||||||||||||
54 | |||||||||||||||||||||||||||
55 | |||||||||||||||||||||||||||
56 | |||||||||||||||||||||||||||
57 | |||||||||||||||||||||||||||
58 | |||||||||||||||||||||||||||
59 | |||||||||||||||||||||||||||
60 | |||||||||||||||||||||||||||
61 | |||||||||||||||||||||||||||
62 | |||||||||||||||||||||||||||
63 | |||||||||||||||||||||||||||
64 | |||||||||||||||||||||||||||
65 | |||||||||||||||||||||||||||
66 | |||||||||||||||||||||||||||
67 | |||||||||||||||||||||||||||
68 | |||||||||||||||||||||||||||
69 | |||||||||||||||||||||||||||
70 | |||||||||||||||||||||||||||
71 | |||||||||||||||||||||||||||
72 | |||||||||||||||||||||||||||
73 | |||||||||||||||||||||||||||
74 | |||||||||||||||||||||||||||
75 | |||||||||||||||||||||||||||
76 | |||||||||||||||||||||||||||
77 | |||||||||||||||||||||||||||
78 | |||||||||||||||||||||||||||
79 | |||||||||||||||||||||||||||
80 | |||||||||||||||||||||||||||
81 | |||||||||||||||||||||||||||
82 | |||||||||||||||||||||||||||
83 | |||||||||||||||||||||||||||
84 | |||||||||||||||||||||||||||
85 | |||||||||||||||||||||||||||
86 | |||||||||||||||||||||||||||
87 | |||||||||||||||||||||||||||
88 | |||||||||||||||||||||||||||
89 | |||||||||||||||||||||||||||
90 | |||||||||||||||||||||||||||
91 | |||||||||||||||||||||||||||
92 | |||||||||||||||||||||||||||
93 | |||||||||||||||||||||||||||
94 | |||||||||||||||||||||||||||
95 | |||||||||||||||||||||||||||
96 | |||||||||||||||||||||||||||
97 | |||||||||||||||||||||||||||
98 | |||||||||||||||||||||||||||
99 | |||||||||||||||||||||||||||
100 |