September 2018 - Koha-bugs - lists.koha-community.org

[Bug 19635] New: OAI-PMH deleted records are now default and are listed first
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '19

04 Mar '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19635 Bug ID: 19635 Summary: OAI-PMH deleted records are now default and are listed first Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It seems bug 15108 made some changes to which records are served up first by the OAI server. When making a basic request with no token, i.e.: http://localhost:8080/cgi-bin/koha/oai.pl?verb=ListRecords&metadataPrefix=m… You get any deleted records first. When continuing if you have more than 50 deleted records the resumptionToken also includes deleted records We have services harvesting the entire catalog that don't expect deleted records first. I am not seeing a way to prevent them, and wonder if they should not be served first. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 21252] New: Koha::Patron->do_check_for_previous_checkout should take Koha::Item as parameter
by bugzilla-daemon＠bugs.koha-community.org 01 Mar '19

01 Mar '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21252 Bug ID: 21252 Summary: Koha::Patron->do_check_for_previous_checkout should take Koha::Item as parameter Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 21401] New: Account offsets should save the transacting library
by bugzilla-daemon＠bugs.koha-community.org 01 Mar '19

01 Mar '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21401 Bug ID: 21401 Summary: Account offsets should save the transacting library Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 39

[Bug 19460] New: Limit total number of checkouts allowed per patron by patron category code
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '19

28 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19460 Bug ID: 19460 Summary: Limit total number of checkouts allowed per patron by patron category code Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: kyle(a)bywatersolutions.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Goal of development: Limit total number of checkouts allowed per patron by patron category code Work to be done: 1) Add new circulation rule "Max checkouts ( global, most restrictive )" to circulation rules. 2) Modify C4::Circulation::TooMany to respect this new rule 3) Modify script and template to show errors relating to this new rule -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 21247] New: Cannot add more than one emoji across the entire database as a tag
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '19

27 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21247 Bug ID: 21247 Summary: Cannot add more than one emoji across the entire database as a tag Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Well I suppose that's not really fair - you can add them but you can only see the first one in the approval list, and on the detail/results pages. To replicate: Add a tag, such as 😍 to a biblio in the OPAC try to add another emoji, such as 🎶 In my 18.05, this won't work and the second tag is never inserted into tags_approval, though it is inserted into tags_all. It seems to be mysteriously approved as under the first emoji added, as well. I checked the DB encoding, it seemed correct. The database I was testing with was an upgraded one, 3.20 -> 18.05.02 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 21065] New: Data in accountoffsets and accountlines is deleted with the patron leaving gaps in financial reports
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '19

