61 results found

1. Field creation date by changes via API

   While changing a specific field in a user records via API the "creation date" should be changed only in this field and not in any other fields – which happens now – in order to be able to recognize the newest changes in a user profile.

   24 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

2. SIS Import/Synchronise: improve invalid character handling

   When the Alma SIS Import/Synchronise job runs, if any of the files contain an invalid XML character, the entire job is aborted. The consequence of this is that user data held in Alma might be out-of-date, depending on whether it has recently changed in central systems. I assume this behaviour occurs because one of the initial steps when the import runs is to parse the input files as a whole, rather than parsing each user record individually.

   This Ideas Exchange ticket requests that the SIS job is improved so that the job does not abort, but instead skips over the individual user record(s) that contains the invalid character(s).

   When the Alma SIS Import/Synchronise job runs, if any of the files contain an invalid XML character, the entire job is aborted. The consequence of this is that user data held in Alma might be out-of-date, depending on whether it has recently changed in central systems. I assume this behaviour occurs because one of the initial steps when the import runs is to parse the input files as a whole, rather than parsing each user record individually.

   This Ideas Exchange ticket requests that the SIS job is improved so that the job does not abort, but instead skips over the… more

   24 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. Provide access to files FTPed to third-parties

   We run a daily scheduled "Publishing to OCLC" job which sends OCLC our new and changed MARC records via FTP.

   From time to time, OCLC email us to let us know that some files were not processed due to errors in the MARC (typically blanks in the leader). To fix these, we need to download the problematic files, correct them, and manually upload to OCLC again.

   However we don't have access to these files in Alma. (OCLC deletes them from their server when their automated process picks them up so we can't get them from there either.)

   We managed to log a Salesforce case to get the developers to find the files for us, so obviously the files are retained. However the process took several months and a lot of ExL staff time.

   Libraries should be able to access the file that was sent to or from a third party directly from the job report.

   We run a daily scheduled "Publishing to OCLC" job which sends OCLC our new and changed MARC records via FTP.

   From time to time, OCLC email us to let us know that some files were not processed due to errors in the MARC (typically blanks in the leader). To fix these, we need to download the problematic files, correct them, and manually upload to OCLC again.

   However we don't have access to these files in Alma. (OCLC deletes them from their server when their automated process picks them up so we can't get them from there either.)

   We managed to… more

   24 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

4. Acquisitions API - Interested in user – add other identifiers in addition to Primary ID

   Currently Alma allows multiple identifiers to identify ALMA Users, however the Acquisitions API (Interested In users) mapping only allows “primary_ID”.

   We’d like any other identifiers used in Alma also be allowed in the mapping (e.g. Email Type). If this is added on the API parameter, staff can use the less sensitive info instead on vendor site.

   Noting that adding other identifiers in the Interested_User api parameters - is only doing what EOD acquisition workflow/mapping can already do.

   It is cumbersome for staff having need to search the requester’s primary id to be able to use this feature.

   Ref #06652820 – Gobi Order API – interested_user - alma identifiers

   Currently Alma allows multiple identifiers to identify ALMA Users, however the Acquisitions API (Interested In users) mapping only allows “primary_ID”.

   We’d like any other identifiers used in Alma also be allowed in the mapping (e.g. Email Type). If this is added on the API parameter, staff can use the less sensitive info instead on vendor site.

   Noting that adding other identifiers in the Interested_User api parameters - is only doing what EOD acquisition workflow/mapping can already do.

   It is cumbersome for staff having need to search the requester’s primary id to be able to use this feature.

   Ref #06652820 –… more

   23 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

5. Accession number available by API

   Hello,
   To be able to develop several external tools (relabelling, cataloging, ...) we need to access the "Accession number" table by API (read and write).
   This would probably give many other clients oportunities in developing external tools for managing physical collections.
   Best regards.

   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

   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

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

7. Add ability to customize the data exported by Bursar integration profile using System = Other

   When creating an integration profile of type Bursar which uses a ‘System’ setting of ‘Other’ there should be more granular control over what data is included in the export.

   If a ‘System’ setting of ‘Other’ is selected, then a 'Data' tab should be made available which will allow you to select via checkbox what fines/fees and user data is included in the exported file. The data available should at minimum include, but not necessarily be limited to, what is accessible via API.

   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

   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

8. Add export start/effective date to Bursar integration profile configuration settings

   When creating a new Bursar integration profile, we want to be able to limit the transactions being exported to only those generated after a specific date. This is in addition to ‘Time before export (days)’ setting. We've never used an integration profile to export fines/fees to be transferred to our bursar office and have instead used the API. We're now stuck in a situation where we can't switch to using an integration profile because without a start/effective date there's no way to prevent the exported files from creating double billing of transactions that have already been transferred to our bursar via API.

   When creating a new Bursar integration profile, we want to be able to limit the transactions being exported to only those generated after a specific date. This is in addition to ‘Time before export (days)’ setting. We've never used an integration profile to export fines/fees to be transferred to our bursar office and have instead used the API. We're now stuck in a situation where we can't switch to using an integration profile because without a start/effective date there's no way to prevent the exported files from creating double billing of transactions that have already been transferred to our bursar… 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

   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

