68 results found

1. Improving Hold Shelf Management in Sierra and IMMS

   We at the Libraries of Malmö would like to suggest that Innovative and Lyngsoe develop an interaction between Sierra and IMMS to help clear hold shelves.

   The issue: Currently, we have hold shelves at our libraries that are numbered between, for example 100 and 120. Each day we clear the holds that have expired the previous day. When we first implemented IMMS, we noted the shelf to clear down on a paper almanac and then wrote them off a week later.

   However, we have since then coded a very simple application to keep track of this for us. The application takes the holds that have expired the previous seven days (this is due to varying opening hours at our libraries), grabs the related barcodes from Sierra, and sends them to IMMS to retrieve the hold shelf. It then reports to the user, for example, “clear the shelves 101 and 103”.

   The application can also report the shelves used on a specific date, to help staff keep track of which shelf to use for new holds.

   Due to its simplicity, the app is prone to human error and not entirely reliable. For example, clearing the holds in Sierra will make it impossible to retrieve the shelves from IMMS, because the application uses the status ! in the item, which is cleared when the clear expired holds and hold shelves function is used. We feel that a better solution would be for Innovative and Lyngsoe to develop this functionality within the Sierra Library Management System.

   We at the Libraries of Malmö would like to suggest that Innovative and Lyngsoe develop an interaction between Sierra and IMMS to help clear hold shelves.

   The issue: Currently, we have hold shelves at our libraries that are numbered between, for example 100 and 120. Each day we clear the holds that have expired the previous day. When we first implemented IMMS, we noted the shelf to clear down on a paper almanac and then wrote them off a week later.

   However, we have since then coded a very simple application to keep track of this for us. The application… more

   •  

   12 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to Have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. Add timestamp to "Suspended" field in user account

   Problem:

   Our practice is to suspend user accounts when a staff member leaves, rather than delete it, so that we can copy the necessary permissions when a replacement is hired. We then try to delete the accounts after 6 months, but there is currently no method within the Admin App or SQL that tells you when a login was suspended, so we have to track that manually.

   Value: adding a timestamp to this field would enable us to more seamlessly manage user accounts for our large consortia and ensure that unnecessary logins are periodically purged.

   7 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to Have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Add an API endpoint which permits writing to review files

   Currently, when a query is beyond the capabilities of Create Lists, it is usually possible to use a SQL query with Python to produce a report. Such a report might list record numbers of bibs/items/orders/patrons/etc which bear further examination and correction by library staff, but staff must copy record numbers or barcodes in the report and paste them into the SDA to pull up the records in question. It would be much easier if an API endpoint permitted those record numbers to be written to a review file so staff can go through them one-by-one in the SDA.

   Another use case for such an endpoint would be the development of record import routines with features which do not exist in the current Create Lists record import facility.

   Currently, when a query is beyond the capabilities of Create Lists, it is usually possible to use a SQL query with Python to produce a report. Such a report might list record numbers of bibs/items/orders/patrons/etc which bear further examination and correction by library staff, but staff must copy record numbers or barcodes in the report and paste them into the SDA to pull up the records in question. It would be much easier if an API endpoint permitted those record numbers to be written to a review file so staff can go through them one-by-one in the SDA.

   Another use… more

   10 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to Have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   UNDER REVIEW  ·  AdminMike Dicus (Product Manager, Innovative) responded

