Innovative Idea Exchange

Settings and activity

121 results found

  1. 9 votes
    How important is this to you?
    Jeremy Goldstein supported this idea  · 
  2. 8 votes
    How important is this to you?
    Jeremy Goldstein supported this idea  · 
  3. 7 votes
    How important is this to you?
    An error occurred while saving the comment
    Jeremy Goldstein commented  · 

    I understand the annoyance here when you don't use fines, but there are other issues that can occur as well from having a patron record open on multiple workstations.

    For a sadly common example among our libraries, if a patron checks out an item at one location, changes their mind, and has it checked back in at another terminal, if the account remained open on the original workstation the checkin will fail to occur without providing much of an indicator of that. In that case the patron now has an item checked out erroneously, and Sierra has incorrect data on where that item is currently located. Because of cases like this I would still want there to be a warning that the patron record needs to be closed, regardless of the fines issue.

  4. 7 votes
    How important is this to you?
    Jeremy Goldstein supported this idea  · 
  5. 12 votes
    How important is this to you?
    Jeremy Goldstein supported this idea  · 
  6. 16 votes
    How important is this to you?
    An error occurred while saving the comment
    Jeremy Goldstein commented  · 

    After a bit more experimenting I found another common occurrence that can lead to similar behavior. The parser seems to want the city and state to share a line of the address, and to either be separated by a comma, or for the state abbreviation to have both letters capitalized.

    "Boston, Ma" works as does "Boston MA". However "Boston ma" or "Boston Ma" does not.

    Jeremy Goldstein shared this idea  · 
  7. 11 votes
    1 comment  ·  LX Starter  ·  Admin →
    How important is this to you?
    Jeremy Goldstein supported this idea  · 
  8. 10 votes
    How important is this to you?
    Jeremy Goldstein supported this idea  · 
  9. 4 votes
    How important is this to you?
    Jeremy Goldstein shared this idea  · 
  10. 8 votes
    UNDER REVIEW  ·  2 comments  ·  LX Starter  ·  Admin →
    How important is this to you?
    Jeremy Goldstein supported this idea  · 
  11. 9 votes
    UNDER REVIEW  ·  1 comment  ·  LX Starter  ·  Admin →
    How important is this to you?
    Jeremy Goldstein supported this idea  · 
  12. 20 votes
    How important is this to you?
    An error occurred while saving the comment
    Jeremy Goldstein commented  · 

    Oh yes, I agree with Ray's comment fully it would be amazing to have an anonymized form of this data available.

    Jeremy Goldstein shared this idea  · 
  13. 17 votes
    How important is this to you?
    Jeremy Goldstein supported this idea  · 
    An error occurred while saving the comment
    Jeremy Goldstein commented  · 

    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.

  14. 10 votes
    How important is this to you?
    Jeremy Goldstein supported this idea  · 
  15. 10 votes
    How important is this to you?
    Jeremy Goldstein supported this idea  · 
  16. 21 votes
    How important is this to you?
    Jeremy Goldstein supported this idea  · 
  17. 21 votes
    How important is this to you?
    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  · 
  18. 24 votes
    How important is this to you?
    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  · 
  19. 23 votes
    How important is this to you?
    An error occurred while saving the comment
    Jeremy Goldstein commented  · 

    We encounter this quite a bit in our system as well and it is a cause of problems for patrons and confusion for staff.

    Jeremy Goldstein supported this idea  · 
  20. 23 votes
    How important is this to you?
    Jeremy Goldstein supported this idea  · 
← Previous 1 3 4 5 6 7