62 results found

1. Create user permissions/roles for limiting SierraDNA access

   We have had a number of instances recently in which a vendor has requested SQL access in order for us to utilize there services. We are hesitant to allow for that (and have policies against it) due to the quantity of secure data that would also provide access to.

   What we need is a way to provide lesser SQL access to particular users to allow them to tap into only the relevant tables (bibs & items for some. Circ_trans and patrons for others).

   Beyond the vendor scenario it would also be fantastic to provide limited access to more of our library staff. As a consortia, we have many of our member libraries who could truly benefit from being able to work with their record data but as long as doing so also provides access to things like staff account usernames and the limit network access table we can't open that access up to more of our own users.

   We have had a number of instances recently in which a vendor has requested SQL access in order for us to utilize there services. We are hesitant to allow for that (and have policies against it) due to the quantity of secure data that would also provide access to.

   What we need is a way to provide lesser SQL access to particular users to allow them to tap into only the relevant tables (bibs & items for some. Circ_trans and patrons for others).

   Beyond the vendor scenario it would also be fantastic to provide limited access to more of our… more

   18 votes

   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

   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

2. Create expanded RestAPI endpoint for patrons/validate that exposes a limited set of patron fields

   We have many vendors who have a need to check data in a few patron record fields as part of their authentication process. Fields such a ptype, home library, the expiration date, etc...are necessary to confirm that a patron is affiliated with the institution subscribing to that vendor's resource and that their card remains in good standing are necessary to provide. However, doing so currently requires providing the patron read permission, which also exposes a variety of additional sensitive data that these vendors should not have access to for their needs (PII, checkouts, fines, reading history, etc.)

   The lesser patron validate role merely runs a binary check on a barcode/pin combination to ensure that data matches a patron in the database. We really require there to be something in-between those two extremes, more like the legacy non-rest API.

   We have many vendors who have a need to check data in a few patron record fields as part of their authentication process. Fields such a ptype, home library, the expiration date, etc...are necessary to confirm that a patron is affiliated with the institution subscribing to that vendor's resource and that their card remains in good standing are necessary to provide. However, doing so currently requires providing the patron read permission, which also exposes a variety of additional sensitive data that these vendors should not have access to for their needs (PII, checkouts, fines, reading history, etc.)

   The lesser patron… more

   15 votes

   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

   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

3. 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

   43 votes

   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

   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

4. Add ability to query empty review files to the reviewFiles API

   This idea is a bit of an addendum to Bob Gaydos' idea to create an endpoint that allows writing to review files (https://ideas.iii.com/forums/951745-ils-sierra/suggestions/50308716).

   The current API cannot provide a list of empty files. That information would be incredibly helpful in conjunction with the other idea so that you may programmatically identify an available review file of sufficient size for your needs. Beyond that, it may be useful to use the API to write an alert mechanism for when your system may be running low on available files.

   It is possible to explore this information via SQL, but the permissions are so much more granular with the APIs so there is an advantage to being able to set up an API key with access for these tasks that would not have access permissions for other more sensitive parts of the system.

   This idea is a bit of an addendum to Bob Gaydos' idea to create an endpoint that allows writing to review files (https://ideas.iii.com/forums/951745-ils-sierra/suggestions/50308716).

   The current API cannot provide a list of empty files. That information would be incredibly helpful in conjunction with the other idea so that you may programmatically identify an available review file of sufficient size for your needs. Beyond that, it may be useful to use the API to write an alert mechanism for when your system may be running low on available files.

   It is possible to explore this information via SQL, but the… more

   9 votes

   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

   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

5. Export RFID Pad Server Settings

   At my library, the installation of RFID equipment & the entry of the required IPs in Sierra are handled by two different departments. Typically, I'll see a ticket that a new PC/RFID pad has been added & receive a request that the IP be added to Sierra.

   In addition to the RFID Pad Server Settings table in Sierra, we maintain a separate spreadsheet of assigned IPs, machine names & information on when & whom the request came from to add or replace them.

   While adding & replacing more than 20 IPs this morning, it dawned on me that this process, or at least a periodic check to make sure that only valid/in use IPs are included in the table & that what's in the table matches other records that we keep (like that spreadsheet) would be improved if we could export what's in the table to more easily compare what's recorded elsewhere.

   At my library, the installation of RFID equipment & the entry of the required IPs in Sierra are handled by two different departments. Typically, I'll see a ticket that a new PC/RFID pad has been added & receive a request that the IP be added to Sierra.

   In addition to the RFID Pad Server Settings table in Sierra, we maintain a separate spreadsheet of assigned IPs, machine names & information on when & whom the request came from to add or replace them.

   While adding & replacing more than 20 IPs this morning, it dawned on me that this process,… more

   •  

   4 votes

   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

   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

6. REST API-compatible Time to Holdshelf/Time to Reshelve

   Our library has deprecated the classic WebPAC in favor of a REST API-based custom discovery layer, but the Time to Holdshelf/Time to Reshelve temporary status message we've configured isn't included in the API response. It would reduce frustration for staff and patrons if we could implement a delay before items appear to be on the shelf when patrons check our website or mobile app.

   Please add the temporary status to the REST API response.

   7 votes

   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

   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

