108 results found

1. API versioning (especially user API)

   API updates should be rolled out with an opt-in and out option. So that developers can test and adopt new versions and roll back if problems occur. Currently we just get a new version and if this new version breaks any of our custom integrations. We have no way to compare to old behaviour or opt out of the update until we can fix this.
   Example of this is the November API changes. The change broke how some of our APIs customizations worked. Our ICT developer team had to make changes to resolve the problems that the November API change made. Then 2 months later Ex libris changed the API to resolve the bug that November had made. This update broke the workarounds that our developers have created. So our ICT developers have then had to work on a second resolution within a very short space of time. This is specifically problematic for our ICT developers as the issue is system critical and therefore needs to be done quickly. Whereas versioning API changes would resolve this.

   API updates should be rolled out with an opt-in and out option. So that developers can test and adopt new versions and roll back if problems occur. Currently we just get a new version and if this new version breaks any of our custom integrations. We have no way to compare to old behaviour or opt out of the update until we can fix this.
   Example of this is the November API changes. The change broke how some of our APIs customizations worked. Our ICT developer team had to make changes to resolve the problems that the November API change… more

   1 vote

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  APIs and Integrations  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all 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

2. Statistics for Cloud Apps

   We would like to be able to see some statistics within our IZ regarding Cloud Apps:

   • Which user has activated which Cloud App
   • How often is a Cloud App used
   • When did a user use a specific Cloud App
   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

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  APIs and Integrations  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all 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

3. Warn before regenerating the SFTP Service private key

   There is a «Regenerate private key» button under Alma configuration » General » S/FTP definitions.

   This button is too efficient. This idea is to make the button a little less efficient, but in doing so make it safer.

   Clicking the «Regenerate private key» button immediately regenerates the private key for the Ex Libris Secure FTP Service. In the process it invalidates any previously generated private key and breaks all integrations with the SFTP Service. More so, the button in Alma (Premium) Sandbox does the same as in Alma Production, including breaking all production integrations.

   All it can take is one slip of a mouse click on this Alma page.

   Library staff and Ex Libris support staff both have fallen into the trap of regenerating the private key on sandbox without knowing that doing so breaks production.

   The idea is to:
   1. Show a warning dialog after clicking the regenerate private key that emphasises that continuing will: a) stop any previously generated private key from working; and b) affects both Alma Production and Alma Sandbox.
   2. Show a second «Regenerate private key» button, along with a «Cancel» button.

   It is important that regenerating the private key becomes a deliberate two-step process to avoid accidently regenerating the private key.

   There is a «Regenerate private key» button under Alma configuration » General » S/FTP definitions.

   This button is too efficient. This idea is to make the button a little less efficient, but in doing so make it safer.

   Clicking the «Regenerate private key» button immediately regenerates the private key for the Ex Libris Secure FTP Service. In the process it invalidates any previously generated private key and breaks all integrations with the SFTP Service. More so, the button in Alma (Premium) Sandbox does the same as in Alma Production, including breaking all production integrations.

   All it can take is one… more

   •  

   35 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  APIs and Integrations  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all 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

4. Ability to change an institutions public key for S/FTP setup

   Our institution is requiring us to change the public key we use in Alma every 90 days in the S/FTP integration connections we have set up, to adhere with our Universities tightening of cyber security measures. We would like the ability to change our institutions public key 4 times a year. Currently institutions are only assigned a static key that can not be changed.

   3 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  APIs and Integrations  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all 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

