From nengard at gmail.com Sat Nov 1 00:51:47 2014 From: nengard at gmail.com (Nicole Engard) Date: Fri, 31 Oct 2014 18:51:47 -0500 Subject: [Koha-devel] [Koha] Question about cover images In-Reply-To: References: Message-ID: Tim, I put this in the opacusercss: /* Hide the no image found image */ .no-image { display: none !important; } It hides that image so that you don't have that problem. Nicole On Fri, Oct 31, 2014 at 3:50 PM, Tim Skeers wrote: > We are running 3.16.03.000 > > > > There is a default thumbnail on bib records with no cover images that says "no cover image available." When I upload cover images, the uploaded one appears, but the "no cover image available" one is still there, right below it, in both the public and staff interface. I am checking the option box to "replace existing covers." Any ideas how to get rid of this default filler image? > > > > Thanks, > > > > Tim > > > > Timothy Skeers | Cataloger | Iowa Library Services/State Library of Iowa | 1112 E. Grand Avenue | Des Moines, Iowa | 50319 | tim.skeers at lib.state.ia.us | (515) 725-0605 > > > > > > _______________________________________________ > Koha mailing list http://koha-community.org > Koha at lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha From martin.renvoize at ptfs-europe.com Tue Nov 4 10:25:36 2014 From: martin.renvoize at ptfs-europe.com (Renvoize, Martin) Date: Tue, 4 Nov 2014 09:25:36 +0000 Subject: [Koha-devel] Proposed addition to the development-meetings: In-Reply-To: <54461320.7090902@biblibre.com> References: <809BE39CD64BFD4EB9036172EBCCFA31423E593F@S-MAIL-1B.rijksmuseum.intra> <809BE39CD64BFD4EB9036172EBCCFA31423E5953@S-MAIL-1B.rijksmuseum.intra> <54461320.7090902@biblibre.com> Message-ID: +1, I've been feelng we need 'deadlines for decisions' fro some time now and have voiced it a few times to various people. Great to hear your intent on stepping up to the post in the leading of such discussions Brendan :) Martin Renvoize Software Engineer, PTFS Europe Ltd Content Management and Library Solutions Skype: Landline: 0203 286 8685 Mobile: 07725985636 http://www.ptfs-europe.com On 21 October 2014 09:02, Paul Poulain wrote: > Le 14/10/2014 17:27, Brendan Gallagher a ?crit : > >> Hello Marcel - >> >> I feel that some things that are put into discussion just take too long >> to get out of discussion or don't really ever get any feedback. So the >> idea is that I'll bring these up at Dev-meetings so we get some movement >> on them. The example I used was the DBIC - we've been talking about >> this for a few years now and I think it's time we all vote and decide on >> the correct path forward. That is it - nothing more complicated than >> that. >> > I think that the problem comes from the fact that TIMTOWTDI. ie: there is > not "one correct path". > We should give deadlines for proposals and POC, then call for a vote, and > once we've voted, let's do it like this. There's probably another way to do > it, probably a better way according to someone, but it's the way we've > decided to go, that's it. And the ones who will do it should have a big > voice (in french we say something like "persuaders are not paying", to > express that it's easy to say what to do when you don't have to do it > yourself ;-) ) > > > -- > Paul Poulain, Associ?-g?rant / co-owner > BibLibre, expert du logiciel libre pour les biblioth?ques > BibLibre, Open Source software for libraries expert > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Wed Nov 5 14:39:20 2014 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 5 Nov 2014 13:39:20 +0000 Subject: [Koha-devel] UNIMARC plugin bug Message-ID: <809BE39CD64BFD4EB9036172EBCCFA314240C621@S-MAIL-1B.rijksmuseum.intra> Hi, Any UNIMARC developer out there (in France?) willing to test this small bug: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13203 Thanks, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at biblibre.com Wed Nov 5 15:26:22 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Wed, 5 Nov 2014 15:26:22 +0100 Subject: [Koha-devel] UNIMARC plugin bug In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA314240C621@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA314240C621@S-MAIL-1B.rijksmuseum.intra> Message-ID: Marcel, Thanks, I will do it. Cheers, Jonathan 2014-11-05 14:39 GMT+01:00 Marcel de Rooy : > Hi, > > > > Any UNIMARC developer out there (in France?) willing to test this small bug: > > > > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13203 > > > > Thanks, > > Marcel > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ From kohanews at gmail.com Wed Nov 5 20:25:27 2014 From: kohanews at gmail.com (Koha News) Date: Wed, 05 Nov 2014 11:25:27 -0800 Subject: [Koha-devel] Koha Community Newsletter: October 2014 Message-ID: <545A79A7.80301@gmail.com> Fellow Koha users: The Koha Community Newsletter for October 2014 is here: http://koha-community.org/koha-community-newsletter-october-2014/ Many thanks to the folks who submitted articles and news to this month's newsletter. Please feel free to email us with any corrections or suggestions. Thanks! Chad Roseburg Joanne Dillon Editors, Koha Community Newsletter From vanoudt at gmail.com Thu Nov 6 07:34:20 2014 From: vanoudt at gmail.com (Nicholas van Rheede van Oudtshoorn) Date: Thu, 6 Nov 2014 14:34:20 +0800 Subject: [Koha-devel] Fwd: RDA records In-Reply-To: <5451B19E.4070205@pbc.wa.edu.au> References: <5451B19E.4070205@pbc.wa.edu.au> Message-ID: Hi all, Got this from our librarian the other day, and wondered if anyone could shed any light on this. We've got an RDA framework, and basically it won't save any modifications to the items. New items are added fine, but existing one's just silently don't make any changes... I've included the email below, since it gives the exact workflow... Nick ---------- Forwarded message ---------- From: Judy Smith Date: Thu, Oct 30, 2014 at 11:33 AM Subject: RDA records To: Nicholas van Oudtshoorn [image: Perth Bible College] [image: Thinking Service] 1 College Court Karrinyup WA 6018 Australia Phone: +61 (0)8 9243 2000 Fax: +61 (0)8 9243 2050 college at pbc.wa.edu.au www.pbc.wa.edu.au CRICOS Provider Code: 00986G ABN: 52 599 089 532 Hi Nick, In saving a record using RDA I found that once I had saved a record and entered the item details, and also saved that, when I wanted to change any details in the item record I was unable to do so. I was able to select a different item location but when I tried to save this the details went back to the original selection. Judy Smith Perth Bible College judy at pbc.wa.edu.au This email is intended for the stated recipient only, and may contain confidential information. If you are not the stated recipient, you are not allowed to use or disclose any information contained within this communication. If you have received this email in error, please contact the sender immediately and delete this email from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pbc_logo.jpg Type: image/jpeg Size: 7876 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: thinking_service.jpg Type: image/jpeg Size: 3803 bytes Desc: not available URL: From tomascohen at gmail.com Thu Nov 6 16:44:00 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Thu, 06 Nov 2014 15:44:00 +0000 Subject: [Koha-devel] 3.18 dates Message-ID: I asked Bernardo to create the 3.18 translate project on Pootle, and we already have most of the 3.18 strings on the translate server. We still need to set a string freeze date. I propose the following dates: - String freeze: November 20th After that date, patches that touch strings will be delayed until after the release. There might be some exceptions I will consider if necesary: * Blockers. * Small changes to the about page for the release. - Release: November 28th I chose friday for a release, so everyone can have a proper release party without the need to go to the office on saturday :-D It's getting closer! YAY! Thanks everyone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Mon Nov 10 00:10:04 2014 From: dcook at prosentient.com.au (David Cook) Date: Mon, 10 Nov 2014 10:10:04 +1100 Subject: [Koha-devel] Proposal for a change in guidelines for the sign-off process in the Koha-community In-Reply-To: References: Message-ID: <01b001cffc72$4bf4cf00$e3de6d00$@prosentient.com.au> I think this has the potential to create a lot of conflict. I know the guideline saying that one company shouldn?t sign off its own patches slows things down, but ? like Owen ? I think it?s an important guideline. While I?m sure no one would abuse the process maliciously, I think a lot of mistakes would probably go unnoticed out of a desire to speed along the process. Even if the tester hasn?t worked on the development, there is an (unspoken) incentive to pass the patch and be less critical than someone from another organization. I think stability is more important than more features. Of course, some recent patches have shown that even our current process isn?t always able to catch all the problems. I think Brooke mentioned that we need more people. That?s probably true. If you think about it, more sign offs will mean even more of a burden on QA, which will mean more and more mistakes get through. Of course, I want to volunteer and do more, but I don?t have the time. Where do we stand regarding a patch coming from one company, a different company signing off, and QA coming from the original company? If Bywater and BibLibre add more people to the QA team, and test each other?s patches, that probably could compensate for higher volumes of patches both needing testing and having been tested. Mind you, I suppose the incentive then becomes to test the other company?s patches faster so they test yours faster and maybe the level of criticism lowers again anyway. Maybe we should trust people?s judgement and let more people add sign offs (so long as we?re also adding eyes to QA, I think). In any case, I think the main point where conflict will come is in the pointing out of abuse. No one likes receiving criticism. I could easily see rifts forming where one or two companies think that they?re acting within the guidelines but other people think they?re abusing the system. I think it would be awkward to point out such abuses in some cases, and heated or tense in other cases. I don?t know. Those are my two cents. I?m the only one at my company involved in the community, so I don?t really have a stake either way. I?m just concerned about stability and overworking key individuals. That said, I don?t have the time to volunteer at the moment. I?ve been too busy to test or contribute patches recently, so I wouldn?t put too much weight in my words. I suppose I?d like to hear from the QA team and former/present/future Release Managers on the subject. If they think they can handle an influx of patches due to companies signing off their own patches (admittedly via different individuals) and potential interpersonal conflict, then I suppose I?m up for it. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Brendan Gallagher Sent: Saturday, 11 October 2014 2:10 AM To: Koha Devel Subject: [Koha-devel] Proposal for a change in guidelines for the sign-off process in the Koha-community Hello All - During the hackfest, there was a discussion on the sign-off process for Koha. In attendance was, Nathan, Chris, Katrin, Paul_P, Jonathan, Arnaud, Joy, Brendan, Tom?s, Brooke, Tom, and BobB. Here is what we all agreed upon to send a proposal to the next developers or general meeting I?d like to put forward a motion for removal of the guideline that one company shouldn?t sign-off on the same company's patches within the community. I am suggesting additional checks be included in the sign-off process to prevent abuse of the proposed guideline, such as the committer and the person signing off must not have collaborated on the development of the patch. We shall review that idea/process every 6 months as an agenda item in the general meeting, to make sure that no abuse of the new privilege has occurred; also note here - that we do not have to wait 6 months to point out abuse of this new privilege. The QA team and Release Team still have the right to ask for more eyes to look at a certain bug at anytime and this should continue. Thank you, Brendan Gallagher -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Mon Nov 10 00:50:34 2014 From: dcook at prosentient.com.au (David Cook) Date: Mon, 10 Nov 2014 10:50:34 +1100 Subject: [Koha-devel] Proposal for a change in guidelines for the sign-off process in the Koha-community In-Reply-To: References: Message-ID: <01b501cffc77$f44cb7d0$dce62770$@prosentient.com.au> I like the sound of this. As I mentioned in my other email, I think stability is super important. I rather a feature languish indefinitely than have an unstable system that is going to give people major problems and corrupt the integrity of their data. Of course, it can be tough to test some features in test environments. I think Brendan mentioned how sometimes they'll push a feature locally and then upstream it only when it's been proven at the local level. I think that this is also really good idea. I've done this from time to time as well, although usually for small things relating to display. I'm generally very hesitant to make local enhancements that affect data in any way. At the moment, I'm looking at adding an OAI harvester client again, and I'm developing against master. I thought about doing it locally and then pushing it up, but it requires too many database additions and I want it to benefit from community scrutiny. I feel sometimes that we try to add too many bells and whistles. At this moment, there are 164 patches waiting to be tested. Only 41 of those are bugs. Personally, I would love more attention shown to bugs than enhancements. But again... that's just my two cents as someone with not a lot of time atm. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Owen Leonard > Sent: Wednesday, 15 October 2014 11:23 PM > To: Koha Devel > Subject: Re: [Koha-devel] Proposal for a change in guidelines for the sign-off > process in the Koha-community > > > I?d like to put forward a motion for removal of the guideline that one > > company shouldn?t sign-off on the same company's patches within the > > community. > > I think this is a good rule, and I think our current process has proved that by > showing that with many different points of view looking at the code more > issues can be found which need to be addressed before something is ready. > > I realize how frustrating it is to have something big and hard to test languish > in the QA process, but I think the right solution might be to get more creative > about how to help things move along. > > From my perspective as a bug tester the biggest thing I can say about it is to > have good test plans. I mean really really good test plans. > List, explicitly, every possible step that the tester could take to test the > patch. > > The obvious example here is Bug 6427 - Rewrite of the accounts system > (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6427). A big > patch that touches a LOT of files and involves one of the most mission-critical > aspects of Koha's circulation functionality. Pushing it before it was properly > tested could be disastrous for libraries who collect fines throughout the day. > > The bug has a pretty good test plan, but is that enough? What else could we > do to make sure it's ready for production? Perhaps set up a dedicated test > instance with some good sample data, give out logins which give permission > to circulate and collect fines, assign multiple days' worth of tests to be > performed by multiple testers? > > Getting volunteer testers is hard, and getting multiple volunteer testers is > harder, but sometimes I think we need to take a more active hand in > soliciting and promoting testing. > > -- Owen > > -- > Web Developer > Athens County Public Libraries > http://www.myacpl.org > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ From dcook at prosentient.com.au Mon Nov 10 01:09:41 2014 From: dcook at prosentient.com.au (David Cook) Date: Mon, 10 Nov 2014 11:09:41 +1100 Subject: [Koha-devel] Opac doesn't support IE6 and IE7 (with js enabled). Are we aware of this ? In-Reply-To: <42FC957D-6C2A-4B9B-B7A9-41FB25D3DE96@catalyst.net.nz> References: <542C2355.100@cineca.it> <542C6900.7030106@cineca.it> <42FC957D-6C2A-4B9B-B7A9-41FB25D3DE96@catalyst.net.nz> Message-ID: <01b601cffc7a$9fb1e800$df15b800$@prosentient.com.au> I think Chris makes a good point here. Working at a support company, I have to support organizations that use IE 7, but I don?t think we have to officially support IE 7 as a project. I don?t think it makes sense not to upgrade to newer versions of JS libraries just to maintain IE 7 support. However, I don?t necessarily appreciate criticism to patches I post that add IE 7 (or IE 8) support, when the code I target is written by us. In most cases, it?s simple feature detection with a few lines of code and comments stating the purpose and situation. In those cases, it doesn?t bother me if no one tests or QAs those patches. However, I post them because I figure other people are experiencing those same issues and I want to help out. I suppose you could argue that adding support in limited areas might just draw out the pain longer and reduce incentive to upgrade. That?s fair. If we don?t want to support IE 7 in any capacity at all, I?m happy to keep those patches entirely local. I?ll also reiterate what Owen said more recently: if you?re going to test Koha in Internet Explorer, it?s best to do it in Internet Explorer. This means doing it on a Windows box or using a Windows VM as provided by Microsoft. Using emulators/testers (especially browser based ones) will often give you false results. Even if you?re using the IE F12 dev tools, you?ll sometimes get incorrect results (depending on what the issue is). So if you want to check Koha?s performance in IE, I?d suggest downloading a VM and running it up in Virtualbox. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Chris Cormack Sent: Thursday, 2 October 2014 8:04 AM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Opac doesn't support IE6 and IE7 (with js enabled). Are we aware of this ? Hi all In my opinion, since Microsoft don't support IE7 and also have ended support for windows XP which is what it runs on. We as a project should not put effort into it. As a support company we have had to support organisations who use dangerous and old proprietary software, but I don't think it's a burden we have to put on the project as a whole. Chris On 2 October 2014 10:02:47 am NZDT, Owen Leonard > wrote: to globaly understand the situation I checking JS libs to find where we are incompatible with IE6/IE7. Please don't continue to spend time checking whether we are compatible with IE6. We do not support IE6. I encourage others to state their opinion on whether we should support IE7. -- Owen -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Mon Nov 10 16:08:43 2014 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 10 Nov 2014 16:08:43 +0100 Subject: [Koha-devel] Minor change on HEA Message-ID: <5460D4FB.2060004@biblibre.com> Hello, Jonathan just made 2 tiny changes on HEA (hea server side, no change on Koha) * HEA now records the creation datetime of an entry. That way we will be able to know which records are never updated (and maybe remove them one day) * when a Koha library send his informations for the 1st time, HEA give it a unique ID. The way the unique ID is generated has been changed, to be less easy to guess by brute force (in case someone would like to hack & flood HEA). database that already have sent their data will keep their previous identifier. Note that http://hea.koha-community.org/ contains the informations for 34 (BibLibre supported) libraries, and, hopefully, much more will be added when Koha 3.18 is released ! All vendors are more than welcomed to set-it HEA for their libraries (and all independent libraries too, of course) After Koha 3.18 release, I plan to submit the patch for previous maintained versions, so we should get more versions info, hopefully. -- Paul Poulain, Associ?-g?rant / co-owner BibLibre, expert du logiciel libre pour les biblioth?ques BibLibre, Open Source software for libraries expert From chris at bigballofwax.co.nz Mon Nov 10 20:50:40 2014 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 11 Nov 2014 08:50:40 +1300 Subject: [Koha-devel] Fwd: Questionaire regarding Patron Privacy and Security In-Reply-To: References: Message-ID: Forwarded with Marshall's permission Would you be able to help me fill this out? Galen has already made a good start which I have pasted at https://etherpad.mozilla.org/YiC0J8efmw Also the Evergreen community are working on their response at https://docs.google.com/document/d/1RgTnQOITvm3B_yzBOTfAuPZgDZig7xQ3N7Euib8rONc/edit Thanks Chris ---------- Forwarded message ---------- From: Marshall Breeding Date: 11 November 2014 02:55 Subject: Questionaire regarding Patron Privacy and Security To: Chris Cormack As you know, libraries are increasingly concerned with protecting the privacy of their patrons and in strong security. For an upcoming panel for CNI I have been charged with gathering data regarding how library management systems handle patron privacy and security. It would be great if I could have responses by November 21, 2014. Could you provide responses for the Koha? You are the one that comes to mind among those in the Koha community, but if there is someone else that you think should respond, please let me know. I really appreciate your help. I am interested in gathering some information regarding the current capabilities or options that systems offer today, looking forward to further progress in this arena toward more secure treatment of patron-related transactions. Given increasing concerns, I would expect that each company is working on providing a more secure environment. This data initially will be used for a briefing at the upcoming CNI Fall 2014 Membership Meeting, December 8-9, 2014: http://www.cni.org/events/membership-meetings/upcoming-meeting/fall-2014/project-briefings-breakout-sessions/ I also anticipate that this information would be helpful for other discussions, presentations, or reports. In addition to information provided by the developers of systems, I may also work with systems administrators of the various products for their perspectives on these security-related capabilities and options. I would greatly appreciate it if you could have your technical or product managers provide responses to these specific questions. It would also be helpful to have any additional comments or perspective whether these seem to be the best areas of concern regarding patron privacy, if there are alternative strategies that you are pursuing. I would also be interested to hear whether this topic has been raised also by your customers or users through enhancement requests or other product roadmap priorities. Does your online catalog or discovery interface: ? Enforce encryption through SSL for all transactions involving patron activity ? Offer the library an option to enable SSL for all transactions involving patron activity ? Enforce encryption for specific pages or transactions involving patron details or login credentials ? Offer the library an option to enable SSL for specific pages or transactions involving patron details or login details Does your client or interface for delivering functionality to library personnel: ? Enforce encryption through SSL or other encryption mechanisms for all transactions ? Offer the library an option to enable SSL or other encryption mechanisms for all transactions ? Enforce encryption for specific pages or transactions involving patron details ? Enforce Encryption for specific pages involving authentication of library personnel accounts ? Offer the library an option to enable SSL for specific pages involving patron details ? Offer the library an option to enable SSL or other encryption mechanisms for specific pages involving authentication of library personnel ? Enforce encryption for transactions involving institutional financial data (acquisitions, patron fines, etc) ? Offer the library an option to enable SSL or other encryption mechanisms for financial transactions How does your platform or system deal with the security of the storage of specific types of data: ? Does your system store patron passwords or PINs as unencrypted text ? Does your system store patron passwords or PINs as salted hash or similar mechanisms ? Does your system encrypt patron details as they are recorded and stored? Are logs or other system files that include patron search or reading behaviors encrypted? Describe any other security measures in place that protect patron privacy as it is transmitted over local networks or the Internet from interception by any third party. One specific scenario that has been a topic of concern involves the presentation of e-book discovery and lending transactions via library catalogs or discovery interfaces. Describe any integration with third party organizations that could potential expose patron details, search, or reading patterns and measures that you have provided to strengthen privacy and security. Do the APIs allow or require encryption in requests or responses that include patron-related data? What limitations to security impact your system imposed by the APIs or protocols managed by external or third-part products? Would your company be interested in a standardized specification for the treatment of patron or financial data, similar to the way that PCI provides a compliance framework for e-commerce transactions? I really appreciate your help with this project. Please confirm that you will be able to respond and let me know if you have any questions or concerns. -marshall Marshall Breeding http://www.librarytechnology.org marshall.breeding at librarytechnology.org http://twitter.com/mbreeding http://www.linkedin.com/in/breeding http://scholar.google.com/citations?user=NnvfJ5cAAAAJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Wed Nov 12 15:58:46 2014 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 12 Nov 2014 14:58:46 +0000 Subject: [Koha-devel] Ambiguous column names Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3142411BFB@S-MAIL-1B.rijksmuseum.intra> Hi, While adding a timestamp to the borrowers table, I ran into the trouble of ambiguous column names when querying multiple tables. See BZ 10459. Until now we added timestamps to several tables while just naming them "timestamp". Adding more timestamps will be increasingly difficult since we have to check all SQL queries that reference timestamp (from another table) and the table at hand. So I now consider adding borrowertimestamp, or bortimestamp (ugly but shorter). Any thoughts about doing this in some consistent manner? Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Wed Nov 12 19:35:40 2014 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 13 Nov 2014 07:35:40 +1300 Subject: [Koha-devel] Ambiguous column names In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3142411BFB@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA3142411BFB@S-MAIL-1B.rijksmuseum.intra> Message-ID: Hi Marcel I think we don't need to make columns unique across the whole db just when selecting do select borrowers.timestamp as something. DBIx::Class helps us with this also Just my 2 cents Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmc at esilibrary.com Wed Nov 12 19:39:22 2014 From: gmc at esilibrary.com (Galen Charlton) Date: Wed, 12 Nov 2014 10:39:22 -0800 Subject: [Koha-devel] Ambiguous column names In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA3142411BFB@S-MAIL-1B.rijksmuseum.intra> Message-ID: Hi, On Wed, Nov 12, 2014 at 10:35 AM, Chris Cormack wrote: > I think we don't need to make columns unique across the whole db just when > selecting do select borrowers.timestamp as something. > DBIx::Class helps us with this also I agree with Chris. In legacy code, doing a "select *" from a join on multiple tables is should be discouraged, so using the addition of a new column to locate cases of these to stamp out is preferable. The alternative of using a distinct column name has the problem of making the writing of more general templates and classes more difficult. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at 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 From dcook at prosentient.com.au Wed Nov 12 23:19:04 2014 From: dcook at prosentient.com.au (David Cook) Date: Thu, 13 Nov 2014 09:19:04 +1100 Subject: [Koha-devel] Ambiguous column names In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA3142411BFB@S-MAIL-1B.rijksmuseum.intra> Message-ID: <036f01cffec6$ab27b680$01772380$@prosentient.com.au> Agreed with Galen and Chris. DBIC should be able to handle this. Also, distinct column names would make joins more difficult when writing it out by hand (and for DBIC I think). David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Galen Charlton > Sent: Thursday, 13 November 2014 5:39 AM > To: Chris Cormack > Cc: Koha Devel > Subject: Re: [Koha-devel] Ambiguous column names > > Hi, > > On Wed, Nov 12, 2014 at 10:35 AM, Chris Cormack > wrote: > > I think we don't need to make columns unique across the whole db just > > when selecting do select borrowers.timestamp as something. > > DBIx::Class helps us with this also > > I agree with Chris. In legacy code, doing a "select *" from a join on multiple > tables is should be discouraged, so using the addition of a new column to > locate cases of these to stamp out is preferable. The alternative of using a > distinct column name has the problem of making the writing of more general > templates and classes more difficult. > > Regards, > > Galen > -- > Galen Charlton > Manager of Implementation > Equinox Software, Inc. / The Open Source Experts > email: gmc at 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 > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ From robin at catalyst.net.nz Wed Nov 12 23:34:04 2014 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 13 Nov 2014 11:34:04 +1300 Subject: [Koha-devel] Ambiguous column names In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3142411BFB@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA3142411BFB@S-MAIL-1B.rijksmuseum.intra> Message-ID: <1415831644.18842.27.camel@zarathud.wgtn.cat-it.co.nz> Marcel de Rooy schreef op wo 12-11-2014 om 14:58 [+0000]: > While adding a timestamp to the borrowers table, What does timestamp mean? Would more granularity be a good thing? I'm thinking something like "created" and "updated". On the other hand, maybe it's overkill. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From info at bywatersolutions.com Thu Nov 13 00:34:23 2014 From: info at bywatersolutions.com (Brendan Gallagher) Date: Wed, 12 Nov 2014 15:34:23 -0800 Subject: [Koha-devel] Fwd: Questionaire regarding Patron Privacy and Security In-Reply-To: References: Message-ID: Can someone add info about LDAP to that list? (someone with the correct technical terms that is ;) ) On Mon, Nov 10, 2014 at 11:50 AM, Chris Cormack wrote: > Forwarded with Marshall's permission > > Would you be able to help me fill this out? > > Galen has already made a good start which I have pasted at > https://etherpad.mozilla.org/YiC0J8efmw > > Also the Evergreen community are working on their response at > > https://docs.google.com/document/d/1RgTnQOITvm3B_yzBOTfAuPZgDZig7xQ3N7Euib8rONc/edit > > Thanks > > Chris > > ---------- Forwarded message ---------- > From: Marshall Breeding > Date: 11 November 2014 02:55 > Subject: Questionaire regarding Patron Privacy and Security > To: Chris Cormack > > > As you know, libraries are increasingly concerned with protecting the > privacy of their patrons and in strong security. For an upcoming panel > for CNI I have been charged with gathering data regarding how library > management systems handle patron privacy and security. > > > > It would be great if I could have responses by November 21, 2014. > > > > Could you provide responses for the Koha? You are the one that comes to > mind among those in the Koha community, but if there is someone else that > you think should respond, please let me know. I really appreciate your help. > > > > > I am interested in gathering some information regarding the current > capabilities or options that systems offer today, looking forward to > further progress in this arena toward more secure treatment of > patron-related transactions. Given increasing concerns, I would expect > that each company is working on providing a more secure environment. > > > > This data initially will be used for a briefing at the upcoming CNI Fall > 2014 Membership Meeting, December 8-9, 2014: > > > http://www.cni.org/events/membership-meetings/upcoming-meeting/fall-2014/project-briefings-breakout-sessions/ > > > > I also anticipate that this information would be helpful for other > discussions, presentations, or reports. > > > > In addition to information provided by the developers of systems, I may > also work with systems administrators of the various products for their > perspectives on these security-related capabilities and options. > > > > I would greatly appreciate it if you could have your technical or product > managers provide responses to these specific questions. It would also be > helpful to have any additional comments or perspective whether these seem > to be the best areas of concern regarding patron privacy, if there are > alternative strategies that you are pursuing. I would also be interested > to hear whether this topic has been raised also by your customers or users > through enhancement requests or other product roadmap priorities. > > > > Does your online catalog or discovery interface: > > ? Enforce encryption through SSL for all transactions involving > patron activity > > ? Offer the library an option to enable SSL for all transactions > involving patron activity > > ? Enforce encryption for specific pages or transactions involving > patron details or login credentials > > ? Offer the library an option to enable SSL for specific pages or > transactions involving patron details or login details > > > > Does your client or interface for delivering functionality to library > personnel: > > ? Enforce encryption through SSL or other encryption mechanisms > for all transactions > > ? Offer the library an option to enable SSL or other encryption > mechanisms for all transactions > > ? Enforce encryption for specific pages or transactions involving > patron details > > ? Enforce Encryption for specific pages involving authentication > of library personnel accounts > > ? Offer the library an option to enable SSL for specific pages > involving patron details > > ? Offer the library an option to enable SSL or other encryption > mechanisms for specific pages involving authentication of library personnel > > ? Enforce encryption for transactions involving institutional > financial data (acquisitions, patron fines, etc) > > ? Offer the library an option to enable SSL or other encryption > mechanisms for financial transactions > > > > How does your platform or system deal with the security of the storage of > specific types of data: > > ? Does your system store patron passwords or PINs as unencrypted > text > > ? Does your system store patron passwords or PINs as salted hash > or similar mechanisms > > ? Does your system encrypt patron details as they are recorded > and stored? > > > > Are logs or other system files that include patron search or reading > behaviors encrypted? > > > > Describe any other security measures in place that protect patron privacy > as it is transmitted over local networks or the Internet from interception > by any third party. One specific scenario that has been a topic of concern > involves the presentation of e-book discovery and lending transactions via > library catalogs or discovery interfaces. > > > > Describe any integration with third party organizations that could > potential expose patron details, search, or reading patterns and measures > that you have provided to strengthen privacy and security. > > > > Do the APIs allow or require encryption in requests or responses that > include patron-related data? > > What limitations to security impact your system imposed by the APIs or > protocols managed by external or third-part products? > > > > Would your company be interested in a standardized specification for the > treatment of patron or financial data, similar to the way that PCI provides > a compliance framework for e-commerce transactions? > > > > I really appreciate your help with this project. Please confirm that you > will be able to respond and let me know if you have any questions or > concerns. > > > > -marshall > > > > > > Marshall Breeding > > http://www.librarytechnology.org > > marshall.breeding at librarytechnology.org > > http://twitter.com/mbreeding > > http://www.linkedin.com/in/breeding > > http://scholar.google.com/citations?user=NnvfJ5cAAAAJ > > > > > > > > > > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Santa Barbara, CA - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info at bywatersolutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmc at esilibrary.com Thu Nov 13 00:45:38 2014 From: gmc at esilibrary.com (Galen Charlton) Date: Wed, 12 Nov 2014 15:45:38 -0800 Subject: [Koha-devel] Fwd: Questionaire regarding Patron Privacy and Security In-Reply-To: References: Message-ID: Hi, On Wed, Nov 12, 2014 at 3:34 PM, Brendan Gallagher wrote: > Can someone add info about LDAP to that list? (someone with the correct > technical terms that is ;) ) I've made an edit to the Etherpad to mention LDAP. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at 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 From dcook at prosentient.com.au Thu Nov 13 02:12:24 2014 From: dcook at prosentient.com.au (David Cook) Date: Thu, 13 Nov 2014 12:12:24 +1100 Subject: [Koha-devel] Ambiguous column names In-Reply-To: <1415831644.18842.27.camel@zarathud.wgtn.cat-it.co.nz> References: <809BE39CD64BFD4EB9036172EBCCFA3142411BFB@S-MAIL-1B.rijksmuseum.intra> <1415831644.18842.27.camel@zarathud.wgtn.cat-it.co.nz> Message-ID: <000001cffede$e1eb4200$a5c1c600$@prosentient.com.au> I think the best option, if we were to change away from timestamp, would have to be "lastmodified", as timestamp types will get updated after every insert/update, I believe. But since they'd all be called "lastmodified", changing it from "timestamp" would become a bit moot, I think. Unless we used datetime types in the database and relied on the code to provide the correct date rather than the database (as it does with the timestamp type). David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Robin Sheat > Sent: Thursday, 13 November 2014 9:34 AM > To: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Ambiguous column names > > Marcel de Rooy schreef op wo 12-11-2014 om 14:58 [+0000]: > > While adding a timestamp to the borrowers table, > > What does timestamp mean? Would more granularity be a good thing? I'm > thinking something like "created" and "updated". On the other hand, maybe > it's overkill. > > -- > Robin Sheat > Catalyst IT Ltd. > ? +64 4 803 2204 > GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF From robin at catalyst.net.nz Thu Nov 13 03:02:50 2014 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 13 Nov 2014 15:02:50 +1300 Subject: [Koha-devel] Ambiguous column names In-Reply-To: <000001cffede$e1eb4200$a5c1c600$@prosentient.com.au> References: <809BE39CD64BFD4EB9036172EBCCFA3142411BFB@S-MAIL-1B.rijksmuseum.intra> <1415831644.18842.27.camel@zarathud.wgtn.cat-it.co.nz> <000001cffede$e1eb4200$a5c1c600$@prosentient.com.au> Message-ID: <1415844170.18842.41.camel@zarathud.wgtn.cat-it.co.nz> David Cook schreef op do 13-11-2014 om 12:12 [+1100]: > I think the best option, if we were to change away from timestamp, > would have to be "lastmodified", as timestamp types will get updated > after every insert/update, I believe. But since they'd all be called > "lastmodified", changing it from "timestamp" would become a bit moot, > I think. Well, I was thinking both, "created" and "updated." So you know when the record was created, and when it was last changed. Both very handy for simple auditing or bug finding. It's possible to have a timestamp field that is initialised to the current date automatically on creation, and another that is auto updated. http://dev.mysql.com/doc/refman/5.1/en/timestamp-initialization.html This would nicely mean that there's no code at all in Koha required to maintain this. Anyway, I was just sticking my oar in, I've no desire to bikeshed it into the ground, anything is better than nothing :) -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From dcook at prosentient.com.au Thu Nov 13 04:10:59 2014 From: dcook at prosentient.com.au (David Cook) Date: Thu, 13 Nov 2014 14:10:59 +1100 Subject: [Koha-devel] Ambiguous column names In-Reply-To: <1415844170.18842.41.camel@zarathud.wgtn.cat-it.co.nz> References: <809BE39CD64BFD4EB9036172EBCCFA3142411BFB@S-MAIL-1B.rijksmuseum.intra> <1415831644.18842.27.camel@zarathud.wgtn.cat-it.co.nz> <000001cffede$e1eb4200$a5c1c600$@prosentient.com.au> <1415844170.18842.41.camel@zarathud.wgtn.cat-it.co.nz> Message-ID: <000c01cffeef$73355e70$59a01b50$@prosentient.com.au> Thanks for the link! It's rather interesting! Yeah, I think "created" and "updated" columns would be useful. I think we already use them in "biblio", although maybe the code in Koha is setting those rather than the database. It would be handy to either auto-initialize/auto-update, or just pass null once to a "created" column and every time to an "updated" column. I'm happy to drop it, but thanks for the clarification :D. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Robin Sheat > Sent: Thursday, 13 November 2014 1:03 PM > To: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Ambiguous column names > > David Cook schreef op do 13-11-2014 om 12:12 [+1100]: > > I think the best option, if we were to change away from timestamp, > > would have to be "lastmodified", as timestamp types will get updated > > after every insert/update, I believe. But since they'd all be called > > "lastmodified", changing it from "timestamp" would become a bit moot, > > I think. > > Well, I was thinking both, "created" and "updated." So you know when the > record was created, and when it was last changed. Both very handy for > simple auditing or bug finding. > > It's possible to have a timestamp field that is initialised to the current date > automatically on creation, and another that is auto updated. > > http://dev.mysql.com/doc/refman/5.1/en/timestamp-initialization.html > > This would nicely mean that there's no code at all in Koha required to > maintain this. > > Anyway, I was just sticking my oar in, I've no desire to bikeshed it into the > ground, anything is better than nothing :) > > -- > Robin Sheat > Catalyst IT Ltd. > ? +64 4 803 2204 > GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF From dcook at prosentient.com.au Thu Nov 13 04:51:32 2014 From: dcook at prosentient.com.au (David Cook) Date: Thu, 13 Nov 2014 14:51:32 +1100 Subject: [Koha-devel] Ambiguous column names In-Reply-To: <1415844170.18842.41.camel@zarathud.wgtn.cat-it.co.nz> References: <809BE39CD64BFD4EB9036172EBCCFA3142411BFB@S-MAIL-1B.rijksmuseum.intra> <1415831644.18842.27.camel@zarathud.wgtn.cat-it.co.nz> <000001cffede$e1eb4200$a5c1c600$@prosentient.com.au> <1415844170.18842.41.camel@zarathud.wgtn.cat-it.co.nz> Message-ID: <000d01cffef5$1cf67430$56e35c90$@prosentient.com.au> Actually, after looking at the `issues` and `reserves` tables, I'm really in favour of getting rid of "timestamp" columns and renaming them more contextually. In the case of `reserves`, I have no idea what `timestamp` means. There's already `reservedate`, `notificationdate`, `reminderdate`, `waitingdate`. It's probably `updated` in that case? As `reservedate` would be `created`? In the case of `issues`, there is already `date_due`, `lastreneweddate`, `returndate`, `issuedate`. I imagine `issuedate` would be `created`. It looks like `timestamp` is `updated` . As I look, it usually matches `lastreneweddate` although timestamp has time while the other does not. I wonder how much we actually use `timestamp` in the code... Of course, if we do change column names, then we'll be screwing up a lot of the existing SQL reports that people have out there which may or may not use timestamp for dating... David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Robin Sheat > Sent: Thursday, 13 November 2014 1:03 PM > To: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Ambiguous column names > > David Cook schreef op do 13-11-2014 om 12:12 [+1100]: > > I think the best option, if we were to change away from timestamp, > > would have to be "lastmodified", as timestamp types will get updated > > after every insert/update, I believe. But since they'd all be called > > "lastmodified", changing it from "timestamp" would become a bit moot, > > I think. > > Well, I was thinking both, "created" and "updated." So you know when the > record was created, and when it was last changed. Both very handy for > simple auditing or bug finding. > > It's possible to have a timestamp field that is initialised to the current date > automatically on creation, and another that is auto updated. > > http://dev.mysql.com/doc/refman/5.1/en/timestamp-initialization.html > > This would nicely mean that there's no code at all in Koha required to > maintain this. > > Anyway, I was just sticking my oar in, I've no desire to bikeshed it into the > ground, anything is better than nothing :) > > -- > Robin Sheat > Catalyst IT Ltd. > ? +64 4 803 2204 > GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF From chris at bigballofwax.co.nz Thu Nov 13 04:58:30 2014 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 13 Nov 2014 16:58:30 +1300 Subject: [Koha-devel] Ambiguous column names In-Reply-To: <000d01cffef5$1cf67430$56e35c90$@prosentient.com.au> References: <809BE39CD64BFD4EB9036172EBCCFA3142411BFB@S-MAIL-1B.rijksmuseum.intra> <1415831644.18842.27.camel@zarathud.wgtn.cat-it.co.nz> <000001cffede$e1eb4200$a5c1c600$@prosentient.com.au> <1415844170.18842.41.camel@zarathud.wgtn.cat-it.co.nz> <000d01cffef5$1cf67430$56e35c90$@prosentient.com.au> Message-ID: I think it should be yellow Chris On 13/11/2014 4:52 pm, "David Cook" wrote: > Actually, after looking at the `issues` and `reserves` tables, I'm really > in favour of getting rid of "timestamp" columns and renaming them more > contextually. > > In the case of `reserves`, I have no idea what `timestamp` means. There's > already `reservedate`, `notificationdate`, `reminderdate`, `waitingdate`. > It's probably `updated` in that case? As `reservedate` would be `created`? > > In the case of `issues`, there is already `date_due`, `lastreneweddate`, > `returndate`, `issuedate`. I imagine `issuedate` would be `created`. It > looks like `timestamp` is `updated` . As I look, it usually matches > `lastreneweddate` although timestamp has time while the other does not. > > I wonder how much we actually use `timestamp` in the code... > > Of course, if we do change column names, then we'll be screwing up a lot > of the existing SQL reports that people have out there which may or may not > use timestamp for dating... > > David Cook > Systems Librarian > Prosentient Systems > 72/330 Wattle St, Ultimo, NSW 2007 > > > -----Original Message----- > > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > > bounces at lists.koha-community.org] On Behalf Of Robin Sheat > > Sent: Thursday, 13 November 2014 1:03 PM > > To: koha-devel at lists.koha-community.org > > Subject: Re: [Koha-devel] Ambiguous column names > > > > David Cook schreef op do 13-11-2014 om 12:12 [+1100]: > > > I think the best option, if we were to change away from timestamp, > > > would have to be "lastmodified", as timestamp types will get updated > > > after every insert/update, I believe. But since they'd all be called > > > "lastmodified", changing it from "timestamp" would become a bit moot, > > > I think. > > > > Well, I was thinking both, "created" and "updated." So you know when the > > record was created, and when it was last changed. Both very handy for > > simple auditing or bug finding. > > > > It's possible to have a timestamp field that is initialised to the > current date > > automatically on creation, and another that is auto updated. > > > > http://dev.mysql.com/doc/refman/5.1/en/timestamp-initialization.html > > > > This would nicely mean that there's no code at all in Koha required to > > maintain this. > > > > Anyway, I was just sticking my oar in, I've no desire to bikeshed it > into the > > ground, anything is better than nothing :) > > > > -- > > Robin Sheat > > Catalyst IT Ltd. > > ? +64 4 803 2204 > > GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Thu Nov 13 05:16:19 2014 From: dcook at prosentient.com.au (David Cook) Date: Thu, 13 Nov 2014 15:16:19 +1100 Subject: [Koha-devel] Ambiguous column names In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA3142411BFB@S-MAIL-1B.rijksmuseum.intra> <1415831644.18842.27.camel@zarathud.wgtn.cat-it.co.nz> <000001cffede$e1eb4200$a5c1c600$@prosentient.com.au> <1415844170.18842.41.camel@zarathud.wgtn.cat-it.co.nz> <000d01cffef5$1cf67430$56e35c90$@prosentient.com.au> Message-ID: <001001cffef8$93a592c0$baf0b840$@prosentient.com.au> I?m partial to blue myself :p. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: Chris Cormack [mailto:chris at bigballofwax.co.nz] Sent: Thursday, 13 November 2014 2:59 PM To: David Cook Cc: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Ambiguous column names I think it should be yellow Chris On 13/11/2014 4:52 pm, "David Cook" > wrote: Actually, after looking at the `issues` and `reserves` tables, I'm really in favour of getting rid of "timestamp" columns and renaming them more contextually. In the case of `reserves`, I have no idea what `timestamp` means. There's already `reservedate`, `notificationdate`, `reminderdate`, `waitingdate`. It's probably `updated` in that case? As `reservedate` would be `created`? In the case of `issues`, there is already `date_due`, `lastreneweddate`, `returndate`, `issuedate`. I imagine `issuedate` would be `created`. It looks like `timestamp` is `updated` . As I look, it usually matches `lastreneweddate` although timestamp has time while the other does not. I wonder how much we actually use `timestamp` in the code... Of course, if we do change column names, then we'll be screwing up a lot of the existing SQL reports that people have out there which may or may not use timestamp for dating... David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org ] On Behalf Of Robin Sheat > Sent: Thursday, 13 November 2014 1:03 PM > To: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Ambiguous column names > > David Cook schreef op do 13-11-2014 om 12:12 [+1100]: > > I think the best option, if we were to change away from timestamp, > > would have to be "lastmodified", as timestamp types will get updated > > after every insert/update, I believe. But since they'd all be called > > "lastmodified", changing it from "timestamp" would become a bit moot, > > I think. > > Well, I was thinking both, "created" and "updated." So you know when the > record was created, and when it was last changed. Both very handy for > simple auditing or bug finding. > > It's possible to have a timestamp field that is initialised to the current date > automatically on creation, and another that is auto updated. > > http://dev.mysql.com/doc/refman/5.1/en/timestamp-initialization.html > > This would nicely mean that there's no code at all in Koha required to > maintain this. > > Anyway, I was just sticking my oar in, I've no desire to bikeshed it into the > ground, anything is better than nothing :) > > -- > Robin Sheat > Catalyst IT Ltd. > ? +64 4 803 2204 > GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF _______________________________________________ Koha-devel mailing list Koha-devel at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Thu Nov 13 08:42:22 2014 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Thu, 13 Nov 2014 07:42:22 +0000 Subject: [Koha-devel] Ambiguous column names In-Reply-To: <1415844170.18842.41.camel@zarathud.wgtn.cat-it.co.nz> References: <809BE39CD64BFD4EB9036172EBCCFA3142411BFB@S-MAIL-1B.rijksmuseum.intra> <1415831644.18842.27.camel@zarathud.wgtn.cat-it.co.nz> <000001cffede$e1eb4200$a5c1c600$@prosentient.com.au> <1415844170.18842.41.camel@zarathud.wgtn.cat-it.co.nz> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31424123EE@S-MAIL-1B.rijksmuseum.intra> Thanks for the replies. I will update the borrower-timestamp report accordingly. I will stick to timestamp for the reasons mentioned. Will have to check/update some queries though to prevent the ambiguous column-error. > Well, I was thinking both, "created" and "updated." So you know when the > record was created, and when it was last changed. Both very handy for > simple auditing or bug finding. Sounds good to me, although I do not commit myself to implementing it right now ;) Marcel From jonathan.druart at biblibre.com Thu Nov 13 09:27:22 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Thu, 13 Nov 2014 09:27:22 +0100 Subject: [Koha-devel] Ambiguous column names In-Reply-To: <000c01cffeef$73355e70$59a01b50$@prosentient.com.au> References: <809BE39CD64BFD4EB9036172EBCCFA3142411BFB@S-MAIL-1B.rijksmuseum.intra> <1415831644.18842.27.camel@zarathud.wgtn.cat-it.co.nz> <000001cffede$e1eb4200$a5c1c600$@prosentient.com.au> <1415844170.18842.41.camel@zarathud.wgtn.cat-it.co.nz> <000c01cffeef$73355e70$59a01b50$@prosentient.com.au> Message-ID: Haha, funny. I tried to do that 2 days ago and... it does not work. create table test( created timestamp not null default current_timestamp, updated timestamp not null default current_timestamp on update current_timestamp ); ERROR 1293 (HY000): Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause The solution would be to create a trigger... MySQL-- So maybe with a datetime? Hum, yes maybe, but only from MySQL 5.6.5 ( https://dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html) MySQL-- 2014-11-13 4:10 GMT+01:00 David Cook : > Thanks for the link! It's rather interesting! > > Yeah, I think "created" and "updated" columns would be useful. I think we > already use them in "biblio", although maybe the code in Koha is setting > those rather than the database. It would be handy to either > auto-initialize/auto-update, or just pass null once to a "created" column > and every time to an "updated" column. > > I'm happy to drop it, but thanks for the clarification :D. > > David Cook > Systems Librarian > Prosentient Systems > 72/330 Wattle St, Ultimo, NSW 2007 > > > -----Original Message----- > > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > > bounces at lists.koha-community.org] On Behalf Of Robin Sheat > > Sent: Thursday, 13 November 2014 1:03 PM > > To: koha-devel at lists.koha-community.org > > Subject: Re: [Koha-devel] Ambiguous column names > > > > David Cook schreef op do 13-11-2014 om 12:12 [+1100]: > > > I think the best option, if we were to change away from timestamp, > > > would have to be "lastmodified", as timestamp types will get updated > > > after every insert/update, I believe. But since they'd all be called > > > "lastmodified", changing it from "timestamp" would become a bit moot, > > > I think. > > > > Well, I was thinking both, "created" and "updated." So you know when the > > record was created, and when it was last changed. Both very handy for > > simple auditing or bug finding. > > > > It's possible to have a timestamp field that is initialised to the > current date > > automatically on creation, and another that is auto updated. > > > > http://dev.mysql.com/doc/refman/5.1/en/timestamp-initialization.html > > > > This would nicely mean that there's no code at all in Koha required to > > maintain this. > > > > Anyway, I was just sticking my oar in, I've no desire to bikeshed it > into the > > ground, anything is better than nothing :) > > > > -- > > Robin Sheat > > Catalyst IT Ltd. > > ? +64 4 803 2204 > > GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Fri Nov 14 01:20:36 2014 From: dcook at prosentient.com.au (David Cook) Date: Fri, 14 Nov 2014 11:20:36 +1100 Subject: [Koha-devel] Ambiguous column names In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA3142411BFB@S-MAIL-1B.rijksmuseum.intra> <1415831644.18842.27.camel@zarathud.wgtn.cat-it.co.nz> <000001cffede$e1eb4200$a5c1c600$@prosentient.com.au> <1415844170.18842.41.camel@zarathud.wgtn.cat-it.co.nz> <000c01cffeef$73355e70$59a01b50$@prosentient.com.au> Message-ID: <007c01cfffa0$cfeb0550$6fc10ff0$@prosentient.com.au> Ahhh, yeah, I did read that you couldn?t have multiple columns with CURRENT_TIMESTAMP. The wording was a bit vague though so I was going to try it out. Good to know. I suppose the thing to do then is use TIMESTAMP for `updated` (with DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP) and then DATETIME for `created` and just use a NOW() in the original INSERT query. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Jonathan Druart Sent: Thursday, 13 November 2014 7:27 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Ambiguous column names Haha, funny. I tried to do that 2 days ago and... it does not work. create table test( created timestamp not null default current_timestamp, updated timestamp not null default current_timestamp on update current_timestamp ); ERROR 1293 (HY000): Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause The solution would be to create a trigger... MySQL-- So maybe with a datetime? Hum, yes maybe, but only from MySQL 5.6.5 (https://dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html) MySQL-- 2014-11-13 4:10 GMT+01:00 David Cook >: Thanks for the link! It's rather interesting! Yeah, I think "created" and "updated" columns would be useful. I think we already use them in "biblio", although maybe the code in Koha is setting those rather than the database. It would be handy to either auto-initialize/auto-update, or just pass null once to a "created" column and every time to an "updated" column. I'm happy to drop it, but thanks for the clarification :D. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org ] On Behalf Of Robin Sheat > Sent: Thursday, 13 November 2014 1:03 PM > To: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Ambiguous column names > > David Cook schreef op do 13-11-2014 om 12:12 [+1100]: > > I think the best option, if we were to change away from timestamp, > > would have to be "lastmodified", as timestamp types will get updated > > after every insert/update, I believe. But since they'd all be called > > "lastmodified", changing it from "timestamp" would become a bit moot, > > I think. > > Well, I was thinking both, "created" and "updated." So you know when the > record was created, and when it was last changed. Both very handy for > simple auditing or bug finding. > > It's possible to have a timestamp field that is initialised to the current date > automatically on creation, and another that is auto updated. > > http://dev.mysql.com/doc/refman/5.1/en/timestamp-initialization.html > > This would nicely mean that there's no code at all in Koha required to > maintain this. > > Anyway, I was just sticking my oar in, I've no desire to bikeshed it into the > ground, anything is better than nothing :) > > -- > Robin Sheat > Catalyst IT Ltd. > ? +64 4 803 2204 > GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF _______________________________________________ Koha-devel mailing list Koha-devel at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at biblibre.com Fri Nov 14 09:37:43 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Fri, 14 Nov 2014 09:37:43 +0100 Subject: [Koha-devel] Ambiguous column names In-Reply-To: <007c01cfffa0$cfeb0550$6fc10ff0$@prosentient.com.au> References: <809BE39CD64BFD4EB9036172EBCCFA3142411BFB@S-MAIL-1B.rijksmuseum.intra> <1415831644.18842.27.camel@zarathud.wgtn.cat-it.co.nz> <000001cffede$e1eb4200$a5c1c600$@prosentient.com.au> <1415844170.18842.41.camel@zarathud.wgtn.cat-it.co.nz> <000c01cffeef$73355e70$59a01b50$@prosentient.com.au> <007c01cfffa0$cfeb0550$6fc10ff0$@prosentient.com.au> Message-ID: https://github.com/biblibre/hea-ws/commit/9b48cc364547e0f779f8369946fb8371c73b6e9f It's exactly what I did :) 2014-11-14 1:20 GMT+01:00 David Cook : > Ahhh, yeah, I did read that you couldn?t have multiple columns with > CURRENT_TIMESTAMP. The wording was a bit vague though so I was going to try > it out. Good to know. > > > > I suppose the thing to do then is use TIMESTAMP for `updated` (with > DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP) and then DATETIME > for `created` and just use a NOW() in the original INSERT query. > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St, Ultimo, NSW 2007 > > > > *From:* koha-devel-bounces at lists.koha-community.org [mailto: > koha-devel-bounces at lists.koha-community.org] *On Behalf Of *Jonathan > Druart > *Sent:* Thursday, 13 November 2014 7:27 PM > > *To:* koha-devel at lists.koha-community.org > *Subject:* Re: [Koha-devel] Ambiguous column names > > > > Haha, funny. I tried to do that 2 days ago and... it does not work. > > create table test( > created timestamp not null default current_timestamp, > updated timestamp not null default current_timestamp on update > current_timestamp > ); > ERROR 1293 (HY000): Incorrect table definition; there can be only one > TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause > > The solution would be to create a trigger... MySQL-- > > So maybe with a datetime? Hum, yes maybe, but only from MySQL 5.6.5 ( > https://dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html) > > MySQL-- > > > > 2014-11-13 4:10 GMT+01:00 David Cook : > > Thanks for the link! It's rather interesting! > > Yeah, I think "created" and "updated" columns would be useful. I think we > already use them in "biblio", although maybe the code in Koha is setting > those rather than the database. It would be handy to either > auto-initialize/auto-update, or just pass null once to a "created" column > and every time to an "updated" column. > > I'm happy to drop it, but thanks for the clarification :D. > > David Cook > Systems Librarian > Prosentient Systems > 72/330 Wattle St, Ultimo, NSW 2007 > > > -----Original Message----- > > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > > bounces at lists.koha-community.org] On Behalf Of Robin Sheat > > Sent: Thursday, 13 November 2014 1:03 PM > > To: koha-devel at lists.koha-community.org > > Subject: Re: [Koha-devel] Ambiguous column names > > > > > David Cook schreef op do 13-11-2014 om 12:12 [+1100]: > > > I think the best option, if we were to change away from timestamp, > > > would have to be "lastmodified", as timestamp types will get updated > > > after every insert/update, I believe. But since they'd all be called > > > "lastmodified", changing it from "timestamp" would become a bit moot, > > > I think. > > > > Well, I was thinking both, "created" and "updated." So you know when the > > record was created, and when it was last changed. Both very handy for > > simple auditing or bug finding. > > > > It's possible to have a timestamp field that is initialised to the > current date > > automatically on creation, and another that is auto updated. > > > > http://dev.mysql.com/doc/refman/5.1/en/timestamp-initialization.html > > > > This would nicely mean that there's no code at all in Koha required to > > maintain this. > > > > Anyway, I was just sticking my oar in, I've no desire to bikeshed it > into the > > ground, anything is better than nothing :) > > > > -- > > Robin Sheat > > Catalyst IT Ltd. > > ? +64 4 803 2204 > > GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From z.tajoli at cineca.it Mon Nov 17 15:53:21 2014 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Mon, 17 Nov 2014 15:53:21 +0100 Subject: [Koha-devel] tests for utf-8 Message-ID: <546A0BE1.9020909@cineca.it> Hi to all, at http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13264 I have insert a very basic test on utf-8 on Opac. This test need a specif enviromet: -- working zebraserver -- wokrking background indexer -- the base url of intranet in env variable KOHA_INTRANET_URL -- the base url of opac in env variable KOHA_OPAC_URL if the enviroment is not good, all test are skipped, not a faliure. To do the tests I need to records, one Unimarc and one MARC21. A question about writting patch: Is it better to have a specific patch only for the two iso2709 records ? Is it a good idea to insert in the git archive a version of two record in a flat/open format (like '.mrk' of MarcEdit) ? Reading the code I find an other test that covers utf-8: t/db_dependent/Koha_Database.t Bye Zeno Tajoli -- Dr. Zeno Tajoli Soluzioni per la Ricerca Istituzionale - Automazione Biblioteche z.tajoli at cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate From tomascohen at gmail.com Mon Nov 17 16:07:06 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Mon, 17 Nov 2014 15:07:06 +0000 Subject: [Koha-devel] tests for utf-8 References: <546A0BE1.9020909@cineca.it> Message-ID: +1000 Many thanks Zeno! Regarding the mrc file you can take a look at t/db_dependent/Search.t which launches its own zebrasrv and loads its own records too. Regards Tom?s El Mon Nov 17 2014 at 11:53:09, Zeno Tajoli () escribi?: > Hi to all, > > at http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13264 > > I have insert a very basic test on utf-8 on Opac. > This test need a specif enviromet: > > -- working zebraserver > -- wokrking background indexer > -- the base url of intranet in env variable KOHA_INTRANET_URL > -- the base url of opac in env variable KOHA_OPAC_URL > > if the enviroment is not good, all test are skipped, not a faliure. > > To do the tests I need to records, one Unimarc and one MARC21. > > A question about writting patch: Is it better to have a specific patch > only for the two iso2709 records ? > > Is it a good idea to insert in the git archive a version of two record > in a flat/open format (like '.mrk' of MarcEdit) ? > > Reading the code I find an other test that covers utf-8: > t/db_dependent/Koha_Database.t > > > Bye > Zeno Tajoli > > > -- > Dr. Zeno Tajoli > Soluzioni per la Ricerca Istituzionale - Automazione Biblioteche > z.tajoli at cineca.it > fax +39 02 2135520 > CINECA - Sede operativa di Segrate > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Mon Nov 17 20:20:47 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Mon, 17 Nov 2014 19:20:47 +0000 Subject: [Koha-devel] Koha 3.18 beta released Message-ID: A beta release of Koha 3.18 is now available for dowload. We encourage all users of Koha to download and test this beta prior to its release on November 28th. Debian packages for this beta will be available soon on the squeeze-dev repository. Koha 3.18.0 is a major release, that comes with many new features. This beta preview is released for testing purposes. Its use on production sites is discouraged. Draft release notes and download links can be found below. Share and enjoy (and test)! Download: http://koha-community.org/download-koha/ Draft release notes: http://koha-community.org/koha-3-18-beta-released/ Thanks everyone! -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at catalyst.net.nz Tue Nov 18 00:04:13 2014 From: robin at catalyst.net.nz (Robin Sheat) Date: Tue, 18 Nov 2014 12:04:13 +1300 Subject: [Koha-devel] Koha 3.18 beta released In-Reply-To: References: Message-ID: <1416265453.20978.18.camel@zarathud.wgtn.cat-it.co.nz> Tomas Cohen Arazi schreef op ma 17-11-2014 om 19:20 [+0000]: > Debian packages for this beta will be available soon on the > squeeze-dev repository. Any chance that the QA tools can be modified to do a test run without a database active, this has been happening a lot lately and right now is preventing a build of 3.18 beta: DBI connect('dbname=koha;host=localhost;port=3306','kohaadmin',...) failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at /tmp/buildd/koha-3.17~git+20141118115103.6cd7c24c/blib/PERL_MODULE_DIR/C4/Context.pm line 785 # Failed test 'use C4::Message;' # at t/00-load.t line 33. # Tried to use 'C4::Message'. # Error: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at /tmp/buildd/koha-3.17~git+20141118115103.6cd7c24c/blib/PERL_MODULE_DIR/C4/Context.pm line 785. # Compilation failed in require at /tmp/buildd/koha-3.17~git+20141118115103.6cd7c24c/blib/PERL_MODULE_DIR/C4/Letters.pm line 27. # BEGIN failed--compilation aborted at /tmp/buildd/koha-3.17~git+20141118115103.6cd7c24c/blib/PERL_MODULE_DIR/C4/Letters.pm line 27. # Compilation failed in require at /tmp/buildd/koha-3.17~git+20141118115103.6cd7c24c/blib/PERL_MODULE_DIR/C4/Message.pm line 25. # BEGIN failed--compilation aborted at /tmp/buildd/koha-3.17~git+20141118115103.6cd7c24c/blib/PERL_MODULE_DIR/C4/Message.pm line 25. # Compilation failed in require at t/00-load.t line 33. # BEGIN failed--compilation aborted at t/00-load.t line 33. Bailout called. Further testing stopped: ***** PROBLEMS LOADING FILE 'C4::Message' # Tests were run but no plan was declared and done_testing() was not seen. # Looks like your test exited with 255 just after 2. FAILED--Further testing stopped: ***** PROBLEMS LOADING FILE 'C4::Message' make[1]: *** [test_dynamic] Error 255 -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From tomascohen at gmail.com Tue Nov 18 05:18:35 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 18 Nov 2014 04:18:35 +0000 Subject: [Koha-devel] RFC: LDAP login fallback Message-ID: If you take a look at bug 12831 [1] you will notice it reads as an important bug, but hasn't got much attention. The main reason the bug is stuck is that there's no consensus on what the fallback functionality use case(s) would be. My POV is that we should identify previous behaviour and restore it. As a non-LDAP user I think the logic should work as a simple fallback: Login fails (different reasons, take care of that as a future enhancement) => retry, with the local DB. It doens't seem difficult to implement. But as a non-expert LDAP user I don't know the usual use cases. Please share your use cases and/or comment here and on the bug itself so we have chances to fix this (bug?) for the release in less than two weeks. Thanks in advance Tom?s [1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12831 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at biblibre.com Tue Nov 18 10:51:01 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Tue, 18 Nov 2014 10:51:01 +0100 Subject: [Koha-devel] Koha 3.18 beta released In-Reply-To: <1416265453.20978.18.camel@zarathud.wgtn.cat-it.co.nz> References: <1416265453.20978.18.camel@zarathud.wgtn.cat-it.co.nz> Message-ID: Does someone have an idea on how this test could be implemented? 2014-11-18 0:04 GMT+01:00 Robin Sheat : > Tomas Cohen Arazi schreef op ma 17-11-2014 om 19:20 [+0000]: > > Debian packages for this beta will be available soon on the > > squeeze-dev repository. > > Any chance that the QA tools can be modified to do a test run without a > database active, this has been happening a lot lately and right now is > preventing a build of 3.18 beta: > > DBI connect('dbname=koha;host=localhost;port=3306','kohaadmin',...) > failed: Can't connect to local MySQL server through socket > '/var/run/mysqld/mysqld.sock' (2) at > /tmp/buildd/koha-3.17~git+20141118115103.6cd7c24c/blib/PERL_MODULE_DIR/C4/Context.pm > line 785 > > # Failed test 'use C4::Message;' > # at t/00-load.t line 33. > # Tried to use 'C4::Message'. > # Error: Can't connect to local MySQL server through socket > '/var/run/mysqld/mysqld.sock' (2) at > /tmp/buildd/koha-3.17~git+20141118115103.6cd7c24c/blib/PERL_MODULE_DIR/C4/Context.pm > line 785. > # Compilation failed in require at > /tmp/buildd/koha-3.17~git+20141118115103.6cd7c24c/blib/PERL_MODULE_DIR/C4/Letters.pm > line 27. > # BEGIN failed--compilation aborted at > /tmp/buildd/koha-3.17~git+20141118115103.6cd7c24c/blib/PERL_MODULE_DIR/C4/Letters.pm > line 27. > # Compilation failed in require at > /tmp/buildd/koha-3.17~git+20141118115103.6cd7c24c/blib/PERL_MODULE_DIR/C4/Message.pm > line 25. > # BEGIN failed--compilation aborted at > /tmp/buildd/koha-3.17~git+20141118115103.6cd7c24c/blib/PERL_MODULE_DIR/C4/Message.pm > line 25. > # Compilation failed in require at t/00-load.t line 33. > # BEGIN failed--compilation aborted at t/00-load.t line 33. > Bailout called. Further testing stopped: ***** PROBLEMS LOADING FILE > 'C4::Message' > # Tests were run but no plan was declared and done_testing() was not seen. > # Looks like your test exited with 255 just after 2. > FAILED--Further testing stopped: ***** PROBLEMS LOADING FILE 'C4::Message' > make[1]: *** [test_dynamic] Error 255 > > > -- > Robin Sheat > Catalyst IT Ltd. > ? +64 4 803 2204 > GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Tue Nov 18 13:13:22 2014 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 18 Nov 2014 13:13:22 +0100 Subject: [Koha-devel] Marseilles hackfest 2015, proposed date Message-ID: <546B37E2.4070000@biblibre.com> Hello, Is there anyone having a (major) problem with Marseilles hackfest occuring in March, 2nd-7th ? I had some feedback from some ppl, removing all "impossible" dates, this one seems OK. -- Paul Poulain, Associ?-g?rant / co-owner BibLibre, expert du logiciel libre pour les biblioth?ques BibLibre, Open Source software for libraries expert From tomascohen at gmail.com Tue Nov 18 13:23:37 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 18 Nov 2014 12:23:37 +0000 Subject: [Koha-devel] Marseilles hackfest 2015, proposed date References: <546B37E2.4070000@biblibre.com> Message-ID: I'd prefer by the end of March instead. El Tue Nov 18 2014 at 9:13:33, Paul Poulain () escribi?: > Hello, > > Is there anyone having a (major) problem with Marseilles hackfest > occuring in March, 2nd-7th ? > > I had some feedback from some ppl, removing all "impossible" dates, this > one seems OK. > -- > Paul Poulain, Associ?-g?rant / co-owner > BibLibre, expert du logiciel libre pour les biblioth?ques > BibLibre, Open Source software for libraries expert > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Tue Nov 18 14:15:43 2014 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 18 Nov 2014 08:15:43 -0500 Subject: [Koha-devel] Reminder: Koha general IRC meetings 19 November at 05:00 and 21:00 UTC Message-ID: The next Koha general IRC meetings will be taking place 19 November at 05:00 and 21:00 UTC First meeting: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+IRC+General+Meeting&iso=20141119T05 Second meeting: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+IRC+General+Meeting&iso=20141119T21 The first meeting has no volunteer to chair. Please volunteer if you'd like to attend the first instead of the second meeting. The agenda is here: http://wiki.koha-community.org/wiki/General_IRC_meeting_19_November_2014 Please add yourself to the "Apologies" section of the agenda if you know you will not be able to attend either meeting. Thanks, Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From mtompset at hotmail.com Tue Nov 18 14:33:46 2014 From: mtompset at hotmail.com (Mark Tompsett) Date: Tue, 18 Nov 2014 08:33:46 -0500 Subject: [Koha-devel] Koha 3.18 beta released In-Reply-To: References: <1416265453.20978.18.camel@zarathud.wgtn.cat-it.co.nz> Message-ID: Greetings, Jonathan already noticed bug 13274. I?ve signed off on your secondary patch. If someone could QA it, I think that would be a better fix. GPML, Mark Tompsett From: Jonathan Druart Sent: Tuesday, November 18, 2014 4:51 AM To: Robin Sheat Cc: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Koha 3.18 beta released Does someone have an idea on how this test could be implemented? 2014-11-18 0:04 GMT+01:00 Robin Sheat : Tomas Cohen Arazi schreef op ma 17-11-2014 om 19:20 [+0000]: > Debian packages for this beta will be available soon on the > squeeze-dev repository. Any chance that the QA tools can be modified to do a test run without a database active, this has been happening a lot lately and right now is preventing a build of 3.18 beta [SNIP] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wlEmoticon-smile[1].png Type: image/png Size: 1046 bytes Desc: not available URL: From chris at bigballofwax.co.nz Tue Nov 18 17:48:09 2014 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Wed, 19 Nov 2014 05:48:09 +1300 Subject: [Koha-devel] Koha 3.18 beta released In-Reply-To: References: <1416265453.20978.18.camel@zarathud.wgtn.cat-it.co.nz> Message-ID: On 19/11/2014 2:34 am, "Mark Tompsett" wrote: > > Greetings, > > Jonathan already noticed bug 13274. > I?ve signed off on your secondary patch. If someone could QA it, I think that would be a better fix. > That's a fix for the bug, however we want the qa tools to complain when these situations are created, so they don't make it into master. Jonathan, you could set a conf file that points to a non-existent db, and have qa tools run t/ with that, then back to the real conf for the rest. That should, in theory, do it. Chris Ch > GPML, > Mark Tompsett > > From: Jonathan Druart > Sent: Tuesday, November 18, 2014 4:51 AM > To: Robin Sheat > Cc: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Koha 3.18 beta released > > Does someone have an idea on how this test could be implemented? > > 2014-11-18 0:04 GMT+01:00 Robin Sheat : >> >> Tomas Cohen Arazi schreef op ma 17-11-2014 om 19:20 [+0000]: >> > Debian packages for this beta will be available soon on the >> > squeeze-dev repository. >> >> Any chance that the QA tools can be modified to do a test run without a >> database active, this has been happening a lot lately and right now is >> preventing a build of 3.18 beta > > > [SNIP] > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtompset at hotmail.com Tue Nov 18 22:27:18 2014 From: mtompset at hotmail.com (Mark Tompsett) Date: Tue, 18 Nov 2014 16:27:18 -0500 Subject: [Koha-devel] upcoming_digest?! Message-ID: Greetings, I was reading misc/cronjobs/advance_notices.pl and was trying to make sense of where $upcoming_digest is set. I think there must be some side-effect obscuring the code. I was wondering if a second pair of eyes might find it. I was trying to determine how $digest->{email} gets set for the from_address call to C4::Letters::EnqueueLetter. GPML, Mark Tompsett -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippe.blouin at inlibro.com Tue Nov 18 22:48:16 2014 From: philippe.blouin at inlibro.com (Philippe Blouin) Date: Tue, 18 Nov 2014 16:48:16 -0500 Subject: [Koha-devel] Any secret for updatedatabase.pl? In-Reply-To: References: Message-ID: <546BBEA0.2010208@inlibro.com> Hol? Koha! After so many rebasing nightmares only caused by updatedatabase.pl, I was wondering how you are doing your insertions in that file to make things easier. Git is a bit dumb by default regarding that file, so I was wondering if you knew of any way to write the insertion to always show at the right place in a rebase. Of course, maybe it's just hopeless, in which case may I ask why we are doing it this way? Locally, I moved from that file and instead create a different file for each update (update_XXXX_long_description), and have my script run them all in sorted order. I could see that used in the community, with a subdirectory for each version. I can imagine it would have a very small impact on performance, but it'd be sooo much easier to rebase. Thanks, Blou Rebase, rebase, rebase.... From chris at bigballofwax.co.nz Tue Nov 18 22:51:35 2014 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Wed, 19 Nov 2014 10:51:35 +1300 Subject: [Koha-devel] Any secret for updatedatabase.pl? In-Reply-To: <546BBEA0.2010208@inlibro.com> References: <546BBEA0.2010208@inlibro.com> Message-ID: On 19 November 2014 10:48, Philippe Blouin wrote: > Hol? Koha! > After so many rebasing nightmares only caused by updatedatabase.pl, I was > wondering how you are doing your insertions in that file to make things > easier. > Git is a bit dumb by default regarding that file, so I was wondering if > you knew of any way to write the insertion to always show at the right > place in a rebase. > > Of course, maybe it's just hopeless, in which case may I ask why we are > doing it this way? > > Locally, I moved from that file and instead create a different file for > each update (update_XXXX_long_description), and have my script run them > all in sorted order. I could see that used in the community, with a > subdirectory for each version. I can imagine it would have a very small > impact on performance, but it'd be sooo much easier to rebase. > > There's a patch to do just that, http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13068 you could test and sign off Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at biblibre.com Wed Nov 19 09:22:01 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Wed, 19 Nov 2014 09:22:01 +0100 Subject: [Koha-devel] upcoming_digest?! In-Reply-To: References: Message-ID: Hello Mark, I believe that you are the good candidate to sign off on bug 13240 ( advanced_notices.pl contains code obfuscation) :) Cheers, Jonathan 2014-11-18 22:27 GMT+01:00 Mark Tompsett : > Greetings, > > I was reading misc/cronjobs/advance_notices.pl and was trying to make > sense of where $upcoming_digest is set. I think there must be some > side-effect obscuring the code. I was wondering if a second pair of eyes > might find it. I was trying to determine how $digest->{email} gets set for > the from_address call to C4::Letters::EnqueueLetter. > > GPML, > Mark Tompsett > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Wed Nov 19 13:03:28 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 19 Nov 2014 12:03:28 +0000 Subject: [Koha-devel] String freeze shifted, till friday Message-ID: Hi, I'll be pushing stuff today and tomorrow, but will be dealing with some other stuff at work too, so I'm moving string freeze to friday. The strings have actually been updated for the beta release a couple days ago (please test! :-D) and there won't be too many changes. Sorry for the inconvenience. Best regards Tom?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Wed Nov 19 15:40:35 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 19 Nov 2014 14:40:35 +0000 Subject: [Koha-devel] Koha YouTube channel Message-ID: Hi, for uploading the recent KohaCon14 video, I'be been playing with YouTube (how to create a channel, add subtitles, etc) because I didn't want to 'own' the video (it was created by/for the community). So I created a YouTube channel named Koha. Later I found a way to grant Liz the rights to manage it (she already does with the community site). I'm not sure we will make use of the channel soon, for other purposes (there are dozens of videos for Koha spreaded all around). But if you have any comments, or stuff to discuss/add to it, please let us know, or just put them on this thread. Regards Tom?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From indradg at gmail.com Wed Nov 19 15:54:36 2014 From: indradg at gmail.com (Indranil Das Gupta) Date: Wed, 19 Nov 2014 14:54:36 +0000 Subject: [Koha-devel] Koha YouTube channel In-Reply-To: References: Message-ID: On Wed, Nov 19, 2014 at 2:40 PM, Tomas Cohen Arazi wrote: > Hi, for uploading the recent KohaCon14 video, I'be been playing with YouTube > (how to create a channel, add subtitles, etc) because I didn't want to 'own' > the video (it was created by/for the community). > > So I created a YouTube channel named Koha. +1 Tomas -- Indranil Das Gupta Phone : +91-98300-20971 Blog : http://indradg.randomink.org/blog IRC : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org From kohanews at gmail.com Wed Nov 19 19:49:14 2014 From: kohanews at gmail.com (Koha News) Date: Wed, 19 Nov 2014 10:49:14 -0800 Subject: [Koha-devel] Call for news: November 2014 Message-ID: <546CE62A.4030900@gmail.com> Fellow Koha users ~ We're collecting news for the November newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- * News items can be of any length. * Anything and everything Koha. * Submit by the 26th. If you are working on an interesting project or development related to Koha, please let us know and we'll include it in the development section. -- Chad Roseburg Joanne Dillon Editors, Koha Newsletter From kohanews at gmail.com Wed Nov 19 19:50:20 2014 From: kohanews at gmail.com (Koha News) Date: Wed, 19 Nov 2014 10:50:20 -0800 Subject: [Koha-devel] Call for development news: November newsletter Message-ID: <546CE66C.2050703@gmail.com> Koha Development community ~ If you have any bugs or projects you'd like us to highlight or promote in the October newsletter, please let us know. Maybe it'll attract some additional eyes, testers and sign-offs. k o h a news AT gmail dot com Thank you! -- Chad Roseburg Joanne Dillon Editors, Koha Newsletter From mtompset at hotmail.com Wed Nov 19 20:27:09 2014 From: mtompset at hotmail.com (Mark Tompsett) Date: Wed, 19 Nov 2014 14:27:09 -0500 Subject: [Koha-devel] Sign off request... Message-ID: Greetings, I was hoping that someone might look at http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11592 opac detail scripts do not respect MARC tag visibility The differences in what appears between Normal View and Marc View (and potentially ISBD view) differs even if some things are marked as not visible. It?s too late for 3.18, but it would be great to get a sign off. I just rebased it. There is a pretty good test plan that should be easy enough to follow. GPML, Mark Tompsett -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wlEmoticon-smile[1].png Type: image/png Size: 1046 bytes Desc: not available URL: From tomascohen at gmail.com Thu Nov 20 19:04:28 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Thu, 20 Nov 2014 18:04:28 +0000 Subject: [Koha-devel] Tidying .mailmap for release Message-ID: I've attached a patch with small changes to the .mailmap file on the prohect source tree. [1] The file is important (at least) for those not showing correctly on the release notes. Please check the release notes [2] and if you find any trouble add a followup or just email me. And sign the previous patches of course :-D The last mappings section is important for companies or institutions to be attributed the work from their people. For example: maps the personal email I use (on Gmail) to my institutional one, so the script that generates the release notes can map the insitutional domain to the proper institution name. That said, please provide feedback on this last part too, the way you want your institution to show, and what domains should be mapped. Thanks in advance. [1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13314 [2] http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=misc/release_notes/release_notes_3_18_0.txt;h=51b61c086900d6a0786818da91cac1c5095fae3d;hb=refs/heads/master#l1045 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Fri Nov 21 05:29:45 2014 From: dcook at prosentient.com.au (David Cook) Date: Fri, 21 Nov 2014 15:29:45 +1100 Subject: [Koha-devel] Any secret for updatedatabase.pl? In-Reply-To: References: <546BBEA0.2010208@inlibro.com> Message-ID: <004d01d00543$c71c6920$55553b60$@prosentient.com.au> I started looking at DBIx::Class::Schema::deploy() and DBIx::Class::Schema::Versioned::upgrade() the other day, as I would love us to move away from kohastructure.sql and updatedatabase.pl. Galen?s existing work is available on Bugzilla http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11390 , as are some of my comments about my investigations into using these methods. I?m having a few minor issues at the moment, but hopefully I?ll resolve them soon. DBIx::Class::Schema has a method called create_ddl_dir(), which lets you dump the DBIC schema out as a SQL file. It also allows you to create SQL ?diffs?, which operate as version updates. So the method will save a full dump, plus the diff. That was you can run incremental updates in sorted order, or just re-deploy the entire database at any specific version. Of course, it still requires us to write a script to handle when these things occur, but that should be easy. That said, it still runs into the same problems as bug 13068. Namely, it?s just SQL updates. If we need anything more complex using Perl, I think we?ll need to write specific update scripts, or a different kind of ?updatedatabase.pl? which uses DBIx::Class::Schema::Versioned for the heavy lifting and itself for more of the delicate/sophisticated updates. Anyway, that?s my 2 cents : ) David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Chris Cormack Sent: Wednesday, 19 November 2014 8:52 AM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Any secret for updatedatabase.pl? On 19 November 2014 10:48, Philippe Blouin > wrote: Hol? Koha! After so many rebasing nightmares only caused by updatedatabase.pl , I was wondering how you are doing your insertions in that file to make things easier. Git is a bit dumb by default regarding that file, so I was wondering if you knew of any way to write the insertion to always show at the right place in a rebase. Of course, maybe it's just hopeless, in which case may I ask why we are doing it this way? Locally, I moved from that file and instead create a different file for each update (update_XXXX_long_description), and have my script run them all in sorted order. I could see that used in the community, with a subdirectory for each version. I can imagine it would have a very small impact on performance, but it'd be sooo much easier to rebase. There's a patch to do just that, http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13068 you could test and sign off Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Fri Nov 21 05:41:35 2014 From: dcook at prosentient.com.au (David Cook) Date: Fri, 21 Nov 2014 15:41:35 +1100 Subject: [Koha-devel] Sign off request... In-Reply-To: References: Message-ID: <005201d00545$6e53eaa0$4afbbfe0$@prosentient.com.au> I?m really interested in this one, but Tomas raised a good point the other day suggesting that we should filter the MARC as it comes out of the source (i.e. Zebra or MySQL) using XSLT (dynamically generated based on framework hidden values). Although now that I look at your patch again, I?m reminded that we don?t necessarily know the context we?re in when we?re retrieving MARC? I suppose when we retrieve MARC via Zebra, we generally know what context we?re in. So we can apply a filter quite easily. If we were to use the XSLTs, we?d need to make sure we?re always getting our MARC data using the same method (and that we?re able to hand the context to it). Hmm? Quick question. Does your patch filter search results for the OPAC? I don?t see a mod there which would do that? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Mark Tompsett Sent: Thursday, 20 November 2014 6:27 AM To: koha-devel at lists.koha-community.org Subject: [Koha-devel] Sign off request... Greetings, I was hoping that someone might look at http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11592 opac detail scripts do not respect MARC tag visibility The differences in what appears between Normal View and Marc View (and potentially ISBD view) differs even if some things are marked as not visible. It?s too late for 3.18, but it would be great to get a sign off. I just rebased it. There is a pretty good test plan that should be easy enough to follow. GPML, Mark Tompsett -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1046 bytes Desc: not available URL: From mtompset at hotmail.com Fri Nov 21 06:09:04 2014 From: mtompset at hotmail.com (Mark Tompsett) Date: Fri, 21 Nov 2014 00:09:04 -0500 Subject: [Koha-devel] Hiding... In-Reply-To: <005201d00545$6e53eaa0$4afbbfe0$@prosentient.com.au> References: <005201d00545$6e53eaa0$4afbbfe0$@prosentient.com.au> Message-ID: Greetings, There are different ?hiding? actions. Let?s see if I remember them all. 1) 942$n This is at the biblio-level. 2) System preference: OpacHiddenItems This can be used to hide on any field at an item-level. 3) Home ? Administration ? MARC frameworks ? {name} framework structure ? Tag {tag number} subfield structure ? Edit subfields constraints This is used to affect visibility: OPAC, Intranet, Editor, Collapsed, Flagged? Bug 11592 refers to method 3. David Cook wrote: > I?m really interested in this one, but Tomas raised a good point the other > day > suggesting that we should filter the MARC as it comes out of the source > (i.e. Zebra or MySQL) using XSLT (dynamically generated based on framework > hidden values). I?m not sure this is applicable in this hiding case. It would likely be valid in case (1) and perhaps case (2). David Cook asked: > Does your patch filter search results for the OPAC? I don?t see a mod > there which would do that? This is not related to search results. It is about opac details in normal, marc, and isbd views. Hopefully this clarifies. And if I?m wrong, someone can explain why (e.g. XSLT does apply, because ...). GPML, Mark Tompsett From pianohacker at gmail.com Fri Nov 21 19:25:28 2014 From: pianohacker at gmail.com (Jesse) Date: Fri, 21 Nov 2014 11:25:28 -0700 Subject: [Koha-devel] Fwd: Streamlining frontend development in Koha In-Reply-To: References: Message-ID: I've been working on Rancor, a professional MARC editor for Koha sponsored by ByWater and DGI, for the past year or so. As Rancor has a lot more client-side complexity than many other parts of the staff interface, I've run into some major frustrations. I have a proposed solution for them, and would like feedback from both developers and translators: Let's rewrite Koha in GWT! But seriously. The issues come down to translation. Making cleanly translatable JavaScript frontend code using Koha's current system requires a lot of finagling and ugly syntax, especially for any complicated string. There are two problems. Problem One: For example, displaying "You have checked out X books, Y of which are on hold" is frustrating to impossible for either the developer or translator: _("You have checked out ") + X + _(" books, ") + Y + _(" of which are on hold") is easy for a developer to write, but gives the poor translator three separate strings to translate. The commonly given solution is to rewrite this as: _("Books checked out: ") + X + _("Books on hold") + Y which works, but is a bit less elegant, and not always realistic. An informal best practice that has some precedent in the OPAC and Datatables is to use named placeholders in the string: _("You have checked out __X__ books, __Y__ of which are on hold").replace("__X__", X).replace("__Y__", Y) This is good, but currently has to be rewritten for every translated string. I'd like to propose a syntax like the following: _$("You have checked out $1 books, $2 of which are on hold", X, Y) or _$("You have checked out $X books, $Y of which are on hold", {X: X, Y: Y}) with a slight preference for the former. Either approach allows translators to reorder substitutions as needed. The exact details of the syntax are up for debate, but something that can be implemented once, thrown into staff-global.js, and used everywhere is the goal. Either approach would be treated the same as: _("You have checked out $1 books, $2 of which are on hold") for the purposes of generating .po's and creating translated templates from existing .po's. Problem two: Currently, for JavaScript code to contain translated strings, it must be placed within a .tt or .inc. This is a historic limitation of the translation scripts (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4503). The stated reasons for not fixing it, besides the hairiness of the translation scripts, are that a) most JavaScript code has been moved to non-language specific directories and b) there are property-based translation systems available for JavaScript (see the datatables-strings.inc file for an example of how the latter works). Here are my reasons for disagreeing with these two points: a) Keeping most JavaScript code non-language-specific is a very laudable goal, both in terms of separation of concerns and deduplication of files in multi-language installs. I believe that the translation system should allow for translation of strings in .js files, however. Despite factoring out many modules and pieces of UI infrastructure using Require.JS, Rancor is currently sitting at ~1200 lines of code that deal with showing error/informational messages to the user, all of which has to be in a .tt or .inc in the current system. This is untenable for any complex JS code. b) While this is more of a matter of taste, I do not like the properties-based translation system. For one thing, it punts the above problem to a solution like is used for datatables, with the translation strings in a .inc containing a single