7. Sierra Patron Address info updates

   The Sierra Patron Record is able to be communicated to Vega Discover in such a way that differentiates the following fields:

   Street Address Line 1
   Street Address Line 2
   City
   State
   Postal Code
   Country

   ---

   Discover does not parse Sierra addresses correctly.

   1) New Discover registrations do not parse correctly in Sierra.
   2) Existing registrations in Sierra do not parse correctly in Discover.

   This was the comment by Innovative Staff on this topic:
   Discover does have difficulty with parsing Sierra patron addresses, and this is not changing in the July release. For libraries who do allow patrons to edit their own home address, making Discover parse and edit Sierra patron addresses better would require development.

   The Sierra Patron Record is able to be communicated to Vega Discover in such a way that differentiates the following fields:

   Street Address Line 1
   Street Address Line 2
   City
   State
   Postal Code
   Country

   ---

   Discover does not parse Sierra addresses correctly.

   1) New Discover registrations do not parse correctly in Sierra.
   2) Existing registrations in Sierra do not parse correctly in Discover.

   This was the comment by Innovative Staff on this topic:
   Discover does have difficulty with parsing Sierra patron addresses, and this is not changing in the July release. For libraries who do allow patrons to edit their own… more

   6 votes

   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

   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

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

   •  

   •  

   •  

   •  

   •  

   •  

   26 votes

   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

   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

9. Make Third Party API Transactions More Apparent in Sierra

   Some time ago, an idea was submitted to enhance the Sierra API to provide statistical group information, so that circulation transactions in third party applications could be credited to a statistical group other than 0 None.

   The idea won the "Let's Connect Sierra API Challenge."

   With the release of Sierra 6.0, it then became possible to include a new optional data parameter to specify the statistical group that should be used when recording a transaction performed using the APIs.

   My library was excited to hear this, as we'd recently begun using the self-checkout feature in the Bibliocommons' app not long before this & found it frustrating that credit for the transactions wasn't being assigned to a dedicated statistical group & just lumped into the default of 0 None. That Bibliocommons requires separate statistical groups for checkouts & renewals made it all the more frustrating.

   After some back & forth involving both Bibliocommons & III support & developers, we began seeing these transactions assigned the desired statistical group in Web Management Reports (see stat groups 908 & 909 in image bibstat1). This is enough to help those keeping track of metrics.

   However, this does not address the need of frontline staff who may need to see where an item was checked out. Normally, they'd do this in the SDA, by looking at the Checkout Location field in the item record.

   Unfortunately, this still displays the 0 None value (see image bibstat2).

   Apparently, this is because Bibliocommons does not currently support the username field in the API coding for their checkouts, which Sierra currently requires. In order for our library to take full advantage of our chosen app from its use to the resultant metrics, we're hoping that the stat group functionality could work without necessarily specifying the username.

   Some time ago, an idea was submitted to enhance the Sierra API to provide statistical group information, so that circulation transactions in third party applications could be credited to a statistical group other than 0 None.

   The idea won the "Let's Connect Sierra API Challenge."

   With the release of Sierra 6.0, it then became possible to include a new optional data parameter to specify the statistical group that should be used when recording a transaction performed using the APIs.

   My library was excited to hear this, as we'd recently begun using the self-checkout feature in the Bibliocommons' app not long… more

   •  

   •  

   6 votes

   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

   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

10. Create an API endpoint that delivers language translations to Vega

    We maintain English and Te Reo Māori names for library branches and item locations in the Sierra branches table. Making these available through an API would allow Vega to display the correct names automatically, and provide a consistent bilingual experience. This would also remove the need to manage translations separately in Vega Admin.

    •  

    •  

    5 votes

    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

    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

11. include PostgreSQL scheduled patches and upgrades in roadmap and upgrade documents

    Sierra 6.6 includes an upgrade to PostgreSQL 16. Innovative should be more specific and tell us that we are upgrading to PostgreSQL 16.10. PostGres 16.14 was the last version in this cycle.

    Does Innovative upgrade PostgreSQL with each Sierra upgrade? Will they patch between upgrades with any security fixes?

    Libraries need to know Innovative's plans PostgreSQL development, and I am unsure if they are always included in the upgrade notes.

    5 votes

    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

    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

12. Add Days Closed Table to SierraDNA

    We are interested in being able to tap into the Days closed table programmatically but it is inaccessible to both the APIs and SQL, and doesn't even have a native export feature (though you can copy and paste it easily enough).

    Creating a SQL View for it seems the most straightforward solution, just provide access to the existing table, along with row numbers to preserve the ordering.

    12 votes

    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

    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

13. 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.

    11 votes

    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

    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

14. Access to SAML logs

    When using the LDAP authentication option, it was useful to be able to see the authentication logs to diagnose login issues. After switching to SAML authentication, access to the SAML logs is only available to Innovative support.

    I propose granting customers access to the CAS Apereo application logs so that we can see SAML authentication issues. These logs may not be as detailed as the LDAP ones since the authentication is happening at the IdP but they might provide clues to further investigate authentication issues.

    2 votes

    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

    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

15. 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

    26 votes

    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

    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

16. 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

    13 votes

    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

    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

17. 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

    28 votes

    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

    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
    PLANNED  ·  AdminMike Dicus (Product Manager, Innovative) responded

    Selected for the Sierra 6.7 release by MEEP enhancement process

18. Translate item status and OPAC message codes in Summary View

    Currently, it's possible to have item status and OPAC message codes displayed in the summary view. However, we'd like the option to display the full names of these statuses/messages rather than the codes to make things clearer for staff who don't have them memorized.

    •  

    6 votes

    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

    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

19. 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

    27 votes

    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

    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.

20. 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

    26 votes

    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

    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.