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

log file of activities for admin of koha in the library
by rania azad mohammed 18 Jan '17

18 Jan '17

Dear We are 3 admins in the library working on shifts in the library, each of us log-in during her time. I want a report or log file to see all the activities of each admin during a specific day. is there such report or file? I tried to find it using the wiki but hopeless -- *Regards,* *Rania Azad |* Library Manager Library Department http://library.auis.edu.iq/ The American University of Iraq, Sulaimani Office: *B-G-32* Ext *1219*

7 13

Zebra: the 'elements zebra::snippet' doesn't work
by Tajoli Zeno 11 Jan '17

11 Jan '17

Hi all, I trying to check my indexes in Zebra. My setup: OS: Debian jessie Koha: 3.20.7 [manual install] Zebra: 2.0.61 [install from IndexData repo] Format: UNIMARC Probably the fact that I use unimarc is relevant but I don't understand where. I do the debug described here: http://wiki.koha-community.org/wiki/Troubleshooting_Zebra#Why_does_a_search… The result of a working search is: Diagnostic message(s) from database: [25] Specified element set name not valid for specified database -- v2 addinfo 'zebra::snippet' but my ../etc/zebradb/retrieval-info-bib-dom.xml is correct: <?xml version="1.0" encoding="UTF-8"?> <retrievalinfo xmlns="http://indexdata.com/yaz"> <retrieval syntax="unimarc" name="F"> <backend syntax="xml" name="marc"> <marc inputformat="xml" outputformat="marc" inputcharset="utf-8" outputcharset="utf-8"/> </backend> </retrieval> <retrieval syntax="unimarc" name="B"> <backend syntax="xml" name="marc"> <marc inputformat="xml" outputformat="marc" inputcharset="utf-8" outputcharset="utf-8"/> </backend> </retrieval> <retrieval syntax="xml" /> <retrieval syntax="xml" name="index"/> <retrieval syntax="xml" name="marc" identifier="info:srw/schema/1/marcxml-v1.1"/> <retrieval syntax="xml" name="marcxml" identifier="info:srw/schema/1/marcxml-v1.1"/> <retrieval syntax="xml" name="zebra::*"/> </retrievalinfo> Do I need to check in other places for the setup of ' zebra::snippet' ? Bye Zeno Tajoli -- Zeno Tajoli / SVILUPPO PRODOTTI/ - Automazione Biblioteche Email: z.tajoli(a)cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)

5 13

INSTALL.debian is outdated
by Jonathan Druart 27 Nov '16

27 Nov '16

2015-11-11 22:37 GMT+00:00 Robin Sheat <robin(a)catalyst.net.nz>: > Aparrish schreef op wo 11-11-2015 om 08:13 [-0700]: >> I followed the official instructions: >> http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=INSTALL.debian;hb… > > We need to delete those, they're from 2012 and are super out of date. Shall we 1) delete them, 2)replace them with the content of the wiki page or 3) just put a link to the wiki page?

12 23

Introduce the use of Grunt or Gulp?
by Owen Leonard 13 Oct '16

13 Oct '16

I would very much like to start using some kind of build tool for front-end assets in Koha. The ones I've encountered are Grunt and Gulp: Grunt: http://gruntjs.com/ Gulp: http://gulpjs.com/ I have some experience with Grunt, and have heard good things about Gulp. Has anyone else used either in their non-Koha projects? Adopting them would introduce a little more complexity to the process of making client-side changes to Koha, and to be honest I'm not sure of the right way to incorporate the tools into our workflow. What I see as the advantages: - Automatic linting, minification, and concatenation of CSS and JS - Potentially, automatic compression of images and contruction of image sprites - Overall performance improvements from the above Disadvantages: A new process to learn for those wanting to contribute front-end modifications. A new set of dependencies for front-end developers (Node.js etc). If there is interest I'd be happy to submit a patch introducing the process to the OPAC as a demonstration. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

10 22

How do we find consensus on interface changes?
by Owen Leonard 06 Oct '16

06 Oct '16

Do we need a procedure for getting consensus on Koha interface changes? I'm thinking about this issue in part because of a couple of interface changes I've been working on. One for Bug 16421: Move hold edit actions into dropdown menu https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16421 (screenshot: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51111) ...and another for Bug 11375: Patron permission names are untranslatable https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11375 (screenshot: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51847) When proposing a change like that should there be a more inclusive process than getting one sign-off and one QA approval? If so, how do we decide what kind of changes require wider approval? How do we solicit opinions from a wider audience? Or is the process working well as-is? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

9 15

Sessions terminated at random under Plack
by Magnus Enger 08 Sep '16

08 Sep '16

Dear Community, I am seeing a strange problem, and I'm not sure where to start digging. I have a (big) server with 30 odd Koha instances. One of these instances has been running under Plack for quite some time now, without any problems. Two new instances have a problem where librarians get kicked out of the intranet more or less frequently, with a message like "Your session has expired, please log in again". We had this problem on 3.22.x. After upgrading to 16.05.02 it went away. After upgrading to 16.05.03 last night it came back again. It is not consistent. Earlier today it looked like you could log in, click on a link, get thrown out, login again and then things would work. Later users got kicked out every single time they clicked on a link in the intranet. All sites are running off the official Debian packages, on the same server. Memcached is installed, enabled and used for storing sessions. Switching SessionStorage to the DB does not stop the problem. Stopping and disabling Plack for these two instances makes the problem go away. I have not found anything interesting in Plack or Apache logs. Anyone got a hunch what might be causing this? Or where to start digging? Best regards, Magnus

