Fix ebsco and summon user list #117
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fix issue where importing BiblioCommons data for Sierra libraries is not working correctly Update release notes Tested on my local by running a BiblioCommons import with shelves and staff list csv files
Update volume level hold functionality for Aspen->Koha to not include an item group id if there is no item group id (if it is 0) Update release notes
BiblioCommons Import
- Execute checkBackgroundProcesses in background - Execute cron process in foreground to keep the container alive - Remove 'sleep infinity' trick in case cron is enabled
Chloe070196
force-pushed
the
fix_ebsco_and_summon_user_list
branch
from
9fe2b5e to
c3a373f
Compare
add alternate library cards to LiDA
Fixes mixup on item-level holds between patron name and pickup branch. https://trello.com/c/RQQkLQ3L/3844-add-robertson-academy-gate#comment-66c656a7e4aae5792da48f87
[pull] 24.09.00 from Aspen-Discovery:24.09.00
Merge pull request Aspen-Discovery#451 from Aspen-Discovery/24.09.00
- When freezing a hold, fixed a bug where the date picker actions when selecting the thaw date were not using translated values.
…ice_in_foreground Cron service in foreground
Fixed a bug where when selecting radio button values in Facets (i.e. Search Within), it would display a different (previously selected) value as being selected.
https://trello.com/c/PNcsJLs7 Provided a list of numbers, print Code 39 barcodes for each number on Avery 5160 labels
+ Enables sidebar Admin Navigation + Replaces "patron id" language with "barcode numbers"
…/24.09.00-QA Correct regexp for spaces-not-tabs detection
Account for patron types being '0' when doing boolean check to get the patron type object (common for Sierra libraries) This issue was made apparent when attempting to enable materials requests for patrons of this type Tested on my local To Test: Create a patron type 0 Enable materials requests for patrons of that type Check to see if materials requests are available via masquerade for a patron of that type
- If Lexis Nexis is used, the linking url will use /title instead of /media To Test: If using Lexis Nexis, links to those records will have an appended /title instead of the usual appended /media - Add patron code to variables used for Sierra self registration via Aspen To test: For a Sierra library, make sure the proper patron code is filled in, in self registration forms -> patron code Register a new test patron Check in Sierra that patron was registered with the correct type Updated release notes and tested on my local
Add ticket number
…ounts Use the cloudLibrary settings that have a scope that matches the home library of the account that is doing the checkout (either the main account or linked card).
Get Patron Type Object Check
The New Materials Request email to staff will only try to send if it has not already been sent.
[pull] 24.09.00 from Aspen-Discovery:24.09.00
If the user agent contains spammy content (such as "sleep(" or "SELECT") return a 404 error. The check for spammy content is case insensitive.
Misc Bug Fixes for LiDA & Discovery
cloudLibrary with alternate cards bug fixes
Ciculation username is needed to properly set the checkout location for checkout.
|
Summon records all displaying nicely on lists with working links! |
sourceIds can have more than 50 characters, in fact, for records such as summons, it appears to be the norm. This resolves the first part of the bug by now ensuring that records with longer sourceIds can be added to the user_list_entry table.
Fixes the 'SearchObject_SummonSearcher::getRecords is undefined' error by adding the necessary method to this class/
The earlier check ascertained that no searchOptions had been allocated to allow a records' data to be processed. If searchOptions were found, they were assigned to this record, meaning that every record in a list was assigned the search options of the very first record to be processed. This meant all records were incorrectly assigned the sourceId of the first one to be processed. The current check also looks at the queryString, containing the record's sourceId, meaning that each distinct record will be processed individually, and that the correctId will be assigned. This then allows for the check verifying that the record found is the record on the list to return true, and for the record to be listed and rendered correctly.
Chloe070196
force-pushed
the
fix_ebsco_and_summon_user_list
branch
from
c3a373f to
a1619a6
Compare
Chloe070196
merged commit 0de7c87
into
PTFS-Europe:fix_ebsco_and_summon_user_list
1 of 2 checks passed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch aims to fix the issue where Ebsco eds and Summon records cause user list pages to crash, or result in improper render of records on these pages.
There were in fact two issues:
1- the records were not added to user_entry_list (unless they were groupedWorks)
2- the list was not displayed, and instead the user would see an error stating that getRecords is undefined
Probable causes:
1- the sourceId having a type of VARCHAR(50)
(some sourceIds, for example the ones associated with summon records, exceed that limit, which led to an
uncaught error being thrown by the database)
2- during the render of the list, the searchObject for each record is generated using
SearchObjectFactory::initSearchObject($sourceType). For groupedWorks, this implements a class that
includes a getRecord method. For all other sourceTypes however, it used SearchObject_BaseSearcher
which does not implement that method.
Test plan: (to go through first without then with the patch applied)
NOTES:
investigation ?
(not certain what it is checking for, precisely)