29 results found

1. Make the hold status information updatable in API

   There is currently no way to update the status of a hold in the API.

   It would be very useful to change the status from

   "status": {
   "code": "0",
   "name": "on hold."
   },

   to

   "status": {
   "code": "i",
   "name": "Requested item ready for pickup."
   },

   Enhancement to be integrated into https://ideas.iii.com/forums/951745-ils-sierra/suggestions/47618129-it-s-about-time-to-make-holds-apis-first-class-cit ?

   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

   0 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
   CLOSED  ·  AdminMike Dicus (Product Manager, Innovative) responded

   In accordance with the Idea Graduation Workflow guidelines agreed upon by Innovative and IUG, this idea has been closed because it was submitted more than two years ago and has not been selected for inclusion in the product.

   
   

   This idea is still available for commenting but is no longer eligible for voting.

   
   

   Ideas that were submitted three or more years ago are archived for future reference.

   
   

2. It's about time to make Holds APIs first-class citizens

   Idea Description
   
   It would be far nicer to have the ability to work with hold data directly--in contrast to having to retrieve hold data via the patron APIs. For example: currently, in order to (reasonably) find the "pickupByDate" values for holds with status "(Bib, Volume, Item) hold ready for pickup" you would have to use a combination of the Sierra SQL feature (to first find all the patron record numbers possessing such a hold) and then filter all the holds for the list of patrons (from the previous step) having the "pickupByDate" key in the response object. Once you have the holds, you still have to then make another set of API calls to retrieve the rest of the hold info (the endpoint returns the hold URL), or combine it back with your SQL data.

   Idea Value
   
   It would be far more simple and effective to be able to work with holds if they were granted more of a "first-class citizen" status as a suite of API endpoints. It would be amazing to have more direct CRUD access to holds in general!

   Idea Description
   
   It would be far nicer to have the ability to work with hold data directly--in contrast to having to retrieve hold data via the patron APIs. For example: currently, in order to (reasonably) find the "pickupByDate" values for holds with status "(Bib, Volume, Item) hold ready for pickup" you would have to use a combination of the Sierra SQL feature (to first find all the patron record numbers possessing such a hold) and then filter all the holds for the list of patrons (from the previous step) having the "pickupByDate" key in the response object. Once you have the holds,… 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

   3 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
   CLOSED  ·  AdminMike Dicus (Product Manager, Innovative) responded

   In accordance with the Idea Graduation Workflow guidelines agreed upon by Innovative and IUG, this idea has been closed because it was submitted more than two years ago and has not been selected for inclusion in the product.

   
   

   This idea is still available for commenting but is no longer eligible for voting.

   
   

   Ideas that were submitted three or more years ago are archived for future reference.

   
   

3. Connect Global Update with Scheduler

   We complete many repetitive tasks in cataloging and patron record management each day. This entails using Create Lists to generate the list, and then using Global Update to perform the same set of edits each time. We need Scheduler to be able to connect into Global Update to perform those tasks automatically.

   This may require enhancement of Global Update to save the Command Input, or it might mean adding the Command Input choices to Scheduler.

   Example:
   Scheduler runs an updated Create List using a saved search query to identify items that need their suppression code updated.
   It then uses a saved input command to update all of the items in that list to the suppression code.

   Another Scheduler task kicks off another saved search query to find items that need suppression code removed.
   It then uses a saved input command to update all of the items in that list to remove the suppression code.

   Of course there is some risk with this, but system administrators can do a lot of damage when manually completing these tasks. I would have more faith in a well-thought out process set up once and then automated than a coffee-deprived sys admin on a Monday following a holiday (me).

   I have administered other systems that had the ability to chain automation processes together to complete complex tasks such as what I'm describing.

   We complete many repetitive tasks in cataloging and patron record management each day. This entails using Create Lists to generate the list, and then using Global Update to perform the same set of edits each time. We need Scheduler to be able to connect into Global Update to perform those tasks automatically.

   This may require enhancement of Global Update to save the Command Input, or it might mean adding the Command Input choices to Scheduler.

   Example:
   Scheduler runs an updated Create List using a saved search query to identify items that need their suppression code updated.
   It then uses 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

   5 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
   CLOSED  ·  AdminMike Dicus (Product Manager, Innovative) responded

   In accordance with the Idea Graduation Workflow guidelines agreed upon by Innovative and IUG, this idea has been closed because it was submitted more than two years ago and has not been selected for inclusion in the product.

   
   

   This idea is still available for commenting but is no longer eligible for voting.

   
   

   Ideas that were submitted three or more years ago are archived for future reference.

   
   

