November 2016 - Koha-bugs - lists.koha-community.org

[Bug 10455] remove redundant 'biblioitems.marc' field
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '16

30 Nov '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10455 Mason James <mtj(a)kohaaloha.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to Master |Pushed to Stable -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14224] patron notes about item shown at check in
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '16

30 Nov '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14224 Aleisha Amohia <aleishaamohia(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |17698 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17698 [Bug 17698] Make patron notes show up on staff dashboard -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15428] Different timeout preference for opac and intranet
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '16

30 Nov '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15428 jdemuth(a)roseville.ca.us <jdemuth(a)roseville.ca.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jdemuth(a)roseville.ca.us -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10662] Build OAI-PMH Harvesting Client
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '16

30 Nov '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662 --- Comment #109 from David Cook <dcook(a)prosentient.com.au> --- I think part of the problem is that I don't want to use Koha's batch import system. I want to handle importing individual records belonging to arbitrary metadata schemas myself. At the moment, I'm abusing the batch system to do what I want. I want to filter the data, I want to check database-level OAI-PMH data, then I want to check Zebra-level MARCXML data, and the batch import isn't really set up for that. And I think it might be prohibitively difficult to update it to handle that. I could decompose C4::ImportBatch::BatchCommitRecords into individual add/update/delete functionality. That would mostly work, although then I would lose the history that the batches afford you. But then there's bug 14367 which would make up for that in theory. I suppose this might all just be idealistic thinking on my part, and perhaps outside the scope of this enhancement. I already have code that mostly works using just the OAI-PMH identifier. It's a flawed concept, but it's the same one used by VuFind and DSpace, and they haven't fallen over yet. I have a few fixes I need to make to C4::Matcher and C4::Search for the matching to work as expected though. I think perhaps what I have so far will just have to be good enough for now. It's far from ideal, but it's functional. I'm tempted to add an "originDescription" as per https://www.openarchives.org/OAI/2.0/guidelines-provenance.htm in each harvested record so that we preserve as much metadata as possible during the OAI-PMH harvest, although I think that's an inappropriate use of that element, as that's supposed to be created at dissemination time rather than harvest time. Perhaps I'll just capture all relevant data and store it in the RDBMS, and we can use it at a later time if necessary. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14367] History for MARC records. Roll back changes on a timeline or per field.
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '16

30 Nov '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14367 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au --- Comment #6 from David Cook <dcook(a)prosentient.com.au> --- Not sure about the implementation of this idea, but I like the idea of storing a history for records... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10662] Build OAI-PMH Harvesting Client
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '16

