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

Re: [Koha-devel] [Koha] RFC for MARC holdings record support
by Ere Maijala 21 Feb '19

21 Feb '19

Good morning! Thanks for the feedback. I added a note to the RFC about embedded holdings in bibliographic records. They cover a lot of needs and we have considered embedding the holdings, but there are issues if there are multiple holdings. Regards, Ere Sebastian Hierl kirjoitti 5.4.2018 klo 10.08: > Good morning! > > I think that the feature would provide added flexibility, in particular > for monographic series and periodicals. Institutions who currently work > with an ILS that has holdings records would want to see the same in > Koha, should they be considering Koha. We currently use the 866 to > display holdings information, thus I don't see this as essential, but it > would be a useful enhancement. > > Greetings from Rome, > Sebastian > > -- > Sebastian Hierl, Ph.D. > Drue Heinz Librarian, Arthur & Janet C. Ross Library > American Academy in Rome > Via Angelo Masina 5 > 00153 Rome > Italy > > T: +39 06 5846 417 > F: +39 06 5810 788 > > On Wed, Apr 4, 2018 at 5:11 PM, Nick Clemens <nick(a)bywatersolutions.com > <mailto:nick@bywatersolutions.com>> wrote: > > There was some discussion of this at the IRC meeting today, > forwarding on > to the general list as well for librarian input/feedback > > On Tue, Apr 3, 2018 at 3:33 AM Ere Maijala <ere.maijala(a)helsinki.fi > <mailto:ere.maijala@helsinki.fi>> wrote: > > > Hi Katrin, > > > > Thanks for the comments. I'll try to clarify the RFC. > > > > --Ere > > > > Katrin Fischer kirjoitti 1.4.2018 klo 17.32: > > > Hi Ere, > > > > > > thx for your work on that! I've added some comments and > questions at the > > > bottom of the RFC page. I think key is to break the big > development down > > > into multiple steps that can be easily tested. > > > > > > Katrin > > > > > > > > > On 26.03.2018 12:58, Ere Maijala wrote: > > >> Hi Everyone, > > >> > > >> I've written an RFC for adding support for MARC holdings records, > > >> available here: > > >> > <https://wiki.koha-community.org/wiki/MARC_Holdings_Records_RFC > <https://wiki.koha-community.org/wiki/MARC_Holdings_Records_RFC>>. I'd > > >> be grateful for any feedback on this. I know there have been some > > >> initiatives to add (back) holdings records, but this proposal > is a bit > > >> different in that it relies on the MARC format and I already > have it > > >> working in a local custom branch apart from OPAC support. > > >> > > >> Regards, > > >> Ere > > >> > > > > > > _______________________________________________ > > > Koha-devel mailing list > > > Koha-devel(a)lists.koha-community.org > <mailto:Koha-devel@lists.koha-community.org> > > > > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > <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/ > <http://bugs.koha-community.org/> > > > > -- > > Ere Maijala > > Kansalliskirjasto / The National Library of Finland > > _______________________________________________ > > Koha-devel mailing list > > Koha-devel(a)lists.koha-community.org > <mailto:Koha-devel@lists.koha-community.org> > > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > <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/ <http://bugs.koha-community.org/> > > > -- > Nick Clemens > Sonic Screwdriver (Development Support) > ByWater Solutions > IRC: kidclamp > _______________________________________________ > Koha mailing list http://koha-community.org > Koha(a)lists.katipo.co.nz <mailto:Koha@lists.katipo.co.nz> > https://lists.katipo.co.nz/mailman/listinfo/koha > <https://lists.katipo.co.nz/mailman/listinfo/koha> > > -- Ere Maijala Kansalliskirjasto / The National Library of Finland

5 8

Centralize and move to gitlab
by Jonathan Druart 08 Aug '18

08 Aug '18

Hi devs, (Spoiler: I am not talking about a move from bugzilla to gitlab for the Koha git repo) Just a quick comment: gitlab has the ability to move projects with all the issues. >From the export page of a project, they say: """ The following items will be exported: Project and wiki repositories Project uploads Project configuration including web hooks and services Issues with comments, merge requests with diffs and comments, labels, milestones, snippets, and other project entities """ So that will be easy to move (already discussed with Chris, will do in May) * koha-community-devs-users/kohadocs to koha-community/kohadocs * https://gitlab.com/koha-dashboard/koha-dashboard to koha-community/koha-dashboard And the ones from github too: * joubu/koha-misc4dev to koha-community/koha-misc4dev * Koha-Community/qa-test-tools to koha-community/qa-test-tools Then, maybe: koha-testing-docker koha-release-notes kohadevbox koha-howto The idea is to centralize our things in one place, ease the PRs and the ability to clone/fork keeping the visibility on what is the reference (account 'koha-community'). I would also like to generate a CI configuration for some of them. CI file for Koha: https://tree.taiga.io/project/joubu-koha-rm-1711/us/146 (I am going to submit that on bugzilla soon) CI file for the manual: https://gitlab.com/koha-community-devs-users/kohadocs/blob/master/.gitlab-c… Any pros/cons? Cheers, Jonathan (No troll please)