5. User API order response of identifiers

   When a response is received from the users API the identifiers aren't ordered.

   For example our library gates system requests a GET on the user API to retrieve an identifier, in our case <id_type desc="Additional ID 1">OTHERID1</id_type>. it can only read the first hit for this identifier

   I would like the response to order the values by status, with Active coming first.

   This would allow us to read the active value and ignore any subsequent Inactive values

   This is an example what is currently returned
   <user_identifiers>
   <user_identifier segment_type="Internal">
   <id_type desc="Additional ID 1">OTHERID1</id_type>
   <value>1234567890</value>
   <status>INACTIVE</status>
   </user_identifier>
   <user_identifier segment_type="External">
   <id_type desc="Barcode">BARCODE</id_type>
   <value>removed</value>
   <status>ACTIVE</status>
   </user_identifier>
   <user_identifier segment_type="External">
   <id_type desc="University ID">UNIVID</idtype>
   <value>removed</value>
   <status>ACTIVE</status>
   </user_identifier>
   <user_identifier segment_type="External">
   <id_type desc="Additional ID 1">OTHERID1</id_type>
   <value>0987654321</value>
   <status>ACTIVE</status>
   </user_identifier>
   </user_identifiers>

   This is how I would prefer it to be returned
   <user_identifiers>
   <user_identifier segment_type="Internal">
   <id_type desc="Additional ID 1">OTHERID1</id_type>
   <value>0987654321</value>
   <status>ACTIVE</status>
   </user_identifier>
   <user_identifier segment_type="External">
   <id_type desc="Barcode">BARCODE</id_type>
   <value>removed</value>
   <status>ACTIVE</status>
   </user_identifier>
   <user_identifier segment_type="External">
   <id_type desc="University ID">UNIVID</idtype>
   <value>removed</value>
   <status>ACTIVE</status>
   </user_identifier>
   <user_identifier segment_type="External">
   <id_type desc="Additional ID 1">OTHERID1</id_type>
   <value>1234567890</value>
   <status>INACTIVE</status>
   </user_identifier>
   </user_identifiers>

   When a response is received from the users API the identifiers aren't ordered.

   For example our library gates system requests a GET on the user API to retrieve an identifier, in our case <id_type desc="Additional ID 1">OTHERID1</id_type>. it can only read the first hit for this identifier

   I would like the response to order the values by status, with Active coming first.

   This would allow us to read the active value and ignore any subsequent Inactive values

   This is an example what is currently returned
   <user_identifiers>
   <user_identifier segment_type="Internal">
   <id_type desc="Additional ID 1">OTHERID1</id_type>
   <value>1234567890</value>
   <status>INACTIVE</status>
   </user_identifier>
   <user_identifier… more

   3 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  APIs and Integrations  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all 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

6. API to get and upload Overdue and Lost Loan Profiles

   It would be great to have an API to get a list of all Overdue and Lost Loan Profiles as well as being able to get and upload individual profiles.

   We have 300 libraries, each of which has 3 or more Overdue and Lost Loan Profiles. Being able to manipulate the profiles with an API would be of great help in keeping track of all these profiles.

   1 vote

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  APIs and Integrations  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all 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

