Settings and activity
117 results found
-
19 votes
Jeremy Goldstein supported this idea ·
-
8 votes
An error occurred while saving the comment -
13 votes
The product manager will review this idea for possible inclusion in a future release.
An error occurred while saving the comment Jeremy Goldstein commented
This is nice from a patron service standpoint but I know some of our member libraries would object given space constraints on their hold shelves not to mention the wasted labor on the part of staff retrieving the item and likely sending it through delivery.
I can certainly see the value for other libraries but this would really need to be an optional feature that organizations like us could opt out of.
Jeremy Goldstein supported this idea ·
-
22 votes
Jeremy Goldstein supported this idea ·
An error occurred while saving the comment Jeremy Goldstein commented
I would be thrilled to be able to use a similar editor to the one found in LXStarter for non-notice based templates. But I'm not sure if that is the right platform for this given that it is designed for actions that occur outside of Sierra and these very much need to be incorporated back into the client to be utilized.
-
7 votes
The product manager will review this idea for possible inclusion in a future release.
An error occurred while saving the comment Jeremy Goldstein commented
I can't believe I'm voting to support non-standard data but in this case absolutely. We often have to get creative with records and certainly have plenty of fully non-MARC bibs within our system for various purposes. The API shouldn't have a problem with those instances.
Jeremy Goldstein supported this idea ·
-
9 votes
The product manager will review this idea for possible inclusion in a future release.
Jeremy Goldstein shared this idea ·
-
12 votes
The product manager will review this idea for possible inclusion in a future release.
An error occurred while saving the comment Jeremy Goldstein commented
From my understanding (thanks in large part to Ray having passed along the response to a ticket he had opened) the hold_removed includes all holds that were cancelled, expired, or cleared from the holdshelf.
Then for filled holds they exist in the table for the period between when they have been filled and the subsequent time that clear holdshelf is run.
Jeremy Goldstein supported this idea ·
An error occurred while saving the comment Jeremy Goldstein commented
Or retain the data in the new hold_removed table for a longer period of time. Either would be quite helpful for projects. In particular we use hold data frequently as a gauge of patron demand so having a historical record of the demand for certain materials would be incredibly helpful.
-
11 votes
Jeremy Goldstein supported this idea ·
-
12 votes
An error occurred while saving the comment Jeremy Goldstein commented
These errors will occasionally show up in the client too so this is a bit broader of an issue than just the sql views.
There’s a glitch with the self checkout feature in our mobile app where if an item is rapidly scanned twice it doesn’t get checked out correctly and the only reason we know about that is the items wind up with a due date of 1969.
Jeremy Goldstein supported this idea ·
-
64 votes
This will be a part of the Renewal Journey feature
An error occurred while saving the comment Jeremy Goldstein commented
Yes, here is the enhancement on the LX Starter roadmap https://portal.productboard.com/iii/15-vega-product-portal/c/397-default-journeys
Jeremy Goldstein supported this idea ·
-
8 votes
The product manager will review this idea for possible inclusion in a future release.
Jeremy Goldstein supported this idea ·
-
14 votes
Jeremy Goldstein supported this idea ·
-
22 votes
Jeremy Goldstein supported this idea ·
-
4 votes
Jeremy Goldstein supported this idea ·
-
7 votes
Jeremy Goldstein supported this idea ·
-
16 votes
Jeremy Goldstein supported this idea ·
-
16 votes
Jeremy Goldstein supported this idea ·
-
56 votes
This idea has been selected to include in Sierra 6.4
Jeremy Goldstein supported this idea ·
-
21 votes
Jeremy Goldstein supported this idea ·
-
64 votes
An error occurred while saving the comment Jeremy Goldstein commented
For another use case, we use shared logins for nearly all of our user accounts and have a naming schema used for helping to identify the role each is used for (think circulation vs circulation supervisors). We have needed to modify that schema in the past, but doing so now means creating whole new accounts instead of simply updating our existing ones in order to fit with such a change.
Jeremy Goldstein supported this idea ·
I don't remember this previously, but looking at the Swagger documentation on our site there is currently a delete endpoint of /v6/patrons/{id}/checkouts/history/{checkoutHistoryId}, which is distinct from the delete endpoint /v6/patrons/{id}/checkouts/history for deleting the full history