11 16

Turn Koha into a Mojolicious application
by Julian Maurice 16 May '18

16 May '18

Hi all, I've been playing with Mojolicious recently and I thought it would be great if Koha was a Mojolicious application (like the REST API already is). Some pros: - Easier deployment - Testable CGI scripts (Test::Mojo) - All Mojolicious features (routing, commands, plugins, ...) - Koha already uses Mojolicious, so there's no new dependency. I wrote a POC here : https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20582 I'd like to gather opinions on it, and for that I want to try something new. I created a "Koha" group on framavox.org, an instance of Loomio (a free software designed to make decisions). In this group there is a discussion named "Bug 20582 - Turn Koha into a Mojolicious application" where you can add comments. And in this discussion there is a proposal where you can vote (Agree, Abstain, Disagree, Block) and add a reason for your vote Group link : https://framavox.org/g/iAKeRC8Q/koha Discussion link : https://framavox.org/d/tTGf0Bzd/bug-20582-turn-koha-into-a-mojolicious-appl… To keep things clean, please - use the framavox group to discuss about the idea of turning Koha into a Mojolicious app (not the implementation) - use the bug report to discuss about the implementation - reply to this mail for anything else (feedback about framavox.org for instance) Thanks -- Julian Maurice <julian.maurice(a)biblibre.com> BibLibre

1 2

Official Docker image
by Tomas Cohen Arazi 12 May '18

12 May '18

Hi everyone, on the CI front, I have recently introduced (successfully) the broad use of Docker images to run the full test suite. This project, named koha-testing-docker [1], evolved into a usable development environment too. Right now I'm trying to spend some time on porting kohadevbox things into it. This Docker image is built and published automatically by our Jenkins server, and then used in the three nodes we have to run the tests. We also have a Docker image for building koha-* packages wherever we need to (yes, we want to automate this, and properly test the generated packages using the CI infrastructure). [2] With this knowledge, and the infrastructure part of it solved, I would like to start publishing an official Docker image of Koha. Once we have this, the koha-testing-docker tools would be rebuilt on top of it. I raise the subject in light of recent discussions about supported OSs, Perl versions and dependencies. [1] https://gitlab.com/koha-community/koha-testing-docker [2] https://gitlab.com/tomascohen/koha-dpkg-docker -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

6 12

Proposed change to standard page markup (Bug 20670)
by Owen Leonard 02 May '18

02 May '18

In case people have feelings about markup, I wanted to share Bug 20670, "Bug 20670 - Add markup and standard classes for sidebars and main content areas." https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20670 The conversion of staff client templates to Bootstrap grids is continuing, and I think it would be helpful to have markup which defines the "main content" from the sidebar on two-column layout pages. If anyone has comments or concerns, or would like to kibitz class names, please feel free! -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

4 6

For larger support companies
by Cab Vinton 26 Apr '18

26 Apr '18

Koha developers may be contrary enough that this wouldn't work, but still a fun idea: https://github.com/codedance/Retaliation Video here -- https://www.youtube.com/watch?v=1EGk2rvZe8A Many possible applications :-) Squirrel on your birdfeeder, child in the cookie jar, ... Cab Vinton Plaistow Public Library

5 4

Koha 17.05.11 release
by Fridolin SOMERS 26 Apr '18

26 Apr '18

The Koha community is proud to announce the release of Koha 17.05.11. This is a maintenance release. The full release notes are available at https://koha-community.org/koha-17-05-11-release/ Regards, -- Fridolin SOMERS <fridolin.somers(a)biblibre.com> BibLibre, France - software and system maintainer

1 0

Re: [Koha-devel] Official Docker image
by Benjamin Rokseth 24 Apr '18

24 Apr '18

