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

[Bug 20627] New: Prevent leakages of user permissions to api access tokens
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '22

06 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20627 Bug ID: 20627 Summary: Prevent leakages of user permissions to api access tokens Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: dcook(a)prosentient.com.au, dpavlin(a)rot13.org, julian.maurice(a)biblibre.com, katrin.fischer(a)bsz-bw.de, oleonard(a)myacpl.org, tomascohen(a)gmail.com Depends on: 20568 Blocks: 20612, 20624 Bug #20568 allow users to create API access tokens, but it always associates all a users permissions with that access token and additionally if that user comes to have more permissions down the line those additional permissions are automagically added to the access token as well. This is generally bad practice for access tokens as in general, they should be of a definite scope and any time additional privileges are required the client application should have to ask for them and receive a new token with the additional privileges assigned to it. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20568 [Bug 20568] Add API key management interface for patrons https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20612 [Bug 20612] Make OAuth2 use patron's client_id/secret pairs https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20624 [Bug 20624] Allow switching off the OAuth2 client credentials grant -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 7826] Standardize link for triggering plugins and auto-entry
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '22

06 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7826 --- Comment #7 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Maybe as a first small step we could replace the ... with the icon used in the cataloguing editor? -- 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 #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