- Koha-devel - lists.koha-community.org

Bug 7430 and NoZebra
by tajoli＠cilea.it 19 Mar '12

19 Mar '12

Hi to all, here at HackFest I'm working on bug 7430, to commit it into master and so for 3.8.0 This patch was written from Jared Camins-Esakov This patch entirely removes portions of the NoZebra code. As I know now 'NoZebra' mode is not working now in 3.6.x We need to write in documentation and setup that for 3.8 the only Serch Engine for Koha is Zebra. Cheers Zeno Tajoli

1 0

User configurable slips pushed (bug 7001, call for more testing)
by Paul Poulain 19 Mar '12

19 Mar '12

Hello all, I just pushed bug 7001: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7001 It contains a great enhancement that has been tested by many people, and resulted in a long long comments thread and fixes/changes. In a few word: * notices can now be in HTML format (not only txt) * notices can be associated to a branch (with a default notice) * the CSS, in case of html, are defined in a syspref (NoticeCSS and SlipCSS) BUT, as it touches a lot of files, I call here for more testing by more people ! Some usefull comments: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7001#c0 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7001#c60 (additional notes section) http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7001#c77 (additional notes section) The list of files updated: C4/Circulation.pm C4/Letters.pm C4/Members.pm C4/Members/Attributes.pm C4/Message.pm C4/Print.pm C4/Reserves.pm C4/Suggestions.pm acqui/booksellers.pl circ/circulation.pl circ/hold-transfer-slip.pl circ/transfer-slip.pl members/memberentry.pl members/moremember.pl members/printslip.pl misc/cronjobs/advance_notices.pl misc/cronjobs/gather_print_notices.pl misc/cronjobs/overdue_notices.pl (+ many templates, SQL default loadable data and updatedatabase) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

8 19

Bugzilla problem and a plea
by Jared Camins-Esakov 17 Mar '12

17 Mar '12

Good morning. Those of you subscribed to koha-bugs may notice something surprising in your inbox today- a message that seems to indicate that a number of bugs that still exist (such as bug 6875) have been resolved. When, in shock, you go to look at the bug report and find out how this could be, you will see that the status remains unchanged. There seems to be an issue with dependencies in Bugzilla where the part of the message that says "This bug depends on another bug, bug XXXX which changed state to..." is missing. Just a heads-up on that, because it's a little disconcerting to see "RESOLVED--FIXED" in an e-mail about a bug that you *know* isn't resolved. That was the problem. My plea is this: if you see any bug reports (such as reports that you filed yourself) that have a status of Pushed to Stable or Pushed to Master (depending which is the final destination for the patch), please test the bug, and, if it's fixed, mark it resolved. We have more than 500 bugs with a pushed status, and most of the are probably no longer issues. It would be nice to tidy up Bugzilla a bit and get the bugs that are resolved off the "open bugs" list. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins(a)cpbibliography.com (web) http://www.cpbibliography.com/

1 0

Fwd: [Koha] rebooting git.koha-community.org and manual.bywatersolutions.com
by Chris Nighswonger 15 Mar '12

15 Mar '12

Forwarding to the devel list also... ---------- Forwarded message ---------- From: Melia Meggs <melia(a)bywatersolutions.com> Date: Thu, Mar 15, 2012 at 2:57 PM Subject: [Koha] rebooting git.koha-community.org and manual.bywatersolutions.com To: koha(a)lists.katipo.co.nz Hello Koha community, We are undergoing some mandatory cloud maintenance and need to reboot a couple of servers that are being used by the community, specifically git.koha-community.org and manual.bywatersolutions.com. We wanted to give you advance notice that we will be rebooting these servers on Friday, March 16 at midnight EST, and we hope this doesn't cause you any inconvenience. Thank you, Melia -- Melia Meggs Chief Operations Officer ByWater Solutions bywatersolutions.com _______________________________________________ Koha mailing list http://koha-community.org Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

1 0

rebooting git.koha-community.org and manual.bywatersolutions.com
by Melia Meggs 15 Mar '12

15 Mar '12

Hello Koha community, We are undergoing some mandatory cloud maintenance and need to reboot a couple of servers that are being used by the community, specifically git.koha-community.org and manual.bywatersolutions.com. We wanted to give you advance notice that we will be rebooting these servers on Friday, March 16 at midnight EST, and we hope this doesn't cause you any inconvenience. Thank you, Melia -- Melia Meggs Chief Operations Officer ByWater Solutions bywatersolutions.com

1 0

Acquisitions, safe to modify a basket's booksellerid?
by Kyle Hall 15 Mar '12

15 Mar '12

Hello all, I have a librarian who would like to have the ability to modify a basket's booksellerid in the Acquisitions module. They want to be able to do this because they frequently have to change vendors after beginning the initial ordering process. I don't feel I'm am very knowledgeable about this module, and was hoping to get some opinions on whether adding this feature would be safe, or would it cause problems. Thanks, Kyle

2 1

Koha 3.8 release schedule & perltidy process
by Paul Poulain 12 Mar '12

12 Mar '12