4. Add a Stat Group When Creating a Patron API Key for Vendors

   This proposal suggests enhancing the Patron API key creation process by incorporating a Stat Group field, allowing staff to categorize API keys by vendor and track their usage using existing reporting tools. The proposed enhancement would modify the API key creation window to include an optional Stat Group field towards the bottom. If left blank, the default stat group (zero) would be assigned, maintaining current functionality. This change addresses a common issue where vendors do not implement the stat group provided by the library, often resulting in API-driven transactions being categorized under stat group 0. This leads to inaccurate or inflated statistics, which is particularly problematic when the library intends to track circulation usage via the API but cannot do so effectively.

   To expand tracking capabilities, it would also be beneficial to explore the feasibility of retroactively assigning a Stat Group to existing API keys. The implementation of this feature could leverage the workflow used for SIP2 license logins as a model for designing the Stat Group selection process when creating new API keys. Additionally, hold requests currently store the stat group within the body of the request rather than in the URL. Understanding this distinction may help in designing the stat group functionality for API keys in a way that aligns with existing data structures and workflows.

   The implementation of this proposal would provide several benefits. It would enable staff to categorize API keys by vendor, allowing more precise tracking and facilitating data collection and reporting using existing tools such as Web Management Reports and Decision Center. It would also improve visibility into vendor-specific API key usage, supporting data-driven decision-making and reducing reliance on stat group 0 as a catch-all category, ultimately leading to more accurate circulation statistics.

   This enhancement would streamline reporting efforts and provide better insights into vendor-specific API key usage, ultimately improving resource management and decision-making processes.

   This proposal suggests enhancing the Patron API key creation process by incorporating a Stat Group field, allowing staff to categorize API keys by vendor and track their usage using existing reporting tools. The proposed enhancement would modify the API key creation window to include an optional Stat Group field towards the bottom. If left blank, the default stat group (zero) would be assigned, maintaining current functionality. This change addresses a common issue where vendors do not implement the stat group provided by the library, often resulting in API-driven transactions being categorized under stat group 0. This leads to inaccurate or… more

   24 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   5 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to Have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   UNDER REVIEW  ·  AdminMike Dicus (Product Manager, Innovative) responded

   The product team will review this idea for consideration for a future release.

5. Create a GET API endpoint for circulation transactions

   This idea came from a discussion at the IUG2025 Sierra Reporting Forum.

   It would be very useful to provide an endpoint to assist with gathering/generating the sorts of circulations statistics that would normally require SQL access. However, the all or nothing nature of SQL permissions is a barrier that prevents many users from being permitted to access those features. With the API on the other hand a user could be limited to simply having read access to an endpoint such as this, along with likely the bib and item endpoints so that they may craft reports without also having to have access to tables that should remain secured.

   This idea came from a discussion at the IUG2025 Sierra Reporting Forum.

   It would be very useful to provide an endpoint to assist with gathering/generating the sorts of circulations statistics that would normally require SQL access. However, the all or nothing nature of SQL permissions is a barrier that prevents many users from being permitted to access those features. With the API on the other hand a user could be limited to simply having read access to an endpoint such as this, along with likely the bib and item endpoints so that they may craft reports without also having to… more

   21 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   5 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to Have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   UNDER REVIEW  ·  AdminMike Dicus (Product Manager, Innovative) responded

   The product team will review this idea for consideration for a future release.

6. Add ability to extend the hold Pickup By date to the /v6/patrons/holds/{holdId} API endpoint

   Currently the only hold parameters one can modify via the API are

   PatronHoldPut {
       pickupLocation (string, optional): the hold's pickup location code,
       freeze (boolean, optional): whether the hold should be frozen (suspended)
   }

   It would be very helpful if the Pickup By date – and while you're at it, the Hold Note – were added as modifiable parameters.  There have been many times when unscheduled branch closures or problems in sending hold pickup notices have caused us to want to extend hold Pickup By dates for items on the holdshelf.

   Having this functionality in an API endpoint would permit a programmatic solution for mass-extending Pickup By dates instead of the tedium of manually modifying each affected hold, which can and has taken me many hours to slog through.

   As for the Hold Note, I can't think of a particularly compelling application for that parameter addition right now, but I'm sure someone would benefit from that.  And like I said, while you're in the code adding the Pickup By date, why not add Hold Note too?

   Currently the only hold parameters one can modify via the API are

   PatronHoldPut {
       pickupLocation (string, optional): the hold's pickup location code,
       freeze (boolean, optional): whether the hold should be frozen (suspended)
   }

   It would be very helpful if the Pickup By date – and while you're at it, the Hold Note – were added as modifiable parameters.  There have been many times when unscheduled branch closures or problems in sending hold pickup notices have caused us to want to extend hold Pickup By dates for items on the holdshelf.

   Having this functionality in an API endpoint would permit a… more

   15 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   UNDER REVIEW  ·  4 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to Have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

