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

[Bug 7441] search results showing wrong branch?
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '16

02 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7441 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #19472|0 |1 is obsolete| | Attachment #19473|0 |1 is obsolete| | Attachment #19474|0 |1 is obsolete| | Attachment #19475|0 |1 is obsolete| | --- Comment #71 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 51963 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51963&action=ed… Bug 7441 - search results showing wrong branch? When you search in the OPAC it shows you the HOME branch on the location in XSLT, but if you click through to the detail page it shows you the CURRENT BRANCH in the holdings table which is very confusing to patrons. I don't know what's the right solution - home or holding branch, but they should be the same in both places for the patron's sake. If you do the same search in the staff client you see the right branch info on the search results and on the detail page. Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Search the catalog, you search should include results with items that have different home and holding libraries. 4) The results should look the same as before the patch 5) Change the system preference OPACResultsLibrary to "current location" 6) Refresh your page of search results 7) The results show now show the holding library instead of the home library -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7441] search results showing wrong branch?
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '16

02 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7441 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14957] Write protecting MARC fields based on source of import
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '16

02 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 --- Comment #12 from Magnus Enger <magnus(a)libriotech.no> --- When you are on the "MARC field permissions" page, "MARC field permissions" is not shown in the left hand menu. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15108] OAI-PMH provider improvements
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '16

02 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15108 --- Comment #16 from Ere Maijala <ere.maijala(a)helsinki.fi> --- It would be great if others could try this out and see if it works for them. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15108] OAI-PMH provider improvements
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '16

02 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15108 Ere Maijala <ere.maijala(a)helsinki.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #44317|0 |1 is obsolete| | Attachment #44318|0 |1 is obsolete| | CC| |ere.maijala(a)helsinki.fi --- Comment #15 from Ere Maijala <ere.maijala(a)helsinki.fi> --- Created attachment 51962 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51962&action=ed… Bug 15108 - OAI-PMH provider improvements This is an initial attempt at improving the OAI-PMH provider (on master branch). The following improvements are included: - Fixed date handling to use UTC as specs require. - Added support for deleted records. - Added support for second precision in time stamps. - Added support for marc21 metadata prefix as recommended in the guidelines (synonym for marcxml). - ListIdentifiers and ListRecords always return records in timestamp order (faster than biblionumber order with the new index). - Improved performance of database queries especially for large collections. - Unified functionality of ListRecords and ListIdentifiers to a common base class. - If items are included in the records, their timestamps are taken into account everywhere so that whichever is the most recent (timestamp of biblioitem or any of its items) is considered the record's timestamp. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14957] Write protecting MARC fields based on source of import
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '16

02 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 --- Comment #11 from Magnus Enger <magnus(a)libriotech.no> --- Never mind me, I was applying the patches on the 3.22.x branch. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14843] Notifications and messages via REST API
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '16

02 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14843 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |veron(a)veron.ch -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14957] Write protecting MARC fields based on source of import
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '16

02 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 --- Comment #10 from Magnus Enger <magnus(a)libriotech.no> --- I am trying to test this, but after applying the patches (and fixing some conflicts), I get this error when I try to do a search, both in the OPAC and the intranet: Can't locate object method "fields" via package "DBI::db" at /home/kohaadmin/kohaclone/C4/Biblio.pm line 2673. Line 2673 looks like this: MARCFIELD: foreach my $field ( $record->fields() ) { I'll try to figure out the problem, but if anyone got any hunches I'm all ears! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14844] Corrupted storable string. When adding/editing an Item, cookie LastCreatedItem might be corrupted.
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '16

02 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14844 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |veron(a)veron.ch --- Comment #3 from Marc Véron <veron(a)veron.ch> --- Maybe the error occurs when the cookie is created (line 479). Just a guess after reading: http://stackoverflow.com/questions/1384702/should-i-use-storable-or-freezet… -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10440] During receipting for any holds attached to items being receipted, to be identified during the receipting process.
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '16

02 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10440 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion --- Comment #10 from Marc Véron <veron(a)veron.ch> --- Findings: - The latest patch attached to this bug does the same as Bug 10472 - It does not do what is advertised in the test plan of the first commit: 1. Create a basket. 2. Create orders under basket and close the basket. 3. Click on Receive shipment button and give the invoice number and shipment date. 4. Click on Receive. If item is on hold one warning message will display "Holds on this title. Please order some more copies." - The first patch does no longer apply, and it seems to be similar to the second patch (does not do what is advertised). - There is a similar Bug 10436 - Identify Holds During receipting that was resolved as duplicate. I set this one to "In Discussion". Maybe the original intention (Warn about holds while receiving) could be go to a new bug? -- You are receiving this mail because: You are watching all bug changes.

1 0