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

Re: [Koha-devel] KOHA 3.14.1 Error
by Owen Leonard 03 Jan '14

03 Jan '14

Replying to the list, since a direct message to me excludes all the other people on the list who might be interested in the conversation. > Here I will try to describe specific steps which will lead us to the error 404 screen; > > 1- First we search for records with multiple items (books or serials, does not matter) > > 2- We open this record we found with multiple items for editing > > 3- We chose "Edit items in batch" option from the "Edit" menu > > 4- We make corrections on the fields under the "Edit item" (For example we change the collection code as "fiction") > > 5- We save this using "Save button" at the bottom, after we are done. > > 6- Just after we save, there will be a button named "Done" available just under the page, and when we click on "Done" we encounter the Error screen. I have just tested this in master and I get the same results. I have filed a bug report: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11475 -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

1 0

KOHA 3.14.1 Error
by Uğur Bulgan 03 Jan '14

03 Jan '14

Happy new year, As S.D.U Central Library we are currently using KOHA 3.10.1 version and we want to upgrade to KOHA 3.14.1 version. Therefore we have built a test server for 3.14.1 version, but we have encountered two errors so far. Error 1: Whenever we want to edit batch materials on KOHA 3.14.1 version, we see that the "source of acquisitions (952$e) field" does not come as pop-as menu while it was coming as a pop-up menu on KOHA 3.10.1 version. Is this some kind of bug? Or one of the new features adds up with the 3.14.1 version? Error 2: While we are editing Batch Materials, when we changed any option then saved, the source screen is coming as usual but then again when we click on "Done" link, we encounter "Error 404" screen. At Koha 3.10.1; The link is: https://koha.sdu.edu.tr/cgi-bin/koha/catalogue/detail.pl?biblionumber=89111 and te page opens with no errors. At Koha 3.14.1; The link is: https://kohat.sdu.edu.tr/cgi-bin/koha/tools/CATALOGUING and it is coming with "Error 404" Ugur BULGAN Suleyman Demirel University TURKEY

2 1

smartmatch unsafe in current perl
by Colin Campbell 02 Jan '14

02 Jan '14

Happy new year folks. People should be aware of this in the perldelta for 5.18: > Smartmatch family of features are now experimental > Smart match, added in v5.10.0 and significantly revised in v5.10.1, > has > been a regular point of complaint. Although there are a number of ways in > which it is useful, it has also proven problematic and confusing for both > users and implementors of Perl. There have been a number > of proposals on > how to best address the problem. It is clear that > smartmatch is almost ecrtainly either going to change or go away in > the future. Relying on its current behavior is not recommended. > > Warnings will now be issued when the parser sees "~~", "given", or "when". > To disable these warnings, you can add this line to the appropriate > scope: > > no if $] >= 5.018, warnings => "experimental::smartmatch"; > > Consider, though, replacing the use of these features, as they may > change behavior again before becoming stable. Compiling and running the current master does generate a number of warnings triggered by these features. It looks as if it would be a wise move to avoid these features in new code. I'll try and look at those occurences and see if they can be addressed by using a less contentious structure. Most of the uses of given/when are syntactic sugar. But there are some uses of the smartmatch operator '~~' in indexing which may be affected by the various changes in behaviour. Incidentally on a make test on perl 5.18.1 a lot of the Quey Parser tests fail, but I havent as yet looked at this. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 800 756 6803 (phone) +44 (0) 7759 633626 (mobile) colin.campbell(a)ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com

1 0

koha-3.00.00 make fails
by Rick Welykochy 28 Dec '13

28 Dec '13