4. Dark contrast display option for the SDA

   We see the Sierra 6.0 Release Notes features new Accessibility improvements in the SDA. It is unclear if this includes a high contrast display option which staff recommend to support use of the software by many different types of staff.

   14 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

   0 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
   CLOSED  ·  AdminMike Dicus (Product Manager, Innovative) responded

   In accordance with the Idea Graduation Workflow guidelines agreed upon by Innovative and IUG, this idea has been closed because it was submitted more than two years ago and has not been selected for inclusion in the product.

   
   

   This idea is still available for commenting but is no longer eligible for voting.

   
   

   Ideas that were submitted three or more years ago are archived for future reference.

   
   

5. Expand Locations field for bibs, holdings, and orders API responses

   Currently, the bibs, holdings, and orders APIs do not return the expanded Locations fields for records with multi locations. The multi location value that is returned is useless without the expanded values.

   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

   0 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
   CLOSED  ·  AdminMike Dicus (Product Manager, Innovative) responded

   In accordance with the Idea Graduation Workflow guidelines agreed upon by Innovative and IUG, this idea has been closed because it was submitted more than two years ago and has not been selected for inclusion in the product.

   
   

   This idea is still available for commenting but is no longer eligible for voting.

   
   

   Ideas that were submitted three or more years ago are archived for future reference.

   
   

6. Allow the "remember me" in Sierra Desktop App login screen to remember passwords as well as username (as previous versions of Sierra did)

   Previous versions of Sierra (version 5 and below) allowed the saving of usernames and passwords in the Sierra desktop app login screen. Since upgrading to 6 this functionally has been lost.

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

   In accordance with the Idea Graduation Workflow guidelines agreed upon by Innovative and IUG, this idea has been closed because it was submitted more than two years ago and has not been selected for inclusion in the product.

   
   

   This idea is still available for commenting but is no longer eligible for voting.

   
   

   Ideas that were submitted three or more years ago are archived for future reference.

   
   

7. assign 1st and 2nd tier timeout permissions (for those using context logins) : SDA and Sierra Web

   In the SDA OR Sierra Web, the Sierra 2-tier login workflow allows administrators to set a "time-out" setting to the 2nd tier (personalized) login. This setting determines if the session will time out or close after a specific amount of time.

   This is an excellent workflow except that there is no setting to manage 1st tier inactivity. This means at the end of the day we have many Sierra licenses that remain open and the Library must manually force close the desktop applications using the "restart a process" in Admin Corner.

   Please configure context logins so that Libraries can determine a time period to "quit" the application. This is especially important for libraries considering Sierra Web as the license is not released if the session does not close cleanly.

   Thank you,
   Elizabeth

   In the SDA OR Sierra Web, the Sierra 2-tier login workflow allows administrators to set a "time-out" setting to the 2nd tier (personalized) login. This setting determines if the session will time out or close after a specific amount of time.

   This is an excellent workflow except that there is no setting to manage 1st tier inactivity. This means at the end of the day we have many Sierra licenses that remain open and the Library must manually force close the desktop applications using the "restart a process" in Admin Corner.

   Please configure context logins so that Libraries can determine… 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

   1 comment  ·  System Administration & APIs  ·  Delete…  ·  Admin →
   CLOSED  ·  AdminMike Dicus (Product Manager, Innovative) responded

   In accordance with the Idea Graduation Workflow guidelines agreed upon by Innovative and IUG, this idea has been closed because it was submitted more than two years ago and has not been selected for inclusion in the product.

   
   

   This idea is still available for commenting but is no longer eligible for voting.

   
   

   Ideas that were submitted three or more years ago are archived for future reference.

   
   