30 Nov '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |In Discussion --- Comment #108 from David Cook <dcook(a)prosentient.com.au> --- Thinking more about matching and how using a OAI-PMH identifier really isn't enough, especially as the identifier is unique only within the repository. You could have two separate repositories with the exact same identifier, so you need to check the OAI-PMH repository URL as well. https://www.openarchives.org/OAI/openarchivesprotocol.html#UniqueIdentifier There are a few ways of verifying that two records describe the same upstream record, but it involves some analysis. https://www.openarchives.org/OAI/2.0/guidelines-aggregator.htm#Identifiers And that analysis gets tricky when you're wanting to match against MARCXML records using Zebra. Especially since different frameworks may or may not contain the fields that you store OAI-PMH data in for the purposes of matching. -- I'm thinking of maybe making a sort of tiered search... where we search the database for OAI-PMH details... and if none are found then we use the Zebra search. However, that's problematic as it sets up some inconsistencies in methods of importing. -- To date, we think about importing only in terms of MARCXML... and that makes some sense. So with OAI-PMH, surely we can still just think of it in terms of MARCXML. Except that the harvested record isn't necessarily the same as the imported record. Although maybe it should be. Maybe instead of using OAI specific details, we should require the use of http://www.loc.gov/marc/bibliographic/bd035.html. I don't know how realistic that is though. How many organisations actually have registered MARC Organisation codes? Maybe that's the prerogative of the Koha user rather than the Koha system though. It looks like VuFind uses the MARC 001 for matching (https://github.com/vufind-org/vufind/blob/master/import/marc.properties) although that's obviously highly problematic. It has some facility for adding a prefix to the 001 for uniqueness, but that's a hack. A sample harvest of DSpace's oai_dc to VuFind's Solr indexes uses the OAI-PMH identifier for matching it seemes (https://vufind.org/wiki/indexing:dspace) but as I noted above that's also technically problematic as you may have the same identifier in multiple repositories. In theory it shouldn't happen... but it could. It looks like DSpace uses the OAI-PMH identifier (stored in the database it seems) for matching as well https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/d…. As noted above, this has issues if the identifier isn't unique outside the repository. DSpace has a sanity check to make sure the item hasn't been deleted before trying to do an update... I've been thinking I could match a OAI-PMH identifier to a biblionumber using a foreign key with restrict so that you can't delete a bib record without unlinking it from its OAI-PMH provenance record. So VuFind and DSpace don't have the most sophisticated of matchers and they both have problems which I'd like to avoid. -- I recall Leif suggesting that we export some data to MySQL tables (e.g. 001, 003, 020, 022, 035), but that's not without its difficulties as well, and keeps us locked into MARC as well. -- I also remember Mirko mentioning Catmandu::OAI, but it's just a layer over HTTP::OAI, and HTTP::OAI is flawed in a few ways and won't meet Stockholm University Library's requirements of having a OAI-PMH harvester that parses a XML stream. In any case... the downloading of OAI-PMH records is the easy part. It's what to do with them once we're uploading to Koha... -- For a truly robust solution, I think we'd need to overhaul Koha's importing facilities, and I'm not sure of the best way to do that. We need to be able to link X number of arbitrary identifiers with a particular Koha "record", and we need to be able to query those identifiers in a that allows for rapid matching. To be honest, this is something that Linked Data seems to be good at. You have a particular subject, and then you can link data to it arbitrarily. Then for your query, you could look for "?subject <http://koha/hasOAIPMHid> <oai:koha:5000>" or "?subject <http://koha/marc/controlNumber> '666'" Of course, ElasticSearch would work just as well, although you'd still want to save that data somewhere as a source of truth. We don't tend to use things like Zebra/Solr/ElasticSearch as the sole repository of data since we can refresh it from a source of truth. I suppose both a triplestore and a RDBMS have the same problem. You can link an identifier to a record, but what if you lose that link? You wind up with duplicates. I suppose the best you can do is try to prevent people from destroying links by accident. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 16873] New: Rrenewal error message not specific enough on self check.
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '16

30 Nov '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16873 Bug ID: 16873 Summary: Rrenewal error message not specific enough on self check. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Scenario: An item is set to auto-renew. The borrower uses Koha's web based self-check terminal to renew the item, but gets the error message "This book cannot be renewed" when he/she tries to renew the item, rather than a more specific message like "This item is set for auto-renewal". This is confusing to the borrower, who thinks that the item has not and cannot be renewed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 14699] Intranet search history issues due to DataTables pagination
by bugzilla-daemon＠bugs.koha-community.org 30 Nov '16

30 Nov '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14699 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer(a)bsz-bw.de Status|Pushed to Master |Pushed to Stable --- Comment #17 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- This patch has been pushed to 16.11.x, will be in 16.11.01! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14224] patron notes about item shown at check in
by bugzilla-daemon＠bugs.koha-community.org 29 Nov '16

29 Nov '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14224 --- Comment #18 from Aleisha Amohia <aleishaamohia(a)hotmail.com> --- (In reply to Jonathan Druart from comment #17) > Hi Aleisha, > I have tried this small snippet: > use Koha::Issues; > my $issue = Koha::Issues->find(1); > say $issue->branchcode; > and it works as expected. > Do you have a small part of code to recreate the error you got? use Koha::Issues; my $issue_id = $query->param('issue_id'); if ( $issue_id =~ /\d+/ ) { $issue = Koha::Issues->find($issue_id); } This returns the error. I have checked that issue_id is being assigned correctly and it is, so can't work out what I'm doing wrong. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14376] Allow the librarian to choose a patron when entering a purchase suggestion
by bugzilla-daemon＠bugs.koha-community.org 29 Nov '16

29 Nov '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14376 Marjorie Barry-Vila <marjorie.barry-vila(a)ccsr.qc.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marjorie.barry-vila(a)ccsr.qc | |.ca -- You are receiving this mail because: You are watching all bug changes.

1 0