9. bursar integration - option to export fine/fee credits even if minimum value > 0

   Currently in order for fine/fee credits to be exported in the bursar integration, the minimum value must be set to zero, which means Alma will export fines of any amount even if they are very small.
   We would like to be able to set a minimum value for the fine export, but still export credits. Ideally we'd like a checkbox to tell Alma to apply the minimum value amount to credits as well as to debits. For example if we set the minimum value to $5 and check a box to include credits, Alma would export any fines over $5, as well as any credits over $5.

   Currently in order for fine/fee credits to be exported in the bursar integration, the minimum value must be set to zero, which means Alma will export fines of any amount even if they are very small.
   We would like to be able to set a minimum value for the fine export, but still export credits. Ideally we'd like a checkbox to tell Alma to apply the minimum value amount to credits as well as to debits. For example if we set the minimum value to $5 and check a box to include credits, Alma would export any fines over $5,… 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

   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. Browzine : Journals with multiple sources

    Libraries who are using Browzine are exporting our journals holdings file using a Google Scholar XML schema. For titles that have multiple sources, Browzine will based on their own algorithm to determine one source to be made available to the users in the Browzine interface. According to Third Iron, this "choosing algorithm" is designed to pick the source that has the widest coverage. This is fine in most of the cases but if we want to override this "decision", we will need to write in to Third Iron.

    Suggestion: To consider having a designated field in the portfolio record for libraries to indicate as “preferred source in Browzine”? This would allow libraries to easily flag out titles that we want to be visible in Browzine.

    Thank you.

    Libraries who are using Browzine are exporting our journals holdings file using a Google Scholar XML schema. For titles that have multiple sources, Browzine will based on their own algorithm to determine one source to be made available to the users in the Browzine interface. According to Third Iron, this "choosing algorithm" is designed to pick the source that has the widest coverage. This is fine in most of the cases but if we want to override this "decision", we will need to write in to Third Iron.

    Suggestion: To consider having a designated field in the portfolio record for… more

    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

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

12. Provide all User Profile data via API

    Please provide at least GET API access to user profile data (Config -> User Management -> Roles and Registration -> Profiles). This should be full data: for each profile, include full roles and parameters.

    Currently, there is no good way to export user profile data from Alma. It does not seem to be available in Analytics; it's not in any of the code or mapping tables available via "config" APIs.

    We can use the Alma UI to export each profile to Excel individually... but that is not practical at scale, and the role data we can extract from Excel is not directly applicable / compatible with what's needed for the "user_role" data in the "user" APIs.

    Having accurate and complete user profile data available via API would make it much easier and safer to manage our staff permissions programmatically.

    Please provide at least GET API access to user profile data (Config -> User Management -> Roles and Registration -> Profiles). This should be full data: for each profile, include full roles and parameters.

    Currently, there is no good way to export user profile data from Alma. It does not seem to be available in Analytics; it's not in any of the code or mapping tables available via "config" APIs.

    We can use the Alma UI to export each profile to Excel individually... but that is not practical at scale, and the role data we can extract from Excel is… 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

    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

13. Check box option to disable Alma from appending file names in publishing profiles

    We publish files to many third party vendors. Some vendor systems must have their files named with a certain convention and CANNOT process them if that filename convention is altered in any way.

    Alma publishing profiles are current configured to append "_new" to the end of files it publishes, even if you specify a file name already. We would like the option to either enable or disable each publishing profile from appending the filenames it sends. They can be enabled by default, or not, but the option would be helpful.

    Use case: We are publishing files of electronic holdings to OCLC because the current OCLC Data Sync profiles as they exist within Alma do not handle electronic materials (see https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/090Integrations_with_External_Systems/030Resource_Management/110Publishing_to_OCLC#Publishing_Electronic_Holdings_to_OCLC ). OCLC asks for a specific file naming convention, and that name cannot be altered. The profile adds "_new" to the end of the file name, which prevents their system from processing the file entirely. As a result, we have to either manually download these incredibly large files, change the file name, the put them on OCLC's server, or write a script to do this for us with no coders on staff.

    We publish files to many third party vendors. Some vendor systems must have their files named with a certain convention and CANNOT process them if that filename convention is altered in any way.

    Alma publishing profiles are current configured to append "_new" to the end of files it publishes, even if you specify a file name already. We would like the option to either enable or disable each publishing profile from appending the filenames it sends. They can be enabled by default, or not, but the option would be helpful.

    Use case: We are publishing files of electronic holdings to… 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

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

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

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

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

18. Add support for System for Cross-domain Identity Management (SCIM) standard

    System for Cross-domain Identity Management (SCIM) is a standard for automating the exchange of user identity information between identity domains, or IT systems. Supporting this standard would allow for better automation and SIS integration for institutions using Alma.

    https://en.wikipedia.org/wiki/System_for_Cross-domain_Identity_Management

    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

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

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