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

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

awstats
by Paul A 13 Dec '13

13 Dec '13

Has anyone here got a working version of awstats (v.7) running with Koha on Apache 2.2.x? Specifically (Debian/Ubuntu), the cross referencing of the apache2 .conf files, both LAN and WAN? I'm trying to do some research into mobile/smartphone use -- at a meeting yesterday with BellMobility (not specifically Koha), I was told that they're seeing a 5% per MONTH increase in data loads. This ties in with recent press reports that "mobile" access will surpass "desktops" by 2015 in Canada. Question (prompted? reinforced?) by a couple of off-list emails with Robin S. on the subject of bootstrap in Koha. tnx and br - paul

2 1

3.14.1 in progress
by Fridolin SOMERS 13 Dec '13

13 Dec '13

Hie community ! As RM for 3.14, I start pushing today into 3.14.x. I will release 3.14.1 has planned on 22nd (a Xmas gift). I'm proud to add my stone to the building (translation of "ajouter une pierre à l'édifice"). Best regards, -- Fridolin SOMERS Biblibre - Pôle support fridolin.somers(a)biblibre.com

2 1

Re: [Koha-devel] Architectural goals for 3.16
by Paul A 11 Dec '13

11 Dec '13

At 09:59 AM 12/11/2013 +1300, Liz Rea wrote: >On 11/12/13 05:40, Owen Leonard wrote: > >> [4] Upgrade the version of Bootstrap we use to 3.x. > > As I mentioned in IRC today the primary caveat for this goal is that > > Bootstrap 3 says it "drops support for Internet Explorer 7 and Firefox > > 3.6." However, it doesn't explicitly say what "dropping support" > > means. If it means broken functionality, that is a problem for us. If > > it means graceful degradation, that's more acceptable. I'll be doing > > some investigation, but I think we need some opinions from others > > about what level of support we need to offer for IE7 and FF 3.6. > > > > -- Owen > > >(this is only my opinion, since you asked.) Mine too (and we're "small" so maybe near the bottom end of the relevancy scale.) >IE 7 is only available in Windows XP, which is due to be end of life in >April 2014. First, I really have no opinion on IE 7 thru 10 -- I do read the stats on "market share", and I do have access (for webpage verification purposes) of IE8, but that's it... >Any changes we make for this cycle won't be released until >after XP is EOL. [snip] XP is an outdated, and dangerous operating system >to be >running. We're all entitled to our opinions and I respect yours. However XPPro SP2,[1] properly set up (with a *user* account, never go on-line with admin privileges) is not "dangerous." EOL, maybe, but I feel that Koha is gaining ground in (excuse me if I'm not PC) less developed countries where quite frankly older o/s abound for whatever reasons. Upgrading Koha to deny XP (and I'm not at all sure that's what's being proposed) might be cutting off our noses to spite our face. >It should be noted that it was discovered that bootstrap 3 sites, though >not officially supported in FF 3.6, still seem to look and work OK. For the record, I still have (no time to rebuild) half a dozen "kiosks" that run FF3.6 under Win98SE (despite a whole bunch of misinformation that it's not possible) -- the Koha OPAC is visually perfect (3.8.5 near standard OPAC CSS) and very fast. YMMV. Bottom line: bootstrap 3 is probably the right way to go, and sooner rather than later ... but let's not forget that there are probably hundreds of thousands, if not potentially millions, of KohaOPAC users who are not as "up to date" with their boxes as we might be... Best regards, Paul [1] I have two boxes running XPPro, installed 2001, upgraded SP2 2004 (both running IE8 since 2009). They have never, ever failed in 12 years -- "bullet-proof" is a term that comes to mind. Note that I have never used Vista, Win7 or Win8.

5 6

Re: [Koha-devel] RSS method for checking and warning about current installed version
by Paul A 10 Dec '13

10 Dec '13

At 08:55 PM 12/3/2013 -0200, Tomas Cohen Arazi wrote: >My main concern is people having Koha instances that already reached EOL >and/or are not supported anymore. How to do it is the topic in discussion. >I like the idea of a button (maybe in the form of a tab in the about page >;-) and maybe with a disclamer notice and a confirmation button). Having a >syspref defaulting to "disabled" could work if this is troublesome in >several jurisdictions. I'm referring to professionals who know full well what they are doing with their library systems, we don't need the security implications of any "preference" having external file editing capability. If amateurs need reminding, that's another question that should be available during installation, not afterwards. Look around the landscape: does perl, or apache, or mysql, or zebra, or etc, etc... do this? You say "could work" -- I'm suggesting that security must be bullet proof. As far as I'm concerned, this avenue should be blackballed for a standard install/upgrade. It's just the thin end of the wedge towards other intrusions. Best regards -- Paul >Regards >To+ > > >On Tue, Dec 3, 2013 at 7:46 PM, Paul A ><<mailto:paul.a@navalmarinearchive.com>paul.a(a)navalmarinearchive.com> wrote: >At 07:48 AM 12/4/2013 +1300, Chris Cormack wrote: >>On 4/12/2013 6:38 am, "Tomas Cohen Arazi" >><<mailto:tomascohen@gmail.com>tomascohen(a)gmail.com> wrote: >> > >> > What would you think of adding some way for the >> <http://about.pl>about.pl page to load information on newer versions >> available, or even if the currently used branch has reached EOL? >> > >>I like this idea, assuming it is an opt in option. (and easily switched >>off again too) >>Chris > >TomÃÂ¡s, please tell me that this does NOT involve instances of Koha >attempting, unsupervised, to contact an external website. > >Thanks and best regards, >Paul > >_______________________________________________ >Koha-devel mailing list ><mailto:Koha-devel@lists.koha-community.org>Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : <http://www.koha-community.org/>http://www.koha-community.org/ >git : <http://git.koha-community.org/>http://git.koha-community.org/ >bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/ > > > > >-- >TomÃ¡s Cohen Arazi >ProsecretarÃa de InformÃ¡tica >Universidad Nacional de CÃ³rdoba >â +54 351 4333190 ext 13168 >GPG:Â B76C 6E7C 2D80 551A C765 Â E225 0A27 2EA1 B2F3 C15F

4 4