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

[Bug 8292] New: clicking ignore on hold cancels transfer
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '14

12 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8292 Priority: P5 - low Change sponsored?: --- Bug ID: 8292 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: clicking ignore on hold cancels transfer Severity: major Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Circulation Product: Koha If a title has some holds on it and I check it in at the borrowing library, I got a message telling me about a hold. I clicked "Ignore" on that message. The barcode was not transferred back to the owning library at this point even though it should have been. The barcode still shows as having a Current Location. Notes from Ian on the code inspection: The portion of code that triggers the automatic return home is not called if a hold is found; this makes sense in the case where you're filling the hold, since you'd be transferring to that library instead of the home library. But when you 'ignore', nothing additional happens. The ignore button just makes the confirmation box disappear; not further actions are taken. So the code to do the transfer is never performed, and the item sits at the holdingbranch library. Obviously this is not what people expect. If you're ignoring the hold, you want the checkin to proceed as if the hold had never popped up in the first place, and that means doing a return home if appropriate. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 12435] New: Update MARC21 frameworks to Update No. 18 (April 2014)
by bugzilla-daemon＠bugs.koha-community.org 11 Oct '14

11 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12435 Bug ID: 12435 Summary: Update MARC21 frameworks to Update No. 18 (April 2014) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: bgkriegel(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl "Update No. 18 (April 2014) includes changes resulting from proposals that were considered by the MARC 21 community during January 2014."[1] [1] http://www.loc.gov/marc/bibliographic/bdapndxg.html -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 9967] New: Authorized values are not Plack-compatible
by bugzilla-daemon＠bugs.koha-community.org 11 Oct '14

11 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9967 Bug ID: 9967 Summary: Authorized values are not Plack-compatible Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: jcamins(a)cpbibliography.com If you add or change an authorized value linked to an item field, you will not be able to use your changed authorized value under Plack without resetting the Plack server. Possibly relevant warnings: Subroutine AuthorizedValuesForCategory redefined at /home/jcamins/kohaclone/admin/authorised_values.pl line 31. Subroutine default_form redefined at /home/jcamins/kohaclone/admin/authorised_values.pl line 238. -- You are receiving this mail because: You are watching all bug changes.

1 39

[Bug 7844] New: plack scripts for startup
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '14

10 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7844 Priority: P5 - low Change sponsored?: --- Bug ID: 7844 Assignee: gmcharlt(a)gmail.com Summary: plack scripts for startup QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: dpavlin(a)rot13.org Hardware: All Status: NEW Version: master Component: Command-line Utilities Product: Koha Last missing peace to get started with plack is tooling. http://wiki.koha-community.org/wiki/Plack does provide some information, psgi files and startup scripts should also be part of main repository for easy deployment on sendboxes. -- You are receiving this mail because: You are watching all bug changes.

1 45

[Bug 9328] New: File::Find::Rule should not be a mandatory dependency for installation
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '14

10 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9328 Bug ID: 9328 Summary: File::Find::Rule should not be a mandatory dependency for installation Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: gmcharlt(a)gmail.com File::Find::Rule is introduced as a dependency in the work for bug 7167. However, since it's indirectly invoked via C4::Installer, that module must be present for Makefile.PL to compile during installation. I suggest making a new convention that it be possible to run Makefile.PL without requiring non-core Perl modules. F::F::Rule doesn't introduce functionality that is not available to File::Find, just some (admittedly useful) syntactical sugar, so one possibility would be cutting out that dependency entirely. If that's not preferred, it at least should not be required for Makefile.PL to run. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 9326] New: New database update system suggests running duplicate updates
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '14

10 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9326 Bug ID: 9326 Summary: New database update system suggests running duplicate updates Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: jcamins(a)cpbibliography.com CC: gmcharlt(a)gmail.com Depends on: 7167 When an update has been renamed, the new database update system suggests running the duplicate update, even though when you tell it to go ahead and do that, it informs you that it is a duplicate update. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 6328] New: Fine in days does not work
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '14

10 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6328 Bug #: 6328 Summary: Fine in days does not work Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: paul.poulain(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Some code coming from BibLibre has been lost in the process of inclusion in 3.4. The result is that fine in days does not work at all (you can setup rules, but it does nothing) Step to reproduce: Koha > Admin > circ rules > set 1 day fine every day of overdue for default rule Issue a book return date last week check-in the book => no debarment is set The following patch will fix all of those problems by : * updating borrowers.debarred to a date field (instead of tinyint). It contains the limit of the debarment * changing API of DebarMember and UpdateBorrowerDebarred to pass a date * display debarrdate where applicable. Note that a debarrdate of 31/12/9999 is considered as unlimited and not displayed * added a debarrcomment, usefull to explain why a patron is debarred (this is independant from debarrdate changes and can be used when placing an unlimited debarment too) -- 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 64

[Bug 6190] New: Custom field removal from patron entry screens
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '14

10 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6190 Bug #: 6190 Summary: Custom field removal from patron entry screens Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: srdjan(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Implement a mechanism for removing unwanted fields from the entry screens. It will be a syspref, BorrowerUnwantedField, that will have the same format as BorrowerMandatoryField -- 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 54

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