7. Create RestAPI with a Patron Validate role that updates the “last circ activity date” in patron record 

   Our library wants to provide the patron validate role to our vendors.
   But, we do not want to give the vendors any read or write roles.

   We do this now with several vendors, but the authentication does not update the "last circ activity" field in the patron record.

   Is it possible to add a new permission that would only allow authentication but update the "last circ activity" field in the patron record.

   Why add this feature?
   Our library purges patron that don't circulate for X number of years. We don't want to delete patrons that are actively using our eVendor content.
   We want to give our eVendors as little read/write permissions as possible.

   Thank you.

   Our library wants to provide the patron validate role to our vendors.
   But, we do not want to give the vendors any read or write roles.

   We do this now with several vendors, but the authentication does not update the "last circ activity" field in the patron record.

   Is it possible to add a new permission that would only allow authentication but update the "last circ activity" field in the patron record.

   Why add this feature?
   Our library purges patron that don't circulate for X number of years. We don't want to delete patrons that are actively using our eVendor… more

   17 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   UNDER REVIEW  ·  3 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to Have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

8. Restart a Range of Terminals

   Sierra 6.5 saw the move of the process for restarting terminal sessions from our text-based management tool to the Sierra Admin App. While I'm chuffed enough about that to be writing this enhancement idea on Thanksgiving Day (and to be using the word chuffed), I'm hoping further development can make it even better & restore some of the functionality from the admin app that isn't available in this updated interface.

   Specifically, I'd like to be able to restart a range of terminals (for example, all staff sessions), mirroring the Restart Multiple Terminals option in text-based. Yes, we can check a box next to listed sessions to restart several at once, but it's much easier to say, "Restart everything from line 30-142."

   Sierra 6.5 saw the move of the process for restarting terminal sessions from our text-based management tool to the Sierra Admin App. While I'm chuffed enough about that to be writing this enhancement idea on Thanksgiving Day (and to be using the word chuffed), I'm hoping further development can make it even better & restore some of the functionality from the admin app that isn't available in this updated interface.

   Specifically, I'd like to be able to restart a range of terminals (for example, all staff sessions), mirroring the Restart Multiple Terminals option in text-based. Yes, we can check a… more

   •  

   •  

   4 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to Have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

9. More universal accessibility features

   Improving universal accessibility features for users/employees with diverse accessibility needs.

   For example, for employees with visual impairments :
   - High contrast mode and adjustable font size. Currently, users can change text color and size, but increasing the font size often causes content to be hidden, as the window does not automatically adjust. Users must manually resize the window each time. A responsive layout would greatly improve usability.

   Other potential improvements could include : screen reader compatibility, customizable keyboard navigation, text descriptions for icons, etc.

   Even just the high contrast would help a lot. Additionally, it would be helpful if users could personalize their accessibility settings through their individual initials, without affecting the default settings for all users using the same login.

   Improving universal accessibility features for users/employees with diverse accessibility needs.

   For example, for employees with visual impairments :
   - High contrast mode and adjustable font size. Currently, users can change text color and size, but increasing the font size often causes content to be hidden, as the window does not automatically adjust. Users must manually resize the window each time. A responsive layout would greatly improve usability.

   Other potential improvements could include : screen reader compatibility, customizable keyboard navigation, text descriptions for icons, etc.

   Even just the high contrast would help a lot. Additionally, it would be helpful if users… more

   14 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   UNDER REVIEW  ·  2 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to Have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

10. Ability to view history for item and volume records.

    It would be helpful for us to have access to the history of item and volume records, including details of their creation and any subsequent edits. This would improve our ability to track changes and ensure accountability if any issues come up.

    25 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    5 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to Have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    PLANNED  ·  AdminMike Dicus (Product Manager, Innovative) responded

    This enhancement is planned for Sierra 6.6.

11. Automatic SSL Certificate Renewal

    Keeping our systems secure with SSL certificates is essential. Certificates need to be renewed and there is a service commitment to handle this process. But there is a better way. SSL providers can be setup to automatically renew and deliver an updated SSL certificate to our systems when their expiration time approaches.

    This idea is for Innovative to support software-only site with setting up an automatic SSL renewal process thereby keeping our systems safe from expiring certificates and making the process worry-free.

    21 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to Have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    UNDER REVIEW  ·  AdminMike Dicus (Product Manager, Innovative) responded

    The product team will review this idea for consideration for a future release.

