February 2012 - 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 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

[Bug 5598] New: More Granular Cloning Circulation & Fine Rules
by bugzilla-daemon＠bugs.koha-community.org 25 Sep '14

25 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5598 Summary: More Granular Cloning Circulation & Fine Rules Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: System Administration AssignedTo: paul.poulain(a)biblibre.com ReportedBy: helen.linda(a)goddard.edu QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 Currently Koha only allows cloning of rules at the library/branch level. There should be an ability to clone rules on patron categories. That way, if you have multiple patron categories, but many of them share a rule regarding an item type, you could write the rule for the one patron type, then select "Clone to" and be able to multi-select the other patron categories to which that rule also applies. -- 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 2

[Bug 6711] New: 'No more renewals' message has empty pull down
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '14

24 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6711 Bug #: 6711 Summary: 'No more renewals' message has empty pull down Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All URL: /cgi-bin/koha/circ/circulation.pl OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: katrin.fischer(a)bsz-bw.de QAContact: koha-bugs(a)lists.koha-community.org Created attachment 4972 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=4972 screenshot To reproduce: - check out a book - renew as long as possible - check barcode out again (that's how I ran into it) -- 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 6

[Bug 7304] New: Working on funds ergonomic display and funds management by multi librarians
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '14

18 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7304 Bug #: 7304 Summary: Working on funds ergonomic display and funds management by multi librarians Classification: Unclassified Change sponsored?: Sponsored Product: Koha Version: rel_3_8 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions AssignedTo: claire.hernandez(a)biblibre.com ReportedBy: claire.hernandez(a)biblibre.com QAContact: ian.walls(a)bywatersolutions.com Blocks: 7163 "* aqbudgets.pl displays funds the librarians can use. There is a « show all funds » check box to access every funds. * on the fund level, you can define owner, users and/or library and then restrict access to : none of these or to the owner only or to the ower + users o to the ower + users + librarians from a specific library. We based the restriction on the library a librarian is connected to. These restrictions take effect on : acqui/acqui-home.pl acqui/booksellers.pl acqui/lateorders.pl acqui/neworderempty.pl acqui/parcel.pl admin/aqbudgets.pl admin/aqplan.pl" (BibLibre MT5557) -- 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 28

[Bug 4861] New: Debian packaging does not include translations
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '14

17 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4861 Summary: Debian packaging does not include translations Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Packaging AssignedTo: lars(a)catalyst.net.nz ReportedBy: lars(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 The Debian packaging of Koha does not include translations. It should include translations at least for all the languages that are 50+% translated. Since OPAC users (especially) may be wanting to use their own language, the translations should be included in the koha-common.deb package. -- 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 9