8. Superuser account with access to all accounting units from one log in?

   Could we have an enhancement option to create a Sierra user administrator account that has access to all accounting units? I am the only system administrator and cataloger for a library system with multiple accounting units and I would very much appreciate the ability to do everything I need to from one log-in (managing/creating new check-in records, for example).

   10 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

   1 comment  ·  System Administration & APIs  ·  Delete…  ·  Admin →
   CLOSED  ·  AdminMike Dicus (Product Manager, Innovative) responded

   This idea is no longer under consideration because implementing it would require significant changes to accounting units in Sierra.

9. REST API security enhancement request: Assign granularity to API role permissions

   Objective: Allow Libraries to assign granularity to API role permissions.

   When Libraries give a 3rd party vendor read access, we want to be able to restrict the endpoints associated with the role. In addition, we want to restrict the fields that can be returned. Ideally, the implementation of the requested features below will provide an interface to the Innovative clients where the vendor access will be managed.

   There are endpoint and field restriction examples below to show how assigning granularity to API role permissions would allow libraries to improve access management.

   Endpoint restriction example:
   We would like to be able to restrict the endpoints available to the vendor to a subset of options below.

   The patron read role includes the following endpoints:

   GET /v6/patrons - Get a list of patrons.

   GET /v6/patrons/checkouts/{checkoutId} - Get a checkout by checkout ID.

   GET /v6/patrons/find - Find a patron by varField fieldTag and varField content.

   GET /v6/patrons/fines/{fineId} - Get a fine record by fine ID.

   GET /v6/patrons/holds/{holdId} - Get a hold record by hold ID.

   GET /v6/patrons/metadata - Get a list of metadata.

   POST /v6/patrons/query - Filter the records by a query in JSON format.

   GET /v6/patrons/validate/authmethods - Available methods for authentication.

   GET /v6/patrons/{id} - Get a patron by record ID.

   GET /v6/patrons/{id}/checkouts - Get checkout data for a single patron record.

   GET /v6/patrons/{id}/checkouts/history - Get checkout/read history for a single patron record.

   GET /v6/patrons/{id}/checkouts/history/activationStatus - Get the patron's reading history status.

   GET /v6/patrons/{id}/fines - Get the fines data for a single patron record.

   GET /v6/patrons/{id}/holds - Get the holds data for a single patron record.

   GET /v6/patrons/{id}/holds/request/form - Get the hold request form for a bib record.

   Field restriction examples:

   Say we have allowed the use of the following endpoint:

   GET /v6/patrons/{id} - Get a patron by record ID.

   We would like to have the ability to restrict the patron record fields that are returned. Different vendors require access to patron data for various reasons and below are three scenarios that we hope will illustrate the utility of this requested feature:

   Vendor A only needs to validate the PIN of a patron so that they allow use of a public access computer. In this case, we only need to provide patron validation access.

   Vendor B needs to validate the PIN of a patron for the use of a public access computer, but they also need to ensure that the patron is not blocked. In this case, we need to provide patron validation access as well as read access to the blockInfo field.

   Vendor C needs to validate the PIN of a patron as well as provide metrics on the age group. In this case, we need to provide validation access as well as access to the birthDate field.

   Objective: Allow Libraries to assign granularity to API role permissions.

   When Libraries give a 3rd party vendor read access, we want to be able to restrict the endpoints associated with the role. In addition, we want to restrict the fields that can be returned. Ideally, the implementation of the requested features below will provide an interface to the Innovative clients where the vendor access will be managed.

   There are endpoint and field restriction examples below to show how assigning granularity to API role permissions would allow libraries to improve access management.

   Endpoint restriction example:
   We would like to be able… more

   •  

   8 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

   0 comments  ·  System Administration & APIs  ·  Delete…  ·  Admin →
   CLOSED  ·  AdminMike Dicus (Product Manager, Innovative) responded

   In accordance with the Idea Graduation Workflow guidelines agreed upon by Innovative and IUG, this idea has been closed because it was submitted more than two years ago and has not been selected for inclusion in the product.

   This idea is still available for commenting but is no longer eligible for voting.

   Ideas that were submitted three or more years ago are archived for future reference.