12. Batch Check-In Should Not Update Circactive Date

    Batch check-in is a necessary component of debt write-off and system maintenance. Running this process updates the patron account circulation activity date (CIRCACTIVE) even though this is a system-generated process and not initiated by the patron.

    We use the CIRCACTIVE date when reporting on card usage, and as an indicator of when to delete inactive cards. Because the date is updated through batch check-in, we have to do a lot of clean-up work to understand actual patron usage and behavior.

    Ideally, batch check-in should not update CIRCACTIVE. It would be fine for the account UPDATED date to be updated.

    This may apply to other batch, administrative tasks that are completed by the library and not the actual patron.

    Batch check-in is a necessary component of debt write-off and system maintenance. Running this process updates the patron account circulation activity date (CIRCACTIVE) even though this is a system-generated process and not initiated by the patron.

    We use the CIRCACTIVE date when reporting on card usage, and as an indicator of when to delete inactive cards. Because the date is updated through batch check-in, we have to do a lot of clean-up work to understand actual patron usage and behavior.

    Ideally, batch check-in should not update CIRCACTIVE. It would be fine for the account UPDATED date to be updated.

    This… more

    23 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    3 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to Have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    UNDER REVIEW  ·  AdminMike Dicus (Product Manager, Innovative) responded

    The product team will review this idea for consideration for a future release.

13. Insert/Update Location Codes from a CSV file

    Develop a utility to add new location codes to the so-called Branches table using a CSV file as input. Optionally permit updates (overlays) of existing location code entries so that the branch_code_num, name and/or is_public columns may be reassigned values in this way.

    Our library has very granular location codes which describe branch (or collection subset of a branch such as a display area), audience, format and genre, loosely speaking. This amounts to 220-250 location codes per branch (or collection subset). We currently have over 5,000 distinct location codes in our Sierra database, and every time a new branch is established or renamed, a lot of manual effort is required to add or update those location code entries one at a time.

    Using SQL to extract current location codes, and SQL, Excel or a text editor to perform string substitutions, a CSV file can be prepared fairly quickly. This utility would not have to be customer-facing; supplied with a CSV file uploaded as part of a Service Commitment, Support could run it. This would save development effort on a pretty user interface.

    Develop a utility to add new location codes to the so-called Branches table using a CSV file as input. Optionally permit updates (overlays) of existing location code entries so that the branch_code_num, name and/or is_public columns may be reassigned values in this way.

    Our library has very granular location codes which describe branch (or collection subset of a branch such as a display area), audience, format and genre, loosely speaking. This amounts to 220-250 location codes per branch (or collection subset). We currently have over 5,000 distinct location codes in our Sierra database, and every time a new branch is… more

    10 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    UNDER REVIEW  ·  1 comment  ·  System Administration & APIs  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to Have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

14. 2038 issue

    We use the patron's 18th birthday as their youth card expiration date. Due to the Year 2038 issue we have been unable to add the correct date for several years now. We would really like to be able to have (any/all) date fields updated so we can begin to record accurate future dates again.

    28 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    6 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to Have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    UNDER REVIEW  ·  AdminMike Dicus (Product Manager, Innovative) responded

    The product team will review this idea for consideration for a future release.

