11 results found

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

   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 (incl 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.

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

   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 (incl 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. Granular Permissions on Item Record

   We would like to see more specific permissions on items records to allow staff who don't have access to edit entire item records to be able to do basic things like add and delete item messages or change the status of the item.

   Frontline staff are discovering outdated item messages or finding that items are missing, and it's inefficient for them to have to contact someone else to change the status of the item, or delete an item message attached to it.

   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

   2 comments  ·  System Administration (incl 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. Allow sorting options for API Results

   An example of this is the Items/GET API appears to sort the results based on catalog date/item id of the item. It would be nice to specify a different sort parameter that would allow the current sort or a new sort which would return them in the same sorting specified in the Cataloging function in Sierra.

   This might be nice for other APIs as well.

   5 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 (incl 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. Make API loader allow bad MARC

   One of the major advantages of Sierra is it's flexibility. Particularly the Sierra fixed fields. Sierra allows those fixed fields to be used in non-standard ways, but the API loader does not have that flexibility. If you try to load records with unexpected data with the API, the load will fail. The API MARC loader does not have to validate MARC. Sierra has never really validated MARC. Don't start now. The API should allow the same weird non-standard data as the rest of Sierra.

   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

   1 comment  ·  System Administration (incl 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. Manage Reading History through RESTAPI

   Currently patrons can opt in and out of Reading History our public catalog (Bibliocore) but we get many requests from patrons who want to manage that reading history by removing items from Reading History but the RESTAPI doesn't allow users to do that, they have to log into their accounts on WebPac in order to manage the titles in that history. We would like to see full Reading History management currently available in WebPac added to the RESTAPI.

   8 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 (incl 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. Edit Username in Admin App

   Once a user is created in the admin app, you are not able to update the username. You may update the password, permissions, etc., but not the username itself.

   All of our clerk-level positions are part-time, so there is a lot of turnover. Each time an employee leaves, his/her account must be deleted and a new one created for the replacement. When the new account is created, you then must import all of the permissions, options, locations served, etc., of a comparable employee for the same location.

   Ideally, we would simply be able to edit the username and password and provide that to the replacement employee, who will have the exact same permissions, workflow, settings, etc.

   Idea Value
   Allowing system administrators to edit the Sierra username would cut down on unnecessary work, saving time, staff aggravation.

   Once a user is created in the admin app, you are not able to update the username. You may update the password, permissions, etc., but not the username itself.

   All of our clerk-level positions are part-time, so there is a lot of turnover. Each time an employee leaves, his/her account must be deleted and a new one created for the replacement. When the new account is created, you then must import all of the permissions, options, locations served, etc., of a comparable employee for the same location.

   Ideally, we would simply be able to edit the username and password and… more

   65 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

   8 comments  ·  System Administration (incl 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. Delete Item Records - Ensure Permissions Apply to Deleting Checkin Cards

   Staff members not authorized to delete item records are currently allowed to do so when deleting checkin records. This should not be the case.

   If a person who does not have permission to create item records attempts to create an item record as part of the checkin process for a serial, they will be prompted for override credentials in order to do so. This should be the case (especially!) with deleting item records as well. That is, when someone without delete items permissions attempts to delete a checkin card along with its attached items, it should prompt for override credentials there as well.

   If you have a large number of locations and delete a checkin card that happens to have attached issues for all of your locations, the implications are pretty severe.

   Idea Value
   • Prevent staff from unintentionally deleting item records (could be many attached items for a checkin card, depending on the number of branches/locations)
   • Ensure consistent behavior when it comes to permissions

   Staff members not authorized to delete item records are currently allowed to do so when deleting checkin records. This should not be the case.

   If a person who does not have permission to create item records attempts to create an item record as part of the checkin process for a serial, they will be prompted for override credentials in order to do so. This should be the case (especially!) with deleting item records as well. That is, when someone without delete items permissions attempts to delete a checkin card along with its attached items, it should prompt for override credentials… 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

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

   This has been reported as a bug in Sierra and will be resolved outside of the enhancement process.

9. Make Review Files in Admin App Consistent w/SDA & Sierra Web

   In Sierra - SDA and Web - you can sort review files in Create Lists by the column header, i.e., file #, current records, max records, type, status, login and created.

   In the Admin App (BACK END MANAGEMENT > Review Files), the only columns displaying are file # (which doesn't appear to match the file # in the SDA/Sierra Web), number of records (= max records), current and name. Sorting by column is not an option.

   The display, labeling and function for managing review files should be consistent.

   Idea Value
   When managing review files in the admin app, particularly when creating new review files, it's helpful to see, at a glance, how many files you have by increment/max records. For example, if I know I need 2 review files to be >100K records, I like to see how many are available in the various increments and delete unnecessary review files as needed in order to create 2 larger files.

   Currently, I have to sort by # in the SDA, while making changes in the admin app, save and then log out of the SDA, log back in and sort to see what is going to work. A big time waster.

   In Sierra - SDA and Web - you can sort review files in Create Lists by the column header, i.e., file #, current records, max records, type, status, login and created.

   In the Admin App (BACK END MANAGEMENT > Review Files), the only columns displaying are file # (which doesn't appear to match the file # in the SDA/Sierra Web), number of records (= max records), current and name. Sorting by column is not an option.

   The display, labeling and function for managing review files should be consistent.

   Idea Value
   When managing review files in the admin app, particularly when… 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

   1 comment  ·  System Administration (incl 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.

   
   

10. Increase Character Limits for Data Fields

    The Notice Type data field in the Text of Circulation Notices table is a mere 20 characters long. As we've had to create a number of new notices for temporary changes in operating hours, policies, etc., due to COVID, we'd like to make the description a bit more descriptive than 20 characters allows.

    Also, because you cannot delete any of the old/test notice types, you already have to use up some of the characters to note that it's old/test/not used.

    This runs along the same lines as Loan rules: increase the limit beyond 20 characters to loan rule names. This would cut down on confusion and staff time spent when reviewing the table. For example, when you look to see what the text of notices sent would be for specific loan rules, because the descriptions are so brief, you often have to click into the notice text and read it to confirm that it's the one that should be used.

    We waste a lot of time trying to describe key features/functions with these arbitrary limits.

    The Notice Type data field in the Text of Circulation Notices table is a mere 20 characters long. As we've had to create a number of new notices for temporary changes in operating hours, policies, etc., due to COVID, we'd like to make the description a bit more descriptive than 20 characters allows.

    Also, because you cannot delete any of the old/test notice types, you already have to use up some of the characters to note that it's old/test/not used.

    This runs along the same lines as Loan rules: increase the limit beyond 20 characters to loan rule names. This… more

    8 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 (incl 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.

    
    

11. Make Sierra User Profile Imports Additive, at least Optionally

    In the Sierra web-based admin utility, in Authorizations and Authentication Admin, when importing permissions from one Sierra user to another, the "donor" settings overwrite those of the recipient user. I propose adding a checkbox to allow these to be imported in an additive manner.

    Idea Value
    Recently two of my coworkers in Technical Services and Collection Development received promotions and shifted into different roles. When using the feature to assign the permissions of users similar to the new roles, old but still valid permissions were lost due to the way the feature overwrites the recipient permissions with those of the donor user.

    If we had a checkbox to alter this behavior, the recipient could retain all their old permissions while gaining the donor permissions. As the graphic suggests, the result would be an ORing of the two sets of permissions.

    This behavior should likewise extend to Applications, Workflows, Settings, Options and Preferences to the extent possible. Applications and Permissions are straightforward enough. Workflows involve an ordered display and for all I know conflicts may arise in Settings, Options and/or Preferences when combining two users in this way. My request of Mike and the product team is to implement that portion of this request which is readily doable and to not let the potential conflicts kill the whole idea.

    After voting (thanks in advance), please see my other opt-in Idea Lab entry.

    In the Sierra web-based admin utility, in Authorizations and Authentication Admin, when importing permissions from one Sierra user to another, the "donor" settings overwrite those of the recipient user. I propose adding a checkbox to allow these to be imported in an additive manner.

    Idea Value
    Recently two of my coworkers in Technical Services and Collection Development received promotions and shifted into different roles. When using the feature to assign the permissions of users similar to the new roles, old but still valid permissions were lost due to the way the feature overwrites the recipient permissions with those of the… more

    37 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 (incl 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.