April 2015 - Koha-bugs - lists.koha-community.org

[Bug 1917] Add RSS Feeds for Lists
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1917 --- Comment #21 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Created attachment 38332 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=38332&action=edit Bug 1917 - Add RSS Feeds for Lists Test Plan: 1) Apply this patch 2) Create one or more public lists 3) View the list in the opac 4) Note the new RSS icon next to the list name 5) Open the link in FireFox or an RSS reader 6) You should see an RSS feed of your list with the title and author of each item as a hyperlink to the record details Signed-off-by: Nicole Engard <nengard(a)bywatersolutions.com> Followed test plan. Works as expected. Signed-off-by: Marc Véron <veron(a)veron.ch> Signed-off-by: Katrin Fischer <katrin.fischer.83(a)web.de> Signed-off-by: Martin Renvoize <martin.renvoize(a)ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 13331] New: Subfield does not show in cataloging editor - if subfield is disabled in OPAC/enabled in Staff, via frameworks
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13331 Bug ID: 13331 Summary: Subfield does not show in cataloging editor - if subfield is disabled in OPAC/enabled in Staff, via frameworks Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: mtj(a)kohaaloha.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Subfield does not show in cataloging editor - if subfield is disabled in OPAC/enabled in Staff, via frameworks -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 5511] New: Check for Change in Remote IP address for Session Security. Disable when remote ip address changes frequently.
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5511 Summary: Check for Change in Remote IP address for Session Security. Disable when remote ip address changes frequently. Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: System Administration AssignedTo: paul.poulain(a)biblibre.com ReportedBy: amit.gupta(a)osslabs.biz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 Check for Change in Remote IP address for Session Security. Disable when remote ip address changes frequently. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 59

[Bug 12122] New: TransferSlip should accept both itemnumber and barcode
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12122 Bug ID: 12122 Summary: TransferSlip should accept both itemnumber and barcode 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: benjamin.rokseth(a)kul.oslo.kommune.no QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com C4::Circulation::TransferSlip uses Getitem which takes either itemnumber or barcode. It should therefore accept both itemnumber and barcode as input. This would make it easy to generate print slip from barcode instead of doing item lookup (GetItemnumberfromBarcode) first. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 13603] New: autoBarcode setting hbyymmincr not taking month into account when looking up next increment
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13603 Bug ID: 13603 Summary: autoBarcode setting hbyymmincr not taking month into account when looking up next increment Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The hbyymmincr autoBarcode builder looks up all barcodes that begin with any number of letters ( the branchcode ) and a two-digit year directly afterward ( e.g. MPL15 ), then grabs the last four digits as the increment counter. The problem is, this does not take months into account, so unlike the description that says the system is limited to 10,000 items a month, it is limited to 10,000 items per *year*. This situation can easily be corrected my adding the month into the lookup ( e.g. MPL1501 ). -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 13636] New: Search results item status incorrect for holds
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13636 Bug ID: 13636 Summary: Search results item status incorrect for holds Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Imagine this scenario: we have one record with four items. Two of those items are checked out, one of those items is a waiting hold, and one of those items is available. We would expect to see this on the search results page. Instead, we will see both non-checked out items as unavailable due to waiting holds. This is due to a semantic issue GetReserveStatus. C4::Search::searchResults uses GetReserveStatus to get the reserve status of each item, but unlike all other calls to the sub, this one passes in not only itemnumber, but biblionumber. When no reserve is found for the available item, the subroutine uses the biblionumber to grab what is essentially an arbitrary reserve to use for the status. This makes no sense and this functionality should be entirely removed from the subroutine so regressions like this will be prevented in the future. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 1917] Add RSS Feeds for Lists
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1917 --- Comment #20 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 38325 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=38325&action=edit Bug 1917 [QA Followup] - Don't limit the list results for RSS feeds -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 1917] Add RSS Feeds for Lists
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1917 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 1917] Add RSS Feeds for Lists
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1917 --- Comment #19 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Agreed, I think it should be a the full list. (In reply to Katrin Fischer from comment #18) > Hm, I found another thing: The RSS feed will only list the first(?) 20 of a > longer list. I am not sure why this happens and if there is a way to get a > complete list. > > We have a system preference for the search results - numSearchRSSResults - > maybe it should follow that? But I'd kinda expect it to give a full list or > at least have an explanation or a link to get to the full list. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 10975] New: addbiblio.pl checks if marcflavour equals "usmarc"
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '15

22 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10975 Bug ID: 10975 Summary: addbiblio.pl checks if marcflavour equals "usmarc" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: magnus(a)enger.priv.no QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl On line 924 of cataloguing/addbiblio.pl we have this line: $template->param( title => $record->title() ) if ($record ne "-1" && C4::Context->preference('marcflavour') eq "usmarc"); As far as I know, the 'marcflavour' syspref will never, ever be equal to "usmarc". I'm not sure if this has any practical sideeffects, though, I just spotted it while looking for something else. -- You are receiving this mail because: You are watching all bug changes.

1 2