15. Create Granular Permissions for Editing Permissions for Select Group of Users

    We would like to see more granulated permissions for user administration, especially with assigned permissions, settings, options, workflows, etc.

    We would like the ability to assign a particular group of user accounts (e.g., circ student employees) to a specific admin (e.g., head of circulation) without assigning ALL system administration. It would be helpful for troubleshooting and having this department be able to assign macros, specific permissions, and print settings to different accounts.

    Ideally, this "group admin" would have the ability to edit settings on accounts for options, settings, and workflows. It would be great if they could clone and create a new account from within their group as well.

    I am thinking about Springshare's LibStaffer software and how the app's overall admins can be different than the individual schedule admin. That sort of granularity for user accounts here would be useful.

    This would enable us to allow our supervisors more ability to assist their employees when troubleshooting before forwarding it onto sys admins.

    We would like to see more granulated permissions for user administration, especially with assigned permissions, settings, options, workflows, etc.

    We would like the ability to assign a particular group of user accounts (e.g., circ student employees) to a specific admin (e.g., head of circulation) without assigning ALL system administration. It would be helpful for troubleshooting and having this department be able to assign macros, specific permissions, and print settings to different accounts.

    Ideally, this "group admin" would have the ability to edit settings on accounts for options, settings, and workflows. It would be great if they could clone and create… more

    9 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    UNDER REVIEW  ·  0 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to Have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

16. Restart a Range of Sessions/Processes in Admin App

    Sierra 6.5 saw the move of the process for restarting terminal sessions from our text-based management tool to the Sierra Admin App. While I'm chuffed enough about that to be writing this enhancement idea on Thanksgiving Day (and to be using the word chuffed), I'm hoping further development can make it even better & restore some of the functionality from the admin app that isn't available in this updated interface.

    Specifically, I'd like to be able to restart a range of terminals (for example, all staff sessions), mirroring the Restart Multiple Terminals option in text-based. Yes, we can check a box next to listed sessions to restart several at once, but it's much easier to say, "Restart everything from line 30-142."

    Sierra 6.5 saw the move of the process for restarting terminal sessions from our text-based management tool to the Sierra Admin App. While I'm chuffed enough about that to be writing this enhancement idea on Thanksgiving Day (and to be using the word chuffed), I'm hoping further development can make it even better & restore some of the functionality from the admin app that isn't available in this updated interface.

    Specifically, I'd like to be able to restart a range of terminals (for example, all staff sessions), mirroring the Restart Multiple Terminals option in text-based. Yes, we can check a… more

    •  

    •  

    •  

    •  

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  System Administration & APIs  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to Have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

