Settings and activity
18 results found
-
10 votes
Victor Zuniga
supported this idea
·
-
29 votesVictor Zuniga
supported this idea
·
An error occurred while saving the comment Victor Zuniga
shared this idea
·
-
7 votesVictor Zuniga
supported this idea
·
-
25 votes
This enhancement is planned for Sierra 6.6.
Victor Zuniga
supported this idea
·
-
22 votes
The product team will review this idea for consideration for a future release.
Victor Zuniga
supported this idea
·
-
36 votesVictor Zuniga
supported this idea
·
-
5 votesVictor Zuniga
supported this idea
·
-
26 votes
The product team will review this idea for consideration for a future release.
Victor Zuniga
supported this idea
·
An error occurred while saving the comment Victor Zuniga
commented
Thanks for the clarification, Jeremy. Yes, we want to maintain the existing stat group parameter. If a vendor does not implement the provided stat group code, this will serve as a backup plan to keep track of their usage on the system via the Patron API. Thanks!
Victor Zuniga
shared this idea
·
-
21 votes
The product team will review this idea for consideration for a future release.
An error occurred while saving the comment Victor Zuniga
commented
I think this would address the issue of permissions to generate reports for internal or external use (vendors). As Jeremy mentioned, there is no viable way to provide access to the circulation transactions without exposing the entire database. This proposal finds a compromise for this particular scenario.
Victor Zuniga
supported this idea
·
-
35 votes
An error occurred while saving the comment Victor Zuniga
commented
Yes, this will be a great addition. I know that in recent upgrades to the Patron REST API, there is the ability to assign a value for the stat group. You still rely on the vendor to make this change.
It would be great for library staff members to control this feature via the user interface.
Victor Zuniga
supported this idea
·
-
5 votesVictor Zuniga
supported this idea
·
-
6 votes
An error occurred while saving the comment Victor Zuniga
commented
Also, can we provide an option to export the reading history as a .csv file?
An error occurred while saving the comment Victor Zuniga
commented
We recently encountered this issue with a patron request to include the checkout date. In addition to the checkout date, including repeat checked-out items (aka duplicates) would be ideal. It is not unusual for some patrons to borrow the same item multiple times, especially if their reading history spans over 10+ years. Patrons would love to see each of these entries when exporting the data from the system. Currently, duplicate titles are exported only once. This misleads the patron into thinking they checked out fewer items than what the exported email would display.
Victor Zuniga
supported this idea
·
-
24 votes
This idea will be reviewed by the Innovative product team for consideration in planning the upcoming product roadmap.
Victor Zuniga
supported this idea
·
-
153 votesVictor Zuniga
supported this idea
·
-
30 votes
The product team will review this idea for consideration for a future release.
Victor Zuniga
supported this idea
·
-
9 votes
This idea will be reviewed by the product management team for possible inclusion in a future release.
Victor Zuniga
supported this idea
·
-
13 votes
This idea will be reviewed by the product management team for possible inclusion in a future release.
Victor Zuniga
supported this idea
·
-
77 votes
An error occurred while saving the comment Victor Zuniga
commented
Yes, please implement this functionality into LX Starter.
This should be an expected functionality out of the box.
Please migrate the existing code workflow from JasperStudio (Print Templates) into LX Starter.
Victor Zuniga
supported this idea
·
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.