Hello koha-devel, I just updated the 3.8 release process with the schedule/planning of the release: http://wiki.koha-community.org/wiki/Roadmap_to_3.8 Here it is: March, 23th (1 month before the release) = feature freeze. April, 6th = strong feature freeze, string freeze April 20th = starting release process, everything frozen April 23th = release of Koha 3.8.0 IMPORTANT = perltidy process In january IRC meeting we spoke of perltidy thing. We have a coding guideline rule that says code must be perltidied. However, all the existing code is not perltidied, and it's hard to mix perltidied and non perltidied code. Thus, we have investigated the idea of doing a "perltidy big-bang" just when releasing 3.8.0, for all the code. Pro: * the code will be perltidied, the coding guideline will be applicable * all perltidy being made at the same time, it will be easier to read the git log. (One of the argument against perltidying is that it's a problem for reading git history) * doing that for a release is better for future bugfixes means that patches will apply on 3.8 as well as on master. Cons: * patches that are waiting may become "does not apply" because of the perltidy thing * patches submitted to fix bugs in 3.8 may not apply on 3.6 easily, that will add more work for 3.6 releases. All in one, our conclusion was that the best solution is to do that during a release process. So I plan do it during 3.8 release. (I have a (small ?) question about that : do you think I should make only one huge commit with perltidy ? one for each directory ? one for each file ?) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

13 19

Re: [Koha-devel] Koha 3.8 release schedule & perltidy process -- more time?
by savitra sirohi 10 Mar '12

10 Mar '12

Hi Paul, we have been caught off-guard by this schedule. We have a lot of stuff to submit but March 23rd is too little time. If we have 2 more weeks, we can get good stuff included. Possible? Thanks, Savitra Sirohi Nucsoft OSS Labs http://www.osslabs.biz On Thu, Mar 8, 2012 at 6:29 PM, Paul Poulain <paul.poulain(a)biblibre.com>wrote: > Hello koha-devel, > > I just updated the 3.8 release process with the schedule/planning of the > release: http://wiki.koha-community.org/wiki/Roadmap_to_3.8 > > Here it is: > March, 23th (1 month before the release) = feature freeze. > April, 6th = strong feature freeze, string freeze > April 20th = starting release process, everything frozen > April 23th = release of Koha 3.8.0 > > IMPORTANT = perltidy process > > In january IRC meeting we spoke of perltidy thing. We have a coding > guideline rule that says code must be perltidied. However, all the > existing code is not perltidied, and it's hard to mix perltidied and non > perltidied code. > Thus, we have investigated the idea of doing a "perltidy big-bang" just > when releasing 3.8.0, for all the code. > > Pro: > * the code will be perltidied, the coding guideline will be applicable > * all perltidy being made at the same time, it will be easier to read > the git log. (One of the argument against perltidying is that it's a > problem for reading git history) > * doing that for a release is better for future bugfixes means that > patches will apply on 3.8 as well as on master. > > Cons: > * patches that are waiting may become "does not apply" because of the > perltidy thing > * patches submitted to fix bugs in 3.8 may not apply on 3.6 easily, that > will add more work for 3.6 releases. > > All in one, our conclusion was that the best solution is to do that > during a release process. > So I plan do it during 3.8 release. > > (I have a (small ?) question about that : do you think I should make > only one huge commit with perltidy ? one for each directory ? one for > each file ?) > > -- > Paul POULAIN > http://www.biblibre.com > Expert en Logiciels Libres pour l'info-doc > Tel : (33) 4 91 81 35 08 > _______________________________________________ > Koha-devel mailing list > Koha-devel(a)lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Thanks, Savitra Sirohi Nucsoft OSS Labs Professional Support for Open Source Software Ph: +91 89718 06111 Web: http://www.osslabs.biz

2 2

Mobile friendly OPAC
by Marc Boivin 09 Mar '12

09 Mar '12

Hi all, We've been working a mobile friendly OPAC, you can find it here https://dev3.koha.sys-tech.net/ (please be gently it's a development server, very little resources). I did not want to post it on en general list, because the server can't handle much. To test it, either use a mobile device or, in a modern browser, shrink the width of your window till around 700 pixels. What we've done, using CSS Media Queries, is: * Remove as much noise as possible to focus on simple search and record consulting. * Simplified the advance research, only reachable if there is no search results * Reformatted opac-detail Next thing on our list is user login, we hope to have it done by the end of next week. We would like to give this feature back to the community. But first I'd like to get input on what would be nice, what's missing, what you generally think of the idea. TIA, Marc Marc Boivin Chargé de projet Web 418 520-0739, poste 169 marc.boivin(a)libeo.com Libéo / Web et applications libres 6700, boulevard Pierre-Bertrand, bureau 209 Québec (Québec) G2J 0B4 S. F. : 1 877 969-8324 Téléc. : 418 520-4554 www.libeo.com Aimez-nous sur Facebook : www.facebook.com/libeocom

1 0

Rebasing Solr devs at Hackfest
by Claire Hernandez 09 Mar '12

09 Mar '12

Hello, Just to say I'm eager to do things for Solr integration in Koha community version during Hackfest in Marseille in 10 days! There are 5 full days, I am not alone so we can start something usefull. I would like to know who is interested to test things, give feedback to move forward this week (and after). I already have some names ;) Feel free to write me to explain your vision (or encourage us :), give tips, offer help etc.! Thanks! Claire.

1 0