Hi all, I have downloaded http://download.koha.org/koha-3.00.00.tar.gz and began installing it on Debian/etch (in a Linux vserver environment). 0. FINE: cd koha-3.00.00 1. FINE: perl Makefile.PL 2. FAIL: make : : : Manifying blib/man3/C4::UploadedFile.3pm Manifying blib/man3/C4::BackgroundJob.3pm Manifying blib/man3/opac::opac-dictionary.3pm Manifying blib/man3/serials::member-search.3pm /usr/bin/perl "-Iblib/arch" "-Iblib/lib" fix-perl-path.PL blib /usr/bin/perl "-Iblib/arch" "-Iblib/lib" rewrite-config.PL blib/KOHA_CONF_DIR/koha-conf.xml Bad arg length for Socket::inet_ntoa, length is 0, should be 4 at rewrite-config.PL line 67. make: *** [blib/KOHA_CONF_DIR/koha-conf.xml] Error 255 Any ideas what went wrong and how to fix? Aside: there were a couple of other problems with this "out of the box" debian based install of Koha 3.0 which had to be fixed along the way, e.g. seven missing perl modules and libgd not found. I'll report on the entire process from unpacking to a running Koha/3.00.00 once I get to the end. cheers rickw -- ________________________________________________________________ Rick Welykochy || Praxis Services || Internet Driving Instructor The manual said Windows XP/SP2 or better so I installed Linux.

4 5

Re: [Koha-devel] Koha 3.12.x and VIAF
by Stefano Bargioni 26 Dec '13

26 Dec '13

Hi, Partha: thanks for detecting this bug. I'm going to correct the wiki page. In Koha 3.12 please comment out or delete lines // $($('ul.toolbar')[0]).append('\ // <div class="ui-widget" style="margin-top:5px">\ // <label for="viaf">VIAF Autosuggest </label> <span id="viaf_reset" title="reset">[X]</span> <input type="text" style="font-size:0.9em" id="viaf" size="80" title="digitare almeno i primi 3 caratteri di un nome">\ // </div>\ // '); and substitute them with $('#authoritytabs').prepend('\ <div class="ui-widget">\ <label for="viaf">VIAF Autosuggest:</label> <input type="text" style="font-size:0.9em" id="viaf" size="80" title="Please enter three or more characters of a name">\ </div>\ '); BTW, $('#bibliodescriptions').tabs({ active: 1 } ); belongs to the next entry "Change the default view on OPAC detail pages". Bye. Stefano Fridolin SOMERS wrote: > Hie, > > In wiki page, there is a final note : > " > In 3.12 use: > $('#bibliodescriptions').tabs({ active: 1 } ); > " > Did you test this ? > > Le 27/09/2013 13:33, Partha Mukhopadhyay a ?crit : >> Dear all, >> >> The JQuery script >> (http://wiki.koha-community.org/wiki/JQuery_Library#Add_VIAF_autosuggest_for…) >> for integrating Koha with VIAF is not working in Koha 3.12.x (tested from 3.12.1 >> to 3.12.5). >> >> Pl. check.... >

3 2

Sound alerts RFC
by Kyle Hall 20 Dec '13

20 Dec '13

Hey all, We have some partners who would like to have a bit more flexibility when it comes to audio alerts. 1) Have a new "alert" sound for most if not all alerts ( ie yellow alert boxes ), keeping the current sound as the "error" sound. 2) The ability to select new sounds for each of these ( success, alert, error ) I've added my development plan to Bug 11431 - Add additional sound options for warnings. If you have any comments on this idea, please add them! http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11431 http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com )

1 0

Architectural goals for 3.16
by Galen Charlton 20 Dec '13

20 Dec '13