4 10

Serious problem
by Mark Tompsett 06 Sep '16

06 Sep '16

Greetings, Take the following steps: check out, check in, restart mysql server, check out, check in... old_issues bug! This is because we delete from issues (among other tables) when we move it to old_issues and "InnoDb forgets its highest auto_increment after server restart". Any ideas on the best way to solve it? Should I resurrect my https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10454 ? GPML, Mark Tompsett

5 16

Re: [Koha-devel] What's on in Koha devel #3 (RESTful API)
by Marcel de Rooy 05 Sep '16

05 Sep '16

> = RESTful API = > I also would like to know who is willing to maintain this code? For instance on bug 16330 (REST API: add routes to add, update and delete > patrons) the delete route is calling > # check if loans, reservations, debarrment, etc. before deletion! > my $res = $patron->delete > So no check is done from the API. > But if bug 16907 (Move DelMember and HandleDelBorrower to > Koha::Patron) is pushed, $patron->delete will take care of the holds, etc. My question is simple: are we expecting from devs, signoffers and > QAers to update and maintain these routes? > Or a dedicated person will update them before each release? Just formally, I would say that if the community agreed to push this code, the community should maintain it too. We should keep the code base in a consistent state. Similarly, we should prevent redundant code: the checks for deleting a patron in one place, etc. If we are on a road now creating a lot of redundant code between Koha/REST and Koha/Objects, we should re-evaluate first and not just keep pushing more code. Is this mainly a communication issue? Which goals do we want to achieve? Should our scripts go via REST some day and should all business logic remain in Objects? Etc. etc. Marcel

10 18

Release unification: Security fixes and releases
by Mirko Tietgen 04 Sep '16

04 Sep '16

Hello everyone, can we maybe find a consistent way of labelling releases/ fixes "security"? All new releases contain XSS patches… - 3.20 and 3.22 are labelled "security release" in the emails/ release notes - 16.05 is not - 16.05 and 3.20 list the fixes under the headline "Critical bugs/ Koha - 3.22 as "Security bugs fixed" on top of the list - 3.22 features "security" in the release notes headline (and so in the URL in Wordpress) - The others don't The first question is probably… - Is a security release only a special release in between the regular schedule or - is a security release everything that contains patches with security fixes? It seems to me that the second option is more common within the Koha community and personally I'd prefer it. We should shout it at people and make them upgrade. To underline that intention, showing the security fixes seperately on top of the release notes makes sense to me. I propose to… - use the label "security release" in the release notes headline and first paragraph (and Wordpress URL) - mention number of security fixes seperately - display them under the headline "Security bugs fixed" on top of the list …whenever there are patches from "Koha security" in a release. Basically that is what we have in the 3.22.10 release notes: https://koha-community.org/koha-3-22-10-security-release/ Does that make sense? Any reasons not to do it? Is it harming artistic freedom of RMaints? Would it complicate stuff a lot? I think it would be a good thing to have some consistency here. Cheers, Mirko -- Mirko Tietgen mirko(a)abunchofthings.net http://koha.abunchofthings.net http://meinkoha.de

4 4

Koha::* business objects authorization check
by Tomas Cohen Arazi 31 Aug '16

31 Aug '16

Hi everyone, adding to the discussion about Koha::Objects I have a subject that needs broad (an urgent) discussion. The REST api patches are shaping up, and I'd like to focus on an important one: 14868 [1]. This bug introduces a way of specifying on the Swagger files, the required privileges to do stuff on objects. For example: + "x-koha-authorization": { + "allow-owner": true, + "allow-guarantor": true, + "permissions": { + "borrowers": "1" + } } specifies that to get a patron object you need to either have the 'borrowers' permission, be the object owner, or the guarantor of the object's owner. This is really nice, because permissions definition are now higher level entities (just a configuration thing), and they are part of the API documentation. There's even a bug with patches that introduce required permissions in the error messages. The current implementation introduces checks for each object class on the controller code. My feeling is that each business object should be responsible for such a check. The first step I made was to extend Koha::Object so it exposes an ->owner method that returns the Koha::Patron object that owns the object (because we can get the guarantees from there too). I did this to eliminate the need of class-specific checks on the controller. But at the end of the day, this still didn't feel it was good enough. I belive such a business matter should not be so tied to the controller/routing code and it is still there. Talking with Jonathan we thought we could make Koha::Objects->search accept more parameters (current userid, required permissions) and have the code checking authorization there, basically creating a filter on the search. The main problem is how to propagate the swagger-specified required permissions down to the Koha::Object in a clean way. I'd like to hear how people belive we should handle on this new+fresh code permissions check, so we have good foundations for the future of the project. Cleaning untested business logic from controller scripts is a good start! And this is the time to do it! Thanks in advance PS. I'm sure Jonathan will explain the discussion better once he comes back from the pub :-D [1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14868 -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

3 4