Settings and activity
107 results found
-
10 votes
Wes Osborn
supported this idea
·
An error occurred while saving the comment -
5 votesWes Osborn
shared this idea
·
-
32 votesWes Osborn
supported this idea
·
-
19 votesWes Osborn
supported this idea
·
An error occurred while saving the comment Wes Osborn
commented
This should also extend to the similar authority processing jobs. I didn't know those even existed and we have them back to 2009! We'll delete them through SQL, but it seems unfair not to extend this to other customers who don't have access to SQL.
-
21 votesWes Osborn
shared this idea
·
-
39 votes
An error occurred while saving the comment Wes Osborn
commented
We are evaluating discovery layers and having this in Vega would help put it on par with competitors (coming in Bibliocommons).
Wes Osborn
supported this idea
·
-
4 votes
An error occurred while saving the comment Wes Osborn
commented
You might also want to add this comment here on the product board: https://portal.productboard.com/iii/6-innovative-product-status-board-new/c/753-expresscheck-update
-
6 votesWes Osborn
shared this idea
·
-
74 votes
An error occurred while saving the comment Wes Osborn
commented
This would be very important for any hosted customers who don't have direct access to SQL to perform record set cleanup.
Wes Osborn
supported this idea
·
-
55 votesWes Osborn
supported this idea
·
-
6 votesWes Osborn
shared this idea
·
-
20 votesWes Osborn
supported this idea
·
An error occurred while saving the comment Wes Osborn
commented
If this can't be implemented, the Leap patron bulk change process should make it clearer that you must change the patron's registered branch. Right now that is pretty unclear, whereas in the client it would give you a more specific error message.
-
32 votesWes Osborn
shared this idea
·
-
20 votesWes Osborn
shared this idea
·
-
33 votes
An error occurred while saving the comment Wes Osborn
commented
Although in an ideal world, I suppose it might be nice for the patron to have a preferred area for "each" branch. Just extending the single branch + preferred pickup location would be a huge help for us. In fact renaming this setting/option from preferred to default might better reflect that there can only be one per patron account.
Wes Osborn
shared this idea
·
-
14 votesWes Osborn
shared this idea
·
-
9 votesWes Osborn
shared this idea
·
-
36 votes
An error occurred while saving the comment Wes Osborn
commented
This can be done through the API and through SIP today. You need to contact Overdrive and ask them to map your current barcodes to the patron ID. You'll probably need to send them a mapping file as part of the migration process. Nothing will change for your patrons except for if they get a new barcode, when they log into libby with that new barcode, they'll see the same account information that was their from their previous account.
-
144 votesWes Osborn
supported this idea
·
-
79 votes
An error occurred while saving the comment Wes Osborn
commented
This would make so many staff happy and would be a great feature to entice people over to leap who aren't already using it.
Wes Osborn
supported this idea
·
This is a correct assumption, here is what we were told in 2015 (at that time we put in an enhancement to ask it to use the bib id # instead or the UPC):
Format
LCCN
Author
Title
Volume
Issue
Publication Year
ISBN (the system matches on the 1st ISBN in each record)
In order for a request to be considered a duplicate, each of the above fields must match in both request workforms. For example, if the format listed in request A is DVD, the format in request B must also be DVD. Similarly, depending on how complete the record being used to create the request is, certain fields in the request workform may be blank. If this is the case, that field must be blank/null in both requests in order for it to qualify as a duplicate.
It is possible that two records with different, but similar, titles could be considered duplicates. An example of this would be if you had two DVD’s both released in 2014 and one was titled Le Chef, while the other was titled Chef. Should a patron place a request for these two titles, they would visibly match on the publication year and format. However, because the stored procedure used to check for duplicate requests checks both the Browse Title and the Sort Title of a record, it will also find a match there. While the Browse Title for these would not be a match (LE CHEF and CHEF), because the Sort Title drops the initial article of ‘Le’, requests for these two titles would be determined to be duplicates.