Hi, For discussion, here is a list of some of some things I would like to see in 3.16. This is not meant to be complete; please feel free to use this thread both to comment on my goals and to suggest goals that you're personally willing to advocate for -- and by advocate for, I mean that you and/or the institutions who support your Koha activity are ready and willing to take concrete steps to help implement it. I ask that if all you have is an idea -- no matter how good! -- but not any concrete code or plans to have it be ready in the next few months -- please start a different thread. [1] Deprecation of the GRS-1 mode for Zebra. Reason: the DOM index filter allows greater flexibility for setting up indexing definitions. The DOM filter also offers a path (among other options) towards indexing non-MARC metadata. Obstacles: the default UNIMARC indexing rules for the DOM filter need more testing. There is also an ongoing discussion about the desired semantics for the Any index, which at present behaves differently with the current DOM indexing rules as compared with GRS-1. Upgrade considerations: in order to truly deprecate the GRS-1 filter, at some point there will have to be a forced reindexing upon upgrade. [2] Use DBIx::Class to deploy the database schema for new installations. Reason: Maintaining multiple SQL schema scripts, one for each DBMS we want to support, would be error prone. Making edits to classes under Koha/Schema, then using ->deploy(), offers the possibility of initializing both MySQL and PostgreSQL databases. DBIx::Class::Schema::Versioned could be used at as way of managing schema updates Obstacles: DBIx::Class doesn't automatically know anything about indexes required for good performance; consequently, it will be necessary to write hooks for (at least) MySQL to create the necessary indexes. [3] Relaunch PostgreSQL support Reason: PostgreSQL is a compelling alternative to MySQL, and now that we have DBIx::Class in place, managing the schema for PostgreSQL is now a more reasonable proposition. For 3.16, I propose the following specific goals: - Koha will be installable on a Pg database - A staff user will be able to create or import and bib record and item - A public catalog user will be able to search for and retrieve that item - a reasonable number of the database-dependent tests will pass In other words, I'm not proposing that Pg support be ready for production by 3.16, just that it be just good enough that a developer who wants to improve Pg support isn't starting from nothing. [4] Upgrade the version of Bootstrap we use to 3.x. A new major release of Bootstrap was made recently. Unfortunately, it is not backwards compatible with previous versions (see http://bootply.com/bootstrap-3-migration-guide for a taste of the issues involved). As much as I'm personally not exactly a fan of the changes that were made to the CSS class names, we're much better off if we bite the bullet now and update both staff and OPAC to use the new version of Bootstrap rather than, two years down the road, finding out that we're completely stuck on Boostrap 2.3. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

10 21

ping Koha (developers) community
by Jonathan Druart 19 Dec '13

19 Dec '13

Hi everybody, I have been working on Koha code for 3 years now. And for the last 2 years, I have been implied in the rebase of the BibLibre's patches and in the QA team. Many things have changed during this time. Koha is widely used throughout the world, and some great improvement have been made in the community workflow. However, I feel the need to share with you today my feelings and my frustration about our work methods. As I said, great improvements have been made in the patch integration workflow. Our process of validation and integration of the patches has lead to an improvement of the code. The respect of the basic coding rules - e.g. the indentation - makes the code easier to read and to understand, and then easier to modify. The unit test coverage has been expanded and we can now add new tests easily. It is also more secure to modify a core routine. All of these points are very positive to me: I enjoy developing in these conditions. But in parallel, I encounter difficulties with my patches queue. I try to spend time on every patch, to follow the coding guidelines and to produce clean and readable code, with unit tests. I try to write incremental patches, and understandable test plans (as far as my English level allows me to do...). I also try to QA as soon as I have spare time, and to rebase my patches as fast as possible not to block the signoffers. Concretely, the steps of the integration of a feature from my point of view as developer are: the customer orders a development. I start the development on the master branch (or a previous stable version). After several iterations, the customer agrees on the feature. I rebase the patch on a fresh master branch and I submit the patch in Bugzilla. I iterate with the signoffer and rebase the patch. At this time, the customer expects the feature to be in his production server. I then rebase the feature against his branch. The patch is finally signed after several months and several rebases against the master branch. This will usually need rebase and adjustment for the QA and/or the RM steps. When the customer version will be upgraded to the next release, I will once again adapt the feature - it may have differed from the initial feature. Sorry for this massive paragraph but the workflow is really as heavy as described (and this is the simple version...). The excessive duration of this integration process leads to several problems: - The developer is frustrated by these multiple rebases (trust me, it is really tiresome). - Regressions may be introduced following a badly fixed conflict - The development may need to be fully rewritten. - This is a lost of time not only for the developer, but also for the signoffer and the QAer. - Libraries and librarians may become frustrated too. I do not know how to fix these problems, but I would like to raise some points. The number of patches waiting for QA has decreased. This could be explained by the efforts of the QA team, but also by the decrease of SO patches - and thus by the decrease of patches going into the QA queue. The stack of patches waiting for SO is closed to 200, and my feeling is that the amount of weekly SO has never been so low. 2/3 of theses NSO are enhancements and 60 have been opened prior to 2013. This bottleneck will delay the development of future features. One of the more frustrating thing is to see passed QA patches regress to the does not apply status, because they have been queuing too long at the RM step. It regularly blocks me: I cannot make features for the customers when there are too many dependencies waiting to get pushed to the master branch. Galen, can you explain why there are patches that stay for months in a Passed QA status (26 patches are in passed QA since more than one month, without any activity)? I really would like to see activity on theses patches. I guess it is not always easy to make a decision about some patches - invaliding/rejecting them instead of pushing them. But I think it is better to go ahead or to reject a patch, rather than blocking it without explaining why. Does it mean that you would need help? Module maintainers have been elected for the 3.16 release: what will be exactly their roles? In your 3.14 proposal, you suggest naming master branch committers. Is this idea still topical or did you abandon it? I also have the feeling that the features have been pushed toward the end of the release cycle. Wouldn't it be more secure to push them at the beginning of the cycle, so they are more tested? I spend most of my time rebasing patches, instead of developing new ones or QAing others patches. I worked 40 days in 2013 for the community rebase. This includes the resolution of conflicts and the submission of followups. My time could have been better used. In my opinion, it is not by limiting the amount of pushed patches that we will reach the stability of Koha. Many "actives" patches - i.e. more than currently 600 patches with SO, need SO, Passed QA, in discussion and does not apply status - could fix problems or improve the code. Moreover, some of the submitted features refactor the code and add UT. These features are susceptible to improve the maintenance and the stability of Koha. In my opinion, the main problem is that there are too few active members in the community. The sandboxes have not been used as expected, judging by the low amount of signed patches from sandboxes. Currently most of the testers are not Koha users but rather developers. In France, some universities start to use sandboxes to signoff patches but do not have enough time to do it on a regular basis. Are there such initiatives in the other countries - for example India, Northern African countries, USA,.... ? I have tried regularly to spend personal time to develop improvements for Koha - such as rewriting the authorised values (new module), adding a logging module and rewriting the updatedatabase way. But after respectively 6 months, 1 year and 2 years of rebase, discussion, etc. Nothing happens anymore. My conclusion is sadly that it is not worth anymore investing my free time in Koha. I would like to know if this feeling is shared with other Koha developers or if I am the only one. How do you see the close future of Koha? Would you have any idea on how to improve the workflow? Do you have any idea to lead Koha users to be more implied in the testing process? Freely, Jonathan

9 16

Prices and tax in koha
by BOUIS Sonia 17 Dec '13

17 Dec '13

Hi, I'm a French librarian working at the University Lyon3 and in charge of Koha. I want to know your feelings about the prices processing in koha and the question of the tax. >From 3.10 version, some prices are recalculated according to this tax before they are stocked in the database. It's a pretty good thing but not all the prices are recalculated and there's sometimes a bad calculation : tax is added or subtracted 2 times... Another difficulty is that there's a lot of tables in acquisitions and not all of them works in the same way... So I wonder if a decision about the prices and a correction of all the tables in acquisitions isn't necessary... My suggestion is to stock all the price including tax and to calculate the price in the budget and in all the displaying tables according to the preferences in the vendor. I think, all the scripts of calculation and the template for displaying tables have to be correct. It could be a new goal for koha 3.16 or perhaps for koha 3.18... I'm sorry if my explanations are short and not very clear but I want to know what the community thinks of it. Have a good day Sonia BOUIS ------------------------------------------------------ Responsable du Système intégré de gestion des bibliothèques SERVICE COMMUN DE LA DOCUMENTATION Université Jean Moulin Lyon 3 6 Cours Albert Thomas - B.P. 8242 - 69355 Lyon Cedex 08 ligne directe : +33 (0)4 78 78 79 03 | Fax : +33 (0)4 78 78 79 89 ------------------------------------------------------ http://scd.univ-lyon3.fr<http://scd.univ-lyon3.fr/> L'Université Jean Moulin est membre fondateur de l'Université de Lyon

2 1

Prices and tax in koha
by Paul A 17 Dec '13

17 Dec '13

At 01:43 PM 12/17/2013 +0000, BOUIS Sonia wrote: > >[snip] >My suggestion is to stock all the price including tax I would prefer a "choice" -- maybe it's very specific, but our auditors are clear that for a Canadian charity there are tax implications and we must stock without taxes (historical values are fixed regardless of tax levels [0-13%], without which we would have to do a complete stock take and re-appraisal every year -- for any accountants out there, I'm told this is called "expensing.") >and to calculate the price in the budget and in all the displaying tables >according to the preferences in the vendor. I think, all the scripts of >calculation and the template for displaying tables have to be correct. Consistency is highly desirable... Best - Paul

1 0