17. Improve server security by supporting Apache module mod_security

    With the increase in bot attacks causing DOSS downtime, it is important to be on top of server security. The Apache module "modsecurity" has been around for over 20 years and there is an active community creating rules (https://coreruleset.org/) to block bot attacks. I think that Innovative should include modsecurity in their Apache build and actively support or provide the option to its customers to include rules to increase server security.

    3 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  System Administration & APIs  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to Have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

18. Abililty for Sierra's NCIP responder to be able to parse ISBNs

    Right now NCIP for Symphony, Voyager, Polaris, Koha and Evergreen all accept ISBNs, but Sierra's does not.

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    UNDER REVIEW  ·  1 comment  ·  System Administration & APIs  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to Have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

19. /v6/patrons/{id}/holds/requests/form API endpoint should accept item record numbers as parameters in addition to bib record numbers

    The form endpoint is used to identify cases in which a patron must place a volume level hold or is restricted to an item's home library as a pickup location. Both of those involve item level specifics and yet the endpoint only works with bib records. This is an issue in particular with multi-location libraries/consortia who use the home pickup feature.

    As an example, a sample bib record has two attached items, one which uses the home pickup feature such that it may only be picked up at library A, and one that does not restrict pickup locations so may be picked up at libraries A, B, or C. Because the endpoint returns valid pickup locations for title level holds, it will always return the full list of locations and there is not a way for the end user to know that one of the items may only be picked up at library A.

    Allowing the endpoint to provide item level details would resolve that, though it would also mean testing out individual item records in advance of actually placing holds in all cases in order to see if this restriction is in place...which I don't love. So I'm open to alternative suggestions to fix this feature but this seemed like the smallest ask to me.

    The form endpoint is used to identify cases in which a patron must place a volume level hold or is restricted to an item's home library as a pickup location. Both of those involve item level specifics and yet the endpoint only works with bib records. This is an issue in particular with multi-location libraries/consortia who use the home pickup feature.

    As an example, a sample bib record has two attached items, one which uses the home pickup feature such that it may only be picked up at library A, and one that does not restrict pickup locations so may… more

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    UNDER REVIEW  ·  0 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to Have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

20. Provide full Branches table and full Location code list via Sierra REST API

    Today, Sierra’s REST API does not provide a reliable way to retrieve a complete list of location codes (and their names/labels) as defined in Sierra’s Branches table (SDA: Admin > Parameters > General > Branches). This creates friction for discovery-layer implementations and other third-party integrations that require an authoritative, up-to-date list of locations.

    Innovative Support shared that “it’s not possible to get a list of all locations using the REST API,” and that the closest option is the branches endpoint, which only returns locations that are linked to entries in the Branch Address table, not a full representation of the Branches table. Fiona (BiblioCommons) also confirmed the current Branches API is insufficient and has requested III improve it to return a full representation of the Branches table.

    Current behavior

    When calling:

    GET /v6/branches/?fields=%2C

    We receive only two branch entries and an API response showing:

    "total": 2 (implying only two branch records exist), even though our environment contains many more branch/location entries in the Branches table.

    The response includes a locations array, but only for locations linked to Branch Address table entries.

    Example (truncated):

    {
    "total": 2,
    "start": 0,
    "entries": [
    {
    "id": 1,
    "name": "Poudre River Public Library District",
    "locations": [
    { "code": "adult", "name": "Adult" },
    { "code": "afic", "name": "Adult - Fiction" },
    ...
    ]
    },
    {
    "id": 2,
    "name": "Interlibrary Loan"
    }
    ]
    }

    Desired behavior

    Provide a REST API mechanism to retrieve a complete, authoritative list of:

    All Branches table entries (not only Branch Address table entries that have names populated), and/or

    All location codes as defined in the Branches table, including their display names/labels and other relevant metadata used by integrations.

    Why this matters (impact and use cases)

    This enhancement would significantly improve Sierra interoperability with third-party vendor products and local applications by enabling real-time retrieval of location configuration data.

    Primary use case: Discovery layers

    BiblioCore, Aspen Discovery, and Vega Discover (and similar products) need accurate location codes and labels to support:

    facets and scoping

    branch/location-based availability display

    collection/location grouping rules

    pickup location logic

    suppression or “hidden” locations behavior where applicable

    Right now, when a library:

    adds a new location code,

    renames a location display label,

    retires/deprecates a location,

    …they typically must manually communicate those changes to the discovery vendor (often via spreadsheets/emails/tickets). That adds delay, introduces errors, and makes “near real-time” configuration synchronization impossible.

    Secondary use cases (beyond discovery)

    internal analytics/reporting tools that want to label circulation/hold data by location

    AMH/bin mapping, routing, or sorting optimization tooling

    self-check, RFID, or third-party circulation peripheral integrations

    custom staff apps and dashboards that need the live location dictionary for validation and display

    Proposed solution options

    Any one of these would solve the problem. More than one would be even better.

    Option A: Enhance /v6/branches to represent the full Branches table

    Return all branch/location records stored in the Branches table, not just those tied to Branch Address entries with names.

    Add a way to request “Branch Address fields” separately (since Branch Address and Branches table are distinct concepts in practice).

    Option B: Add a dedicated endpoint for locations

    For example:

    GET /v6/locations

    GET /v6/branches/locations

    Option C: Provide an “includeAll” style flag
    If III wants to preserve current default behavior, add something like:

    GET /v6/branches?includeAll=true

    GET /v6/branches?source=branchesTable vs source=branchAddressTable

    Improving access to the Branches table / locations dictionary via REST API would be a major interoperability win for Sierra. The main theme is discovery layer integration (BiblioCore, Aspen Discovery, Vega Discover), but the same capability would benefit many other integrations and local applications that need accurate, real-time location metadata.

    Today, Sierra’s REST API does not provide a reliable way to retrieve a complete list of location codes (and their names/labels) as defined in Sierra’s Branches table (SDA: Admin > Parameters > General > Branches). This creates friction for discovery-layer implementations and other third-party integrations that require an authoritative, up-to-date list of locations.

    Innovative Support shared that “it’s not possible to get a list of all locations using the REST API,” and that the closest option is the branches endpoint, which only returns locations that are linked to entries in the Branch Address table, not a full representation of the… more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  System Administration & APIs  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to Have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating