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

[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

[Bug 7712] New: a single holds report
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '14

08 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7712 Priority: P5 - low Change sponsored?: --- Bug ID: 7712 CC: gmcharlt(a)gmail.com Assignee: koha.sekjal(a)gmail.com Summary: a single holds report QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: melia(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Hold requests Product: Koha Koha currently has two holds reports: Holds to Pull and Holds Queue. The difference between them is often unclear and confusing. The system shall provide a single report page to detail which materials should be pulled from a branches shelves, and where these items should be sent. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 7711] New: clear holds statuses and workflow
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '14

08 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7711 Priority: P5 - low Change sponsored?: --- Bug ID: 7711 CC: gmcharlt(a)gmail.com Assignee: koha.sekjal(a)gmail.com Summary: clear holds statuses and workflow QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: melia(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Hold requests Product: Koha Created attachment 8197 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8197&action=edit Status Workflow Mapping Clear statuses For each hold in the system, there should be a clear, single status to describe it's current state. These statuses should include: Waiting (in holds queue) Ready to pull Pulled and awaiting pickup Filled Expired Long waiting In transit Suspended Canceled Since these statuses have concrete system states attached to them, they must be hard coded into the system. The use of an Authorized Value list would not be sufficient. Status Workflow Not every status should be reachable from every other status. Attached is a mapping of which statuses a hold shall be able change between. O with a green background indicates possible, while X with a red background indicates impossible. Grey cells are for self-references. [Please see attachment.] Holds shall be considered 'waiting in queue' until they reach the top position of the queue, at which time they change to 'ready to pull'. While in the queue, they can expire, be suspended, or be canceled. Once the hold is ready to pull, the next natural next step for the hold to transition to the “Pulled” state, where it awaits being picked up by the patron. Since this status just means the hold is at the top of the queue, if the queue is rearranged, the status of the hold could go back to 'Waiting in queue'. The hold can also expire, be suspended or be canceled. After the hold is pulled, it should either be picked up by the patron and marked as 'filled', or put 'in transit' to the pick up location. It can also still expire or be canceled. If the hold waits to be picked up for more than appropriate MaxReservePickupDelay circ rule, it will be marked as 'long waiting'. If a hold needs to be transferred to another branch, the status shall go from 'Ready to Pull' to 'In Transit'. Once the item arrives at it's destination and is received, it shall be marked as 'Pulled and ready for pickup' Expired, Suspended and Canceled holds can be brought back into the queue. “Filled” is a terminal status; the hold record can now be archived. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 6891] New: LDIF interoperability - a proposal
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '14

08 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6891 Bug #: 6891 Summary: LDIF interoperability - a proposal Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: xan(a)biblionix.com QAContact: koha-bugs(a)lists.koha-community.org Hello Koha Community, I'm Xan Charbonnet with Biblionix. We're a small company that provides a hosted ILS, Apollo, to small and medium-sized public libraries in the US. We're not open-source, but we do strongly believe in open interchange: library data belongs to libraries, and shouldn't be used as a hostage to keep libraries chained to their automation systems. Far too many systems do treat their customers this way. There are even Koha consortia which are charging their librarians multi-thousand dollar extraction fees just to get their own data out! We've developed what we call LDIF (library data interchange format), which is a W3C XML Schema that defines a way for library data to be stored and exchanged in a vendor-independent manner. We believe this is an important capability which has been missing in the library world. Any Apollo library is able to generate an LDIF file at any time, and download (practically) everything that Apollo knows about their library in a single, well-defined file, complete with the schema. Ideally, that file would be easily importable into any other ILS. Part of making LDIF "real", of course, is engaging other ILS vendors. The Koha Community seemed like the place to start. Is there anyone working on the Koha project who would have an interest in developing support for this fledgling standard? And of course, in working with you, there will likely be changes to be made to LDIF, which will make it better for everyone. LDIF Schema: http://www.biblionix.com/ldif.xsd Example library export (I recommend that you download this rather than view it in your browser; it's a 4MB XML file): http://www.biblionix.com/demolibrary_2011-09-20.xml -- 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 26

[Bug 7611] New: Show the NOT_LOAN authorised values for item status in XSLT OPAC search results.
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '14

07 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7611 Bug #: 7611 Summary: Show the NOT_LOAN authorised values for item status in XSLT OPAC search results. Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: fcapovilla(a)live.ca QAContact: koha.sekjal(a)gmail.com Created attachment 7905 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=7905 XSLT Results template improvement : Use the NOT_LOAN authorised values Improvement : Use the NOT_LOAN authorised values when showing items status in the OPAC search results. Before this patch, these items were only considered as "unavailable". Note : This patch only affects the OPAC XSLT search results template for MARC21 records. This patch was not tested on UNIMARC or NORMARC records. I won't be able to support these formats, so I'm hoping someone could do the same for these other record formats. Patch attached. -- 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 7

[Bug 6748] New: Add link to fast add framework while circulating, if a barcode is not found
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '14

02 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6748 Bug #: 6748 Summary: Add link to fast add framework while circulating, if a barcode is not found Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Work To Be Done: * Add a button to the "unknown barcode" message in checkout that would bring the user to the Fast Add Framework (for consistency with the rest of Koha) o Automatically populate the barcode with the value scanned o Automatically populate the homebranch and holdingbranch with the currently logged in branch o Automatically populate the non public note to say “return the item to cataloging” * Upon save, the item will automatically be checked out the patron. How to test: * Scan a barcode that is not in your system in the check out screen * Confirm that the behavior follows the above -- 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 12

[Bug 6858] New: Adds staticfines.pl for static fines processing
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '14

01 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6858 Bug #: 6858 Summary: Adds staticfines.pl for static fines processing Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: matthias.meusburger(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Add a tool to calculate static fine. For example, 7 days left = 1€ fixed fine -- 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 39

[Bug 6809] New: Add branch filter in holds to pull report
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '14

30 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6809 Bug #: 6809 Summary: Add branch filter in holds to pull report Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Hold requests AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: savitra.sirohi(a)osslabs.biz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Currently only date filters available, add branch filter. -- 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 5