October 2014 - Koha-bugs - lists.koha-community.org

[Bug 7167] New: updatedatabase improvements
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '14

10 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167 Bug #: 7167 Summary: updatedatabase improvements Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: paul.poulain(a)biblibre.com ReportedBy: paul.poulain(a)biblibre.com QAContact: ian.walls(a)bywatersolutions.com During the hackfest in Mumbaï, 5 of us had a brainstorming about database changes to try to improve it. Here are the goals: * must result in patches being easier to test by testers (to sign-off) * must result in less conflict when trying to apply a patch with a DB update when another patch has been applied (the .XXXX problem) * must fix the linear problem (where patches are applied in a completly linear way) * be easy to implement We throwed many ideas, here is the one that seems both easy and usefull : * patches would be submitted in a specific file, in atomicupdate directory * a new file (YAML) would be added, that would have 2 columns, one for the version number, one for the atomicupdate file name * updatedatabase wouldn't change anymore: we would just add something like : LoadYAMLFile() ForEachLine { if (C4::Context->preference("Version") < FirstColumnYAML) { exec(secondColumnYAML); SetVersion (FirstColumnYAML); } } The YAML file would be updated only by the Release Manager, when he pushes a patch. This idea fully achieve most of our initial goals: * (very) easy to implement * it will be easier to test a patch : is there an atomic update in the patch ? OK, to test it, i'll first execute the file * there won't be any conflict anymore of a patch applied and your .XXXX file not applying anymore, needing a rebase * it fixes partially the linear problem = if you have a local branch, you can see what has been applied just looking in the yaml file. Let's say Limoges library has sponsored stuff that has resulted in atomicupdate/limogeupdate.pl Those changes are live in Limoges, but still not in official/community version. The Limoges YAML file will be: 3.07.0001 Community_change1.pl 3.07.0002 community_change2.pl localchange limogesupdate.pl 3.07.0003 community_change3.pl the "localchange" in first column will mean for the updater : "OK, apply the change but don't change the version number" When the localchange has been applied on master community branch, the official/community YAML file will look like: 3.07.0001 Community_change1.pl 3.07.0002 community_change2.pl 3.07.0003 community_change3.pl 3.07.0004 limogesupdate.pl Switching back limoges to a community version would require some manual checking, but that will be *much* easier than what we have today : * diff limoges.yaml official.yaml * apply community changes if/where needed * UPDATE systempreferences SET kohaversion=3.07.0004 manually It's done ! And if the localchange that has been made is never merged into master, whatever the reason, it will be easier to keep track of it too. And if you want to apply a submitted patch to your local setup before it's pushed onto master, you can, just by running the file in atomicupdate directory. And add a "localchange" line to your YAML file to remember the change you've made. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 308

[Bug 13059] New: tab order on add/edit item isn't right
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '14

10 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13059 Bug ID: 13059 Summary: tab order on add/edit item isn't right Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The tab order on the edit item screen skips the add item button and goes up to the catalog search box, then the search submit button and then to the add item button after tabbing out of public note. It should go public note, add item, add and duplicate, add multiple, and then back to the search box at the top. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 13063] New: 111n display wrong in opac
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '14

10 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13063 Bug ID: 13063 Summary: 111n display wrong in opac Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 32118 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=32118&action=edit opac Attached are screenshots from the staff and the OPAC. The staff client is showing things right, but the OPAC isn't. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 12755] New: MARC Preview doesn't always display in managed MARC record
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '14

10 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12755 Bug ID: 12755 Summary: MARC Preview doesn't always display in managed MARC record Change sponsored?: --- Product: Koha Version: 3.16 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: gmcharlt(a)gmail.com Reporter: eb(a)efdss.org QA Contact: testopia(a)bugs.koha-community.org In Manage MARC records If I try to look at an individual record, the popup MARC preview window doesn't appear. This is where it doesn't appear: Using Google Chrome on a Mac running OS X (10.9.4) Using Firefox on a Mac running OS X (10.9.4) Using Google Chrome on Windows 7 Using Firefox on Windows 7 The bottom left hand box on the screen says Javascript:void(0) But: It works as expected running Google Chrome on a virtual machine (Windows XP, yeah, I know). I have disabled all the extensions, thinking one of them might have been blocking it, but it still doesn't work in the Managed staged records. The MARC preview popup box works fine in the Z39.50 search In response to my question on the list Owen Leonard wrote: "I have seen this problem in Windows (7) with Firefox and have confirmed that it still exists in master. There is a JavaScript error: TypeError: $(...).html(...).dialog is not a function /cgi-bin/koha/tools/manage-marc-import.pl?import_batch_id=XX Line 226 I'm guessing this problem was introduced by Bug 10558 - Convert records table in manage-marc-import.pl to Ajax DataTable" -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 643] Allow override of 'debarred' status
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '14