>Hi everyone, on the CI front, I have recently introduced (successfully) the >broad use of Docker images to run the full test suite. This project, named >koha-testing-docker [1], evolved into a usable development environment too. >Right now I'm trying to spend some time on porting kohadevbox things into >it. Great news, Tomas! That will definitely ease development and sandboxing. Probably also migration to elasticsearch. > This Docker image is built and published automatically by our Jenkins > server, and then used in the three nodes we have to run the tests. > We also have a Docker image for building koha-* packages wherever we need > to (yes, we want to automate this, and properly test the generated packages > using the CI infrastructure). [2] Since you're already on gitlab, why not use it for CI instead? Then you could have all code in one place. Retire mr Jenkins, only thing we miss is the Chuck Norris plugin. >With this knowledge, and the infrastructure part of it solved, I would like >to start publishing an official Docker image of Koha. Once we have this, >the koha-testing-docker tools would be rebuilt on top of it. And it gets even better! Let us know if we can help Benjamin Rokseth Deichman Public Library

6 9

z39.50 server
by Johan Seyfferdt 23 Apr '18

23 Apr '18

Hello I am busy setting up a z39.50 server. After a lot of struggles the last couple of days, I was able to use it once successfully, and then I just rebooted the system, and then it didn't work anymore.... I am receiving this error message, help will be very appreciated! Johan Seyfferdt Connecting...OK. Sent initrequest. Connection rejected by v3 target. ID : 81 Name : GFS/YAZ Version: 4.2.30 98864b44c654645bc16b2c54f822dc2e45a93031 Init response contains 1 otherInfo unit: 1: otherInfo unit contains 1 diagnostic: 1: code=1 (Permanent system error), addinfo='' Options: search present triggerResourceCtrl namedResultSets Elapsed: 0.001400

1 0

Koha Core anyone?
by Benjamin Rokseth 20 Apr '18

20 Apr '18

Community hackers, on hackfest I got introvertly enthusiastic about the concept of a Koha Core, and about time I shared some thoughts. Background: Deichman (Oslo Public Library) is heavily leaning on bleeding edge Koha development (REST, Objects, Auth, NCIP and such) and, like at least some others, maintain a lot of local patches to tweak Koha into our users needs. Some are probably interesting to Community, others not. Now to keep everything in sync with Community would be amazing, but not likely to happen anytime soon. Great work has been done on refactoring Koha (new namespace, Koha Objects and REST api, etc.), but we'd like to suggest one more - a Koha core. The idea is simple: borrow from object oriented languages, java, or actually more ruby, since we're dealing with a dynamic language, use class/module inheritance and method overrides. Perl has the "use parent" concept which simplifies inheritance/subclassing and allows for nested overrides. As an example we refactored the current circulation in Koha, since this for us is the core functionality that we depend on and need to hook our local quirks on top of. An attempt to illustrate: +------------+ | Core::Main | +--^---------+ | +--+----------------+ | Core::Prefs | | Core::Exceptions | +-----------------------+ | Core::Circulation <-----+------+---| Deichman::Circulation | | ... | | | +---^-------------------+ +-------------------+ | | | | | | +------------------+------+ +--------------------------+ | Core::Circulation::SIP | |Deichman::Circulation::SIP| +------------------------------------------------------------+ | use parent qw( | Deichman::Circulation +----------------------+ Core::Circulation::SIP | Core::Circulation::UI| ) +----------------------+ | ~ * Core::Main is simply an empty class that act as a parent for any child, including Core::Circulation. * Core::Circulation has a constructor that takes koha objects item and library, optionally patron and sysprefs overrides. It can have accessors such as checkout, messages and other things needed for intra, SIP or whatever. It has methods Checkin, Checkout and Renew, amongst others. * then: Deichman::Circulation::SIP in this example is a local override that inherits from parents Deichman::Circulation and Core::Circulation::SIP now the beauty of this is that Deichman::Circulation::SIP can override anything (even the constructor) without touching any of the core code, and perl will traverse the inheritance tree until it finds the first matching constructor and method. Pros: - simpler, more readable and more reusable code. - local adaptations are easy to hande, and reusable for others - the slight overhead of using blessed objects and inheritance is easily gained by the fact that any operation will only need fetching Koha objects once (item,library,patron etc) instead of refetching them numerous times spread across methods calls and loops - way less db calls if done right, faster Koha - no more C4::Context, hopefully - systempreferences can be dramatically reduced, since most of them are about overrides anyways - can be done incrementally, replacing one functionality at a time cons: - refactoring doesnt make end users happy (but needs to be done in any case) - a bit of work to keep templates happy - requires a basic understanding of oop So to sum up: We already have a working example for circulation (though not in production) that we can demonstrate. It reimplements basically the entire C4::Circulation, just some small parts missing. So it can be done. But we'd love to hear second opinions from the community! We know the fear for breaking changes, but its neither scary or complicated to implement! Benjamin Rokseth Oslo Public Library

7 11