Settings and activity
87 results found
-
3 votes
Emma Olmstead-Rumsey
shared this idea
·
-
23 votesUNDER REVIEW · 5 comments · ILS - Polaris » Acquisitions, Serials & Item/Issue/Inventory Management · Admin →
An error occurred while saving the comment Emma Olmstead-Rumsey
supported this idea
·
-
11 votesEmma Olmstead-Rumsey
supported this idea
·
-
11 votes
An error occurred while saving the comment Emma Olmstead-Rumsey
commented
Yes, please! We would definitely use this feature.
Emma Olmstead-Rumsey
supported this idea
·
-
19 votesEmma Olmstead-Rumsey
supported this idea
·
An error occurred while saving the comment Emma Olmstead-Rumsey
commented
I believe cancellation notifications can be toggled on and off at a high level, but I like the idea of doing it more granularly.
We have cancellation notices turned off globally in our system precisely because we can't have them turned on without sending a million of them for every single unclaimed item. We don't float, so a held item that went to unclaimed will have been pulled off the shelf and put into our delivery run the next day. That's just about when the patron gets the cancellation notice and contacts us to say "wait, I still want that!" Then they have to wait a few days for it to be pointlessly chauffeured to its home branch, only to fill a hold and go straight back to the one it was just at on the hold shelf. My previous system did have those notices turned on and it created a LOT of frustration for patrons.
-
10 votes
An error occurred while saving the comment Emma Olmstead-Rumsey
commented
Is this different than what is already available in Admin Explorer-->Parameters-->Patron Services-->Patron delete options?
-
15 votesEmma Olmstead-Rumsey
supported this idea
·
An error occurred while saving the comment Emma Olmstead-Rumsey
commented
This seems technically challenging to implement but would be a really nice feature! We see the same thing happening in our system. it's very confusing and frustrating to patrons to be denied an automatic renewal only to look in the PAC the next day and see that the bib has no holds on it.
-
10 votesEmma Olmstead-Rumsey
supported this idea
·
-
3 votesEmma Olmstead-Rumsey
supported this idea
·
-
5 votesEmma Olmstead-Rumsey
shared this idea
·
-
21 votesEmma Olmstead-Rumsey
supported this idea
·
-
10 votesEmma Olmstead-Rumsey
supported this idea
·
-
23 votes
An error occurred while saving the comment Emma Olmstead-Rumsey
commented
The same problem happens at multi-branch systems that are not part of a consortium. We recently conducted interviews with patrons about our PAC, and *every single one* expected the combination of the Available Now facet and the location limiter to behave the way Matt described.
I was confused by this request when I first read it, so for anyone like me who might be reading this:
Suppose my library has two branches, East Branch and West Branch. We own two copies of "Don't Let the Pigeon Drive the Bus." The copy belonging to East Branch is checked out and the copy belonging to West Branch is on the shelf.
If I search in the PAC and limit my search to "East Branch items" AND "Available now," "Don't Let the Pigeon Drive the Bus" will show up in my search results even though there is not a copy on the shelf at East. "Available now" shows me all bibs that have at least one attached item in "In" status, and "East Branch" shows me all bibs that have at least one attached item assigned to East Branch.
This search setup is the number one complaint I get about our OPAC.
Emma Olmstead-Rumsey
supported this idea
·
-
7 votesEmma Olmstead-Rumsey
supported this idea
·
An error occurred while saving the comment Emma Olmstead-Rumsey
commented
I love this idea! It could be implemented in a lot of different ways, too, if the details didn't work out for this proposal. But the concept is important. Our patrons do not care what location a checked-out item is assigned to. They care about three categories: available at my current/preferred branch, available elsewhere, and not currently available. Checked-out items could be grouped under a checked-out 'branch'' at the bottom of the availability popup if they couldn't be hidden completely.
-
29 votesEmma Olmstead-Rumsey
supported this idea
·
-
28 votes
An error occurred while saving the comment Emma Olmstead-Rumsey
commented
There is a system admin setting that might or might not do this already, I don't 100% understand how it behaves. Admin Explorer-->Profiles-->Cataloging-->Automatic display in PAC processing.
If you have the bottom checkbox checked, I think you could accomplish this with current tools?
-
19 votes
An error occurred while saving the comment Emma Olmstead-Rumsey
commented
Hi Sam, we are using standard authentication, not OAUTH. Thanks for looking at this.
Emma Olmstead-Rumsey
shared this idea
·
-
9 votes
An error occurred while saving the comment Emma Olmstead-Rumsey
commented
Yes! We were on the fence about using it but ended up deciding to use it precisely because we didn't think we'd be able to stop staff from using it by accident.
The fact that the damaged 'status' is a sort of ghost status that only exists in Leap creates a lot of issues. It would be nice to be able to opt out of this new 'feature.''
Emma Olmstead-Rumsey
supported this idea
·
-
7 votesEmma Olmstead-Rumsey
supported this idea
·
An error occurred while saving the comment Emma Olmstead-Rumsey
commented
Yes, PLEASE!
-
10 votes
An error occurred while saving the comment Emma Olmstead-Rumsey
commented
This seems like it really needs to be fixed. Why not have one system-level table for this and allow entries in it to be suppressed or not at different libraries/branches? That is what is done for a lot of similar items and seems to be much 'safer' in terms of potential for error.
Emma Olmstead-Rumsey
supported this idea
·
I agree with Miles--we initially adopted this workflow and reverted back to our old one in part because of this problem. Since 'declared damaged' is weirdly only a status in Leap, and not its own status in the underlying client, none of our processes to review and delete records for items we no longer have would work with this status. We would only start using the workflow again if the status were regularized and this feature were added.