09 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=643 --- Comment #22 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Created attachment 32122 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=32122&action=edit [PASSED QA] Bug 643: QA Followup - server-side verification of permissions Only allow $force_allow=1 if the logged in user has permissions. TEST PLAN --------- Attempt to intentionally override the checkout by passing an appropriately handcrafted URL. -- Regardless of the force_allow value, it should be not allowed for those lacking the force_checkout permission. NOTE: I didn't test this. I figured Marc Veron could do that. :) (Sorry, couldn't easily get git bz to work with the accent) Signed-off-by: Nick Clemens <nick(a)quecheelibrary.org> Signed-off-by: Katrin Fischer <Katrin.Fischer.83(a)web.de> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 643] Allow override of 'debarred' status
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '14

09 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=643 --- Comment #21 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Created attachment 32121 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=32121&action=edit [PASSED QA] Bug 643: Followup: Display override button only if issuing staff member has force_checkout permission To test: Apply first patch Apply this patch Log in as superlibrarian Go to Home > Patrons > Set permissions for issuing staff member Disable circulate - force_checkout Log in as issuing staff member Try to checkout to a debarred patron => should not be possible Log in again as superlibrarian Enable circulate - force_checkout for issuing staff member Log in as issuing staff_member Try to checkout to a debarred person => You should get the button 'Override debarment temporarily' Signed-off-by: Aleisha <aleishaamohia(a)hotmail.com> Signed-off-by: Nick Clemens <nick(a)quecheelibrary.org> Signed-off-by: Katrin Fischer <Katrin.Fischer.83(a)web.de> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 643] Allow override of 'debarred' status
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '14

09 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=643 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #31997|0 |1 is obsolete| | Attachment #31998|0 |1 is obsolete| | Attachment #31999|0 |1 is obsolete| | --- Comment #20 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Created attachment 32120 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=32120&action=edit [PASSED QA] Bug 643: Allow override of 'debarred' status Add a button to temporarily override patron debarment. To test: 1) Go to patron check out page 2) If patron has been debarred (eg. due to having fees), there is no way to check out to that patron. 3) Apply patch 4) A debarred patron check out page now has a button for "Override debarment temporarily" - clicking on it should allow checking out to that patron. Signed-off-by: Aleisha <aleishaamohia(a)hotmail.com> Rebased because patch did not apply Signed-off-by: Aleisha <aleishaamohia(a)hotmail.com> Signed-off-by: Nick Clemens <nick(a)quecheelibrary.org> Signed-off-by: Katrin Fischer <Katrin.Fischer.83(a)web.de> Tested with/without force_checkout and superlibrarian permission. Also checked crafting a URL is no longer working. No regressions found. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 643] Allow override of 'debarred' status
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '14

09 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=643 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8451] New: Confusing and problematic double prompt for processing transfers
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '14

09 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8451 Priority: P5 - low Change sponsored?: --- Bug ID: 8451 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Confusing and problematic double prompt for processing transfers Severity: minor Classification: Unclassified OS: All Reporter: dcook(a)prosentient.com.au Hardware: All Status: NEW Version: master Component: Hold requests Product: Koha Created attachment 10865 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=10865&action=edit Screenshot of double prompt - two options The following occurs after cancelling a hold on Holds Awaiting Pickup and being prompted that the item needs to be transferred to another library for the next person in the holds queue: First, the item status on the intranet detail screen says that the item is in transit, even though the request.pl/Holds screen does not register a tranfer! Second, when checking in a hold to be transferred (at least as a superlibrarian), the user is confronted with two prompts: 1) Please return <<item>> to <<transfer branch>>. Print slip or cancel transfer. Hold for <<patron>> Confirm. 2) Hold found <<item>>. Hold for <<patron>>. Confirm hold and transfer. If Option 1 is chosen, the <<transfer branch>> name is removed from the item status on the intranet detail screen. Other than that, nothing happens. If you try to check in again from the homebranch, you're prompted with the previous two options again. If you try to check in from the transfer branch, it requests that you transfer it to the transfer branch (which is quite bizarre). If Option 2 is chosen, the request.pl screen reflects the correct state of affairs. However, if you've chosen Option 1 first and then Option 2, when you change to the transfer branch, you're prompted with 2 similar options again! Option 1: Please return <<item>> to <<transfer branch>> (even though you're checking in to the transfer branch!!!) Option 2: Hold found. Confirm hold at <<transfer branch>> At this point, you're stuck in a loop. Regardless of the choice that you make, you CANNOT process the hold. You have to cancel the hold and start all over again. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 4319] waiting items cannot be reserved
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '14

09 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4319 --- Comment #23 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Thx for the comment Nicole! -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0