Settings and activity
99 results found
-
27 votes
The product team will review this idea for consideration for a future release.
Jeremy Goldstein
supported this idea
·
An error occurred while saving the comment -
42 votes
The product team will review this idea for consideration for a future release.
An error occurred while saving the comment Jeremy Goldstein
commented
I know this idea had been submitted at least once previously, but I believe it aged out of the system, though I'm pretty sure it did have some decent support. Very happy to support it again as the lack of this capability is a perpetual annoyance I hear from staff
Jeremy Goldstein
supported this idea
·
-
31 votes
This will be implemented in Sierra in 2027.
An error occurred while saving the comment Jeremy Goldstein
commented
This is a critical issue, but also one that is far larger than this specific use case and I'm guessing has impacts on all dates and timestamps present anywhere in the system. For reference https://en.wikipedia.org/wiki/Year_2038_problem
Jeremy Goldstein
supported this idea
·
-
50 votes
The product team will review this idea for consideration for a future release.
Jeremy Goldstein
supported this idea
·
-
6 votes
An error occurred while saving the comment Jeremy Goldstein
commented
Without the ability to scan items in batch, I've found little incentive to use RFID over the phone's camera for scanning barcodes. There are certainly device limitations in play that would make this unhelpful for many users, but if you do have access to a peripheral such as the one @Shawn shared then adding batch scanning would enormously improve this system.
Jeremy Goldstein
supported this idea
·
-
21 votes
The product team will review this idea for consideration for a future release.
An error occurred while saving the comment Jeremy Goldstein
commented
I never understood why this report didn't include the primary identification point for the invoices it lists out. All invoices are generally referenced by the number assigned by the vendor that produced them and not the internal to Sierra voucher number.
There may be systems where those vouchers are used for something but I've been working with acquisitions with various libraries for nearly 20 years and haven't found one yet who did.Jeremy Goldstein
supported this idea
·
-
18 votesJeremy Goldstein
supported this idea
·
-
37 votes
An error occurred while saving the comment Jeremy Goldstein
commented
The lack of this feature is precisely the reason that our consortia opted to not move to LX Starter at this point in time. We love the editor and really want to be able to utilize this product but until centralized notices are available we simply cannot use this product.
Jeremy Goldstein
supported this idea
·
-
21 votesJeremy Goldstein
supported this idea
·
-
46 votes
An error occurred while saving the comment Jeremy Goldstein
commented
In the print/send orders function, it can be easy to accidentally upload an order to a vendor multiple times. As a means to mitigate this error I propose a two part feature.
As a first step, the system should provide some indication when viewing the orders to ftp queue if an order has already been ftp'd once. I could see two methods for accomplishing this. 1) Add a column to the queue display for sent date, taking the most recent date present that has been appended to the ISBN pick field in a record from having been previously sent. 2) highlight any orders in red or blue where a sent message already exists in an ISBN pick field, similar to how duplicate invoices are colored in the import invoices function.
The second potential piece of this would be to generate a pop-up message along the lines of "File contains previously sent orders, do you wish to proceed?" that would appear at the point where the individual orders are packaged together into a single file for uploading to the vendor. That message would allow staff the opportunity to back out if they wish and remove any offending orders before proceeding.
Jeremy Goldstein
supported this idea
·
-
12 votes
An error occurred while saving the comment Jeremy Goldstein
commented
For an additional use case we also have a number of libraries who are heavy users of x-records with invoices and in those cases the invoice is the only point where such a message could be triggered.
Jeremy Goldstein
supported this idea
·
-
11 votesJeremy Goldstein
supported this idea
·
-
10 votesJeremy Goldstein
supported this idea
·
-
12 votesJeremy Goldstein
supported this idea
·
-
71 votes
An error occurred while saving the comment Jeremy Goldstein
commented
We have received sooooooo many complaints about this system behavior over the years. Staff have had to waste an inordinate amount of time on deduping the produced lists, which has only gotten worse with the introduction of the pagination issue (SIERRA-38727) that was introduced in 6.0.
Jeremy Goldstein
supported this idea
·
-
72 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
·
-
17 votesJeremy Goldstein
supported this idea
·
-
22 votesJeremy Goldstein
supported this idea
·
-
41 votes
The ability to send a message to a selected group of patrons is planned as future functionality in LX Starter.
Jeremy Goldstein
supported this idea
·
I mostly like this a lot, just treat the API key as a user account, similar to how stat groups are assigned to users in Sierra. The only point of clarification I would put out there is I would still want some of the API endpoints to include a stat group parameter as well so that it is possible to use a variety of stat groups in some circumstances. For example our mobile app has a self checkout feature that needs to use a different stat group for different locations within our consortia. We would still like to issue a single API key to the support vendor for administering that. But in that case even it would still be useful to provide a default stat group other than 0 for the key, and just allow that to be overridden by an implicit stat group parameter as part of an API call.