26 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21065 Bug ID: 21065 Summary: Data in accountoffsets and accountlines is deleted with the patron leaving gaps in financial reports Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The tables accountoffsets and accountlines are both "cleaned up" when a patron is deleted by using FK constraints. This is a problem because 1) The patrons have a "right to be forgotten" with GDPR and you can't refuse to delete them if their fines are paid etc. 2) Especially for partial payments and in other cases the data in accountlines and accountoffsets is neded to create reliable reports for statistics, but also for financial reports. It's not possible to determine from other tables like statistics and action_logs what fines are linked to which payment which doesn't allow to create reports by fine/fee type and similar. Instead of deleting the info, we should really just anonymize it. -- CREATE TABLE `accountoffsets` ( `borrowernumber` int(11) NOT NULL DEFAULT '0', `accountno` smallint(6) NOT NULL DEFAULT '0', `offsetaccount` smallint(6) NOT NULL DEFAULT '0', `offsetamount` decimal(28,6) DEFAULT NULL, `timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY `accountoffsets_ibfk_1` (`borrowernumber`), CONSTRAINT `accountoffsets_ibfk_1` FOREIGN KEY (`borrowernumber`) REFERENCES `borrowers` (`borrowernumber`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; CREATE TABLE `accountlines` ( `accountlines_id` int(11) NOT NULL AUTO_INCREMENT, `issue_id` int(11) DEFAULT NULL, `borrowernumber` int(11) NOT NULL DEFAULT '0', `accountno` smallint(6) NOT NULL DEFAULT '0', `itemnumber` int(11) DEFAULT NULL, `date` date DEFAULT NULL, `amount` decimal(28,6) DEFAULT NULL, `description` mediumtext COLLATE utf8_unicode_ci, `dispute` mediumtext COLLATE utf8_unicode_ci, `accounttype` varchar(5) COLLATE utf8_unicode_ci DEFAULT NULL, `amountoutstanding` decimal(28,6) DEFAULT NULL, `lastincrement` decimal(28,6) DEFAULT NULL, `timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `notify_id` int(11) NOT NULL DEFAULT '0', `notify_level` int(2) NOT NULL DEFAULT '0', `note` text COLLATE utf8_unicode_ci, `manager_id` int(11) DEFAULT NULL, PRIMARY KEY (`accountlines_id`), KEY `acctsborridx` (`borrowernumber`), KEY `timeidx` (`timestamp`), KEY `itemnumber` (`itemnumber`), CONSTRAINT `accountlines_ibfk_1` FOREIGN KEY (`borrowernumber`) REFERENCES `borrowers` (`borrowernumber`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `accountlines_ibfk_2` FOREIGN KEY (`itemnumber`) REFERENCES `items` (`itemnumber`) ON DELETE SET NULL ON UPDATE SET NULL ) ENGINE=InnoDB AUTO_INCREMENT=4666 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 41

[Bug 21427] New: Format prices on ordered/spent lists
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '19

26 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21427 Bug ID: 21427 Summary: Format prices on ordered/spent lists Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org On bug 19271 we decided that the work to fix the prices should be split out into it's own bug. Leaving all credit to Katrin for spotting the issue and the initial patch. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 19778] New: Move template JavaScript to the footer: Serials, part 4
by bugzilla-daemon＠bugs.koha-community.org 25 Feb '19

25 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19778 Bug ID: 19778 Summary: Move template JavaScript to the footer: Serials, part 4 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Blocks: 17858 +++ This bug was initially created as a clone of Bug #19777 +++ In order to conform to best practices for performance staff client template javascript should be in the footer instead of the header. This patch will do so for even more of the serials templates. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17858 [Bug 17858] Omnibus: Move staff client JavaScript to the footer -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 20174] New: Remove xml_sax.pl target from Makefile.pl
by bugzilla-daemon＠bugs.koha-community.org 25 Feb '19

25 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20174 Bug ID: 20174 Summary: Remove xml_sax.pl target from Makefile.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org A line was added to Makefile.PL with Bug #5033 but it doesn't seem like it's used anymore? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 19832] New: SIP checkout removes extra hold on same biblio
by bugzilla-daemon＠bugs.koha-community.org 25 Feb '19

25 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19832 Bug ID: 19832 Summary: SIP checkout removes extra hold on same biblio Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: boutrosboutrosboutros(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com C4/SIP/ILS/Transaction/Checkout.pm includes the following bit of code which remove any hold that that matches the biblio and bilbionumber in checkout: # Fill any reserves the patron had on the item. # TODO: this logic should be pulled internal to AddIssue for all Koha. $debug and warn "pending_queue: " . (@$pending) ? Dumper($pending) : '[]'; foreach (grep {$_->{borrowernumber} eq $self->{patron}->{borrowernumber}} @$pending) { $debug and warn "Filling reserve (borrowernumber,biblionumber,reservedate): " . sprintf("(%s,%s,%s)\n",$_->{borrowernumber},$_->{biblionumber},$_->{reservedate}); ModReserveFill($_); # TODO: adjust representation in $self->item } As far as I can tell, this code is completely unnecessary, since C4::Circulation::AddIssue allread calls C4::Reserves::MoveReserve which fullfills the hold. What's more, if the borrower has multiple holds on the same biblio, all of them will be removed. This is clearly wrong. I purpose to remove the code above, unless someone can explain why SIP checkout should behave different than normal checkout in this case. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16