7. Air bar box

   I am a General Manager of Store Operations and responsible for day to day store operations, including scheduling, training, and supervising employees and assistant manager. Before that, [url=https://cgdistro.com/product/air-bar-box-disposable/]Air bar box[/url] I worked as a casual Customer Service Representative, In - store consultant, and ROC Coordinator.Clear eyes, Eagle torch lighters, Duracell batteries, haze xl disposable vape, recharging puff bar, top shine disposable, supreme hyppe max flow and wax pen batteries are among the items for sale. Managing shop profitability as well as all controllable expenses such as labor, inventory levels,

   1 vote

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  APIs and Integrations  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all 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

8. Support full SIP2 protocol

   For the communication between selfcheck kiosks and Alma, the SIP2 protocol is needed.
   The full protocol can be found here: https://developers.exlibrisgroup.com/wp-content/uploads/2020/01/3M-Standard-Interchange-Protocol-Version-2.00.pdf

   Unfortunately, Ex Libris does not support all fields that would be available in the protocol (marked as 'not supported' in this document): https://developers.exlibrisgroup.com/alma/integrations/selfcheck/sip2/

   Please make the whole SIP2 protocol available for Alma.

   94 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   2 comments  ·  APIs and Integrations  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all 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

9. Enable additional types of requests via API

   The API documentation for the Create User Requests endpoint notes that "is currently NOT possible to create GENERALDIGITIZATION, MOVE or WORKORDER request." Enabling this functionality would facilitate batch processing of items for various workflows.

   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

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  APIs and Integrations  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all 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

10. Webhook for Library Hour Changes

    It would be great if a event could be created that would fire a webhook when a librarys hours change.

    The use case for this is when we use a 3rd party system that pulls hours out of Alma, we want to be able to know the hours have changed and perform a sync sooner than say 72 hours later (or whatever interval) when the outside system refreshes automatically.

    This would be useful when we close do to inclement weather or something, so we could trigger updating our 3rd party system after the hours are updated in Alma.

    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

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  APIs and Integrations  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all 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

11. SIP2 Kiosks should bundle loan/return notifications to a single notification

    Currently SIP2 connected self service hardware triggers a receipt notification for every single item that is loaned or returned. Would it be possible to package these notifications in to one email after the transaction is finished based on the configuration that it has been conducted on a self service circulation desk?

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  APIs and Integrations  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all 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

12. Bursar integration: Additional fee statuses in Alma & Allow fee status change with job Import from Bursar

    Currently there exist in Alma only the fee statuses “open”, “transferred” and “closed”. Transferred means fee was exported to external Bursar system. When the fee is imported back to Alma, it is automatically Closed. For staff it is not possible to tell if the closed fee was paid, waived, unpaid etc. without consulting the 3rd party Bursar system.
    To give the librarians and end users more transparency about the (invoice) status of a fee, we would need more differentiated fee statuses. Also, we need to be able to set this status when importing the fees back to Alma using the job Import from Bursar.
    The optimal development would be:
    1. Have the possibility to configure ourselves in Alma which fee statuses we want to use and to have the possibility to add additional fee statuses.
    2. The Import from Bursar job must be able to set this status based on a field in the import XML file.
    If the #1 is not possible, it would be good to have the following additional fee statuses implemented:
    invoiced
    unpaid
    partial payment
    paid/closed
    storno
    write-off
    transferred to the debt collection
    e-mail not deliverable

    Currently there exist in Alma only the fee statuses “open”, “transferred” and “closed”. Transferred means fee was exported to external Bursar system. When the fee is imported back to Alma, it is automatically Closed. For staff it is not possible to tell if the closed fee was paid, waived, unpaid etc. without consulting the 3rd party Bursar system.
    To give the librarians and end users more transparency about the (invoice) status of a fee, we would need more differentiated fee statuses. Also, we need to be able to set this status when importing the fees back to Alma using the… more

    373 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    15 comments  ·  APIs and Integrations  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all 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

13. Alma “scan-in” API: Marc21 field 852 - call number prefix and suffix

    We are using the Alma “scan-in” API
    /almaws/v1/items?itembarcode={itembarcode}
    which redirects to
    /almaws/v1/bibs/{mmsid}/holdings/{holdingid}/items/{item_pid}
    to print book labels.

    Some sublibraries also use call number prefixes or suffixes in some cases.
    
    Please see the following example record:
    - Marc21 field 852 in the Holding record
    - XML output

    (1) Example: Call number with prefix 852 $$k
    852 8_ |b XHOG |c XGRY |h G-1234567 |k Präfix

    XML output:
    item/holdingdata/permanentcallnumber: Präfix G-1234567
    item/holdingdata/callnumber: Präfix G-1234567
    item/holdingdata/accession_number: G-1234567

    item/itemdata/parsedcallnumber:
    <parsedcallnumber>
    <callno/>
    <call_no>Präfix</call_no>
    <call_no>G-1234567</call_no>
    </parsed_call_number>

    (2) Example: Call number with suffix 852 $$m
    852 8_ |b XHOG |c XGRY |h G-1234567 |m Suffix

    XML output:
    item/holdingdata/permanentcallnumber: G-1234567 Suffix
    item/holdingdata/callnumber: G-1234567 Suffix
    item/holdingdata/accession_number: G-1234567

    item/itemdata/parsedcallnumber:
    <parsedcallnumber>
    <callno>G-1234567</call_no>
    <call_no/>
    <call_no>Suffix</call_no>
    </parsed_call_number>

    (3) Example: Call number with prefix 852 $$k and suffix 852 $$m
    852 8_ |b XHOG |c XGRY |h G-1234567 |k Präfix |m Suffix

    XML output:
    item/holdingdata/permanentcallnumber: Präfix G-1234567 Suffix
    item/holdingdata/callnumber: Präfix G-1234567 Suffix
    item/holdingdata/accession_number: G-1234567

    item/itemdata/parsedcallnumber:
    <parsedcallnumber>
    <callno/>
    <call_no>Präfix</call_no>
    <call_no>G-1234567</call_no>
    <call_no/>
    <call_no>Suffix</call_no>
    </parsed_call_number>

    and after some tests the <parsed_call_number> section looks like this:

    <parsed_call_number>
    <call_no/>
    <call_no>Präfix</call_no>
    <call_no>G-1234567</call_no>
    <call_no/>
    <call_no>Suffix</call_no>
    </parsed_call_number>

    Conclusion:
    - Marc21 subfields 852 $$k and $$m are not listed sperately in the XML :-(
    - In <parsed_call_number> section the content of <permanent_call_number> or <call_number> is splitted up into the content of 852 $$k, $$h and $$m. The order of the <call_no> tags is correct (call number prefix / call number / call number suffix) but there are also empty <call_no/> tags.

    Please provide us a XML output with Marc21 852 content in seperate fields. The important call number fields for us are:
    - 852 $$k ... call number prefix
    - 852 $$h ... call number (classification part)
    - 852 $$m ... call number suffix
    - <accession_number> includes 852 $$h only if the call number has been generated via a call number (accession number) counter.

    Other libraries may be interested also in other subfields of Marc21 852:
    https://www.loc.gov/marc/holdings/concise/hd852.html
    $h - Classification part (NR)
    $i - Item part (R)
    $j - Shelving control number (NR)
    $k - Call number prefix (R)
    $l - Shelving form of title (NR)
    $m - Call number suffix (R)

    Having the content of 852 $$k, $$h and $$m in separate XML fields gives us the possiblity to handle the call number parts in a different way on the book label (if desired).
    Having two <call_no> tags in the <parsed_call_number> section is not clear enough. It could mean that you have:
    - 852 $$k ... call number prefix / 852 $$h ... call number (classification part)
    - or 852 $$h ... call number (classification part) / 852 $$m ... call number suffix

    Thank you in advance!

    We are using the Alma “scan-in” API
    /almaws/v1/items?itembarcode={itembarcode}
    which redirects to
    /almaws/v1/bibs/{mmsid}/holdings/{holdingid}/items/{item_pid}
    to print book labels.

    Some sublibraries also use call number prefixes or suffixes in some cases.
    
    Please see the following example record:
    - Marc21 field 852 in the Holding record
    - XML output

    (1) Example: Call number with prefix 852 $$k
    852 8_ |b XHOG |c XGRY |h G-1234567 |k Präfix

    XML output:
    item/holdingdata/permanentcallnumber: Präfix G-1234567
    item/holdingdata/callnumber: Präfix G-1234567
    item/holdingdata/accession_number: G-1234567

    item/itemdata/parsedcallnumber:
    <parsedcallnumber>
    <callno/>
    <call_no>Präfix</call_no>
    <call_no>G-1234567</call_no>
    </parsed_call_number>

    (2) Example: Call number with… more

    16 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  APIs and Integrations  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all 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

14. Add a request cancellation code & reason in the Request webhook

    The current Request webhook doesn't seem to include the Request Cancellation reason. Currently it just says:

    'event' => {
    'desc' => 'Request canceled',
    'value' => 'REQUEST_CANCELED'
    },

    The comment field refers to the request, but not the cancellation reason here:

    'userrequest' => {
    'requesttime' => '2022-05-11T23:42:26.191Z',
    'managedbycirculationdeskcode' => 'EASTCIRC',
    'mmsid' => '993815723607636',
    'taskname' => 'Rejected',
    'author' => 'Ferguson, J.',
    'itemid' => '2365452260007636',
    'issue' => '',
    'pickuplocationlibrary' => 'ABC',
    'dateofpublication' => '',
    'managedbylibrary' => 'State Library',
    'requesttype' => 'HOLD',
    'requestid' => '1419991190007636',
    'pickuplocation' => 'Redmond Barry Reading Room',
    'materialtype' => {
    'desc' => 'Book',
    'value' => 'BOOK'
    },
    'requestsubtype' => {
    'desc' => 'Patron physical item request',
    'value' => 'PATRONPHYSICAL'
    },
    'volume' => '',
    'managedbylibrarycode' => 'ABC',
    'part' => '',
    'barcode' => '30328504468884',
    'expirydate' => '2022-05-19Z',
    'description' => undef,
    'pickuplocationtype' => 'CIRCULATIONDESK',
    'comment' => undef,
    'userprimaryid' => '12345678',
    'pickuplocationcirculationdesk' => 'DEFAULTCIRCDESK',
    'managedbycirculationdesk' => 'East Retrieval',
    'requeststatus' => 'HISTORY',
    'title' => 'Life.',
    'requestdate' => '2022-05-12Z',
    'additional_id' => '141-999-119'
    }

    The current Request webhook doesn't seem to include the Request Cancellation reason. Currently it just says:

    'event' => {
    'desc' => 'Request canceled',
    'value' => 'REQUEST_CANCELED'
    },

    The comment field refers to the request, but not the cancellation reason here:

    'userrequest' => {
    'requesttime' => '2022-05-11T23:42:26.191Z',
    'managedbycirculationdeskcode' => 'EASTCIRC',
    'mmsid' => '993815723607636',
    'taskname' => 'Rejected',
    'author' => 'Ferguson, J.',
    'itemid' => '2365452260007636',
    'issue' => '',
    'pickuplocationlibrary' => 'ABC',
    'dateofpublication' => '',
    'managedbylibrary' => 'State Library',
    'requesttype' => 'HOLD',
    'requestid' => '1419991190007636',
    'pickup… more

    • 

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  APIs and Integrations  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all 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

15. Allow API update action of License in POLine record

    Currently, License field in POLine record cannot be updated via Acquisition API. There are no effective way to link up POLine record and License record without manual update one by one. The field were mentioned in the restpoline.xsd as

    "The license code. Relevant for electronic orders only, and is not supported for PUT. "

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  APIs and Integrations  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all 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

16. Allow API update action of License in POLine record

    Currently, License field in POLine record cannot be updated via Acquisition API. There are no effective way to link up POLine record and License record without manual update one by one. The field were mentioned in the restpoline.xsd as

    "The license code. Relevant for electronic orders only, and is not supported for PUT. "

    1 vote

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    1 comment  ·  APIs and Integrations  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all 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

17. Two-Factor Authentication (2FA) for developer portal

    Currently login to the developer portal https://developers.exlibrisgroup.com/ requires username and password. If a user account associated with an organisation is compromised this gives the malicious actor access to use/create API keys to do anything they want in Alma.

    For example a malicious actor could create an API key which allows them to access all the user information stored in Alma.

    Access to manage API keys should be locked down with 2FA, password login is not sufficient.

    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

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    2 comments  ·  APIs and Integrations  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all 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

18. Import PO Approvals Job schedule more than 1 time a day

    Currently the Import PO approvals job will only run once a day. Can this be scheduled to run multiple times a day.

    We are using rialto which is supposed to be quick way of ordering but jobs are not sent to vender straight away as it has to wait for the job to run adding delays

    If this could be scheduled multiple times a day it would greatly improve the timeline

    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

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  APIs and Integrations  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all 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

19. Allow request-type webhooks to be triggered only under certain conditions

    We would like the ability to configure request webhooks such that they are triggered only when certain conditions are met. Request webhooks for patron physical item requests include the user’s primary ID and the title they have requested. This type of circulation information should in most circumstances stay within the library and not be shared with third parties. But it may be necessary to enable a third-party integration in order to provide needed services, such as a smart locker delivery service. Currently, request-type webhooks are triggered by any request in Alma, regardless of request type or destination. We would like our webhook to be triggered only by requests that designate our smart locker “library” as a destination. This way we would send user data to the third party only when it is necessary to perform the service the user has requested. This enhancement would enable us and our students to benefit from this integration without sacrificing patron privacy.

    We would like the ability to configure request webhooks such that they are triggered only when certain conditions are met. Request webhooks for patron physical item requests include the user’s primary ID and the title they have requested. This type of circulation information should in most circumstances stay within the library and not be shared with third parties. But it may be necessary to enable a third-party integration in order to provide needed services, such as a smart locker delivery service. Currently, request-type webhooks are triggered by any request in Alma, regardless of request type or destination. We would like… more

    50 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    1 comment  ·  APIs and Integrations  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all 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

20. API access to Item's edit history

    For rolling back changes in a batch of items, it would be extremely useful to have API access to the Item Changes that are reported in the History tab of each item record.

    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

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  APIs and Integrations  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all 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