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

[Bug 20210] New: Development requested: Claimed Return
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '19

05 Mar '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20210 Bug ID: 20210 Summary: Development requested: Claimed Return Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jesse(a)bywatersolutions.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org mark an item claimed returned via circulation a check box on list of checkouts on patron record and check out screen gray out/disable 'claimed return' status from lost menu on item detail page ? only perform this action from patron/circulation sys pref to ask 'charge', 'don't charge', or 'ask for confirmation' when marking an item claimed returned sys pref to say what 'lost' status is to be used for 'claimed returns' If no value 'claims returned' is off sys pref to offer an option to alert staff somehow, after a set number of claimed returns remove item from patron's current list of check outs This should stop fines from accruing keep basic information about the item on patron's record so you can track how many times they've said 'i returned that' This should be a tab on the list of checkouts section on patron detail and checkout page all titles they have claimed in the past (even if they have since been returned or deleted) ex. [title 1] / checked out {date} / claimed {date} / not returned / notes [title 2] / checked out {date} / claimed {date} / found {date} / notes Tab should show number of claimed returned items just as the checkout and hold tabs show counts Show unprocessed claimed returns in red in this tab show as missing in the opac and claimed returned in the staff client be able to mark item as 'found' from claimed tab if item happens to be found Offer options of ?returned by patron? or ?found in library? in a pull down to the side of every item that has been claimed. claimed items should be easily distinguishable on staff side (compared to lost items) on patron check out under 'Attention' alert 'Patron has claimed returns', if patron has claimed items that are not processed, that links to the 'Claimed' tab below next to each claimed item have a 'notes' field for anything which should be editable and updatable. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 19428] New: I cannot change the item type of a record in edit item page without changinging the item type in record.
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '19

05 Mar '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19428 Bug ID: 19428 Summary: I cannot change the item type of a record in edit item page without changinging the item type in record. Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jabirmon13(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I cannot change the item type of a record in edit item page without changinging the item type in record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 18337] New: No results found when advanced searching branches
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '19

05 Mar '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18337 Bug ID: 18337 Summary: No results found when advanced searching branches Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: martin.stastny(a)teamlibrary.cz QA Contact: testopia(a)bugs.koha-community.org Hello, I have a problem with advanced searching for specific branch without (or with - doesn't matter) another limit. I always get message: "No results found" in spite of there are a tons of books in the selected branch. Here is my searching url: search.pl?idx=kw&idx=kw&idx=kw&limit=branch%3APKK&sort_by=relevance By some research I found that if I delete "branch%3A" I get some results. We use a multi-instance Koha and the other instances have correct search. Can you help me, please. Kind regards, Martin -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 18507] New: Shibboleth auto-provisioning
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '19

05 Mar '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18507 Bug ID: 18507 Summary: Shibboleth auto-provisioning Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org, francart(a)gmail.com, frederic(a)tamil.fr, jonathan.druart(a)bugs.koha-community.org, katrin.fischer(a)bsz-bw.de, kyle(a)bywatersolutions.com, m.de.rooy(a)rijksmuseum.nl, martin.renvoize(a)ptfs-europe.com, matthias.meusburger(a)biblibre.com, mirko(a)abunchofthings.net, mtj(a)kohaaloha.com, olli-antti.kivilahti(a)jns.fi, pgsengstock(a)wisc.edu, theod(a)lib.auth.gr, tomascohen(a)gmail.com, veron(a)veron.ch, z.tajoli(a)cineca.it Depends on: 8446, 12026, 13114, 13569 Blocks: 12027 Shibboleth authentication has the ability to send an arbitrary number of attributes to koha; These attributes can be used to dynamically create (bug 12026) and update user records in koha. Our shibboleth patches should support the update/sync process as well as the create process. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8446 [Bug 8446] Shibboleth authentication https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12026 [Bug 12026] Shibboleth auto-provisioning https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12027 [Bug 12027] Shibboleth authentication for staff client https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13114 [Bug 13114] Disabled Shibboleth authentication spams logs https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13569 [Bug 13569] Shibboleth example config for Packages -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 16113] New: Specify due date for batch check out
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '19

05 Mar '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16113 Bug ID: 16113 Summary: Specify due date for batch check out Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: marjorie.barry-vila(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi, Currently , we can not manually select a due date in the batch check out tool. This could be a system preference like specifyDueDate or SpecifyReturnDate. Regards, Marjorie -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[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 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 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