October 2022 - Koha-bugs - lists.koha-community.org

[Bug 15500] Add FRBRized View to OPAC & Staff Interface Results
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '22

05 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15500 --- Comment #4 from Heather <heather_hernandez(a)nps.gov> --- Oh, Jason, your thoughts are so cataloging-tastic!! (Please note, all my remarks are MARC21-centric.) Authority records have long had a role in this sort of clustering, e.g., see this authority record for The Hobbit by Tolkien: https://lccn.loc.gov/n79102640 And the work record here: http://experiment.worldcat.org/entity/work/data/449428 Every expression of this work will have the authorized 100 field for Tolkien and a 240 10 Hobbit With the 245 field reflecting the transcribed title of the expression. The 100/240 pairing is used (with the cross references in the authority record to facilitate searching) to cluster the expressions (and manifestations) under the work record. (With the 1XX in the bib having the $9 containing the record number of the author/title authority record? And/or the 240 having this $9? I'm not sure how it's currently working--I could look into it & experiment if it's helpful.) But not all works have authority records, and authorities can be a big learning curve. And not all bibs with a 1XX/240 pairing have authority records. If Koha could use the pre-RDA (and early RDA) 1XX/240 pairings to cluster, that would be fabulous. If this could be a simple matter of developer magic, that would be lovely! But, yes, 7XX Linking Entry Fields are wonderful and can also be used!!! It's what they are there for, and where RDA is going--they're going to be used more and m ore. All linking entry links in Koha would have to be functional, but that's another bug(s) and soapbox...:) A 775 is perfect for actual other editions (you cataloger, you, Jason!), but you would sometimes have a 776 ("Additional Physical Form Entry") for ebooks of a book, audiobooks of a book, etc.--that is, e.g., an audiobook would have the 776 linking back to the print book from which it was read, and also a 775 back to the work record--so a bib record would have to be created for the work. This is really easy to do, and I think it would be easier for a lot of libraries to do than to wade into authorities. Because you have to have something to put into the $w of the 775--a record number (for OCLC libraries, its typically an OCLC record number in the corresponding 001 bib record). It would be very possible to automate this--once a bib record set is created of the expressions, and a work bib record is created, the identical 775 could be placed in all the manifestations of the bib. But, then again, wouldn't it be nice if there could be some developer magic that would allow the library to set the matching threshold, and then a search would just cluster the similar bibs together, based on matching 1XX and/or 24X fields? (And absolutely clustering those bibs that have an authority record with corresponding 1XX/240, or 130, or those bibs with 1000% matching 775s?) Cheerio! h2 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 29719] New: onloan dates are cleared from items when importing and overlaying
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '22

05 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29719 Bug ID: 29719 Summary: onloan dates are cleared from items when importing and overlaying Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Check an item out to a paron 2 - Export the item using Tools->Export data 3 - Stage the record for import 4 - Match on 999c and replace items 5 - Import the batch 6 - View the record and note item is checked out and Available 7 - In the DB note the onloan value is now null -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 12709] Send a custom email to some or all patrons
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '22

05 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12709 --- Comment #7 from Nick Clemens <nick(a)bywatersolutions.com> --- (In reply to Katrin Fischer from comment #6) > (In reply to Ray Delahunty from comment #5) > > Isn't this a duplicate of Bug 16149 which added the ability to combine > > report results with a custom notice to generate emails? I've been testing > > out the new feature that came in 19.05 but as it doesn't support html in the > > message we probably wont be able to use it. (Enhancement request being > > worked on right now.) > > Bug 16149 relies on a plugin, I think this would be good to have in 'core'. To clarify, 16149 is a command line script, there is also a plugin, but they are separate -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 12709] Send a custom email to some or all patrons
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '22

05 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12709 --- Comment #6 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Ray Delahunty from comment #5) > Isn't this a duplicate of Bug 16149 which added the ability to combine > report results with a custom notice to generate emails? I've been testing > out the new feature that came in 19.05 but as it doesn't support html in the > message we probably wont be able to use it. (Enhancement request being > worked on right now.) Bug 16149 relies on a plugin, I think this would be good to have in 'core'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 13965] Add date last seen on item search
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '22

05 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13965 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|date last seen on item |Add date last seen on item |search |search --- Comment #1 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I think this would be really helpful especially in combination with the inventory tool. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15500] Add FRBRized View to OPAC & Staff Interface Results
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '22

05 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15500 --- Comment #3 from Jason Robb <jrobb(a)sekls.org> --- Would love to see this working both in the staff client and OPAC, and would *really* love to see hold capability added to increase patron ease of access to resources with multiple editions living on different bib records. I wonder if Koha's existing authorities architecture could be leveraged as a jumping off point for this? There are some parallels. FRBR organizes things from the top-down - Work > Expression > Manifestation > Item Generally we're only handling Manifestations (at the bib level) and Items (at the item level) in Koha. We could potentially create a collection of "records" for Works similar to an authority file by pulling the general attributes out of existing bib records then merging them into singular "records" for each Work. The Work "record" could store the groupID along with other relevant information, including matchpoints like author, ISBNs and eventually links to external records of the work (LibraryThing, OpenLibrary, Wikidata, etc.) The identifier of the Work could then be added into relevant bib records (maybe the 775?) to create a horizontal link between multiple bib records. Ideally this would all be automated, where, if you bring in a bib record for new edition of an existing Work it gets linked to the existing Work automatically. And if that Work doesn't exist yet, a new Work "record" is generated. Authorities can do some of this type of thing already, just with different parts of the record. And some of the tools in the authorities module would also be useful for managing Works as far as editing, merging, etc. Just a thought! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 8179] Receiving multiple order lines at once
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '22

05 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8179 --- Comment #80 from David Cook <dcook(a)prosentient.com.au> --- Comment on attachment 120622 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=120622 Bug 8179: Add AcqReceiveMultipleOrderLines syspref to preference configuration Review of attachment 120622: --> (https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=817…) ----------------------------------------------------------------- ::: koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/acquisitions.pref @@ +113,5 @@ > - pref: EmailAddressForSuggestions > class: email > + - > + - pref: AcqReceiveMultipleOrderLines > + defualt: no Typo in default -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 31683] New: Return descriptions from items API endpoint
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '22

05 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31683 Bug ID: 31683 Summary: Return descriptions from items API endpoint Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com CC: tomascohen(a)gmail.com It would be pretty handy of the items endpoint (/api/v1/items ) returned the descriptions along with the actual codes. For example if I go here to '/api/v1/items/419' the location returned is 'GEN', which is the A.V. code. It would be neat if I could get the description too, 'General stacks'. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 31679] New: Circulation Rules needs individual rule cloning
by bugzilla-daemon＠bugs.koha-community.org 04 Oct '22

04 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31679 Bug ID: 31679 Summary: Circulation Rules needs individual rule cloning Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently you can clone a set of rules, but you can't clone an individual rule. It would be great if the action buttons were replaced by a single action button, and included a cloning option to clone that rule to another branch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 31681] New: Daily digest notice for ALL notices
by bugzilla-daemon＠bugs.koha-community.org 04 Oct '22

04 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31681 Bug ID: 31681 Summary: Daily digest notice for ALL notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org What if a patron had the option to have a SINGLE notice per day, that was a digest of all notices to them? So, if they have this option checked, they would get a notice at the end of the day, or beginning, that would contain any hold, overdue, predue, etc notices. So, if this is checked, instead of queuing up for the regular cron, maybe the notice is sent in a new cron that is once a day. If done, it might also be beneficial to note on the parton's notifications how the notification was queued (right away/daily). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0