February 2016 - Koha-bugs - lists.koha-community.org

[Bug 15280] Switch default CHECKOUT notice to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '16

09 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15280 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart(a)bugs.koha-c | |ommunity.org Status|Signed Off |BLOCKED --- Comment #6 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Blocked by bug 14757. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15374] Translatability: Fix issues on OPAC summary page
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '16

09 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15374 --- Comment #30 from Marc Véron <veron(a)veron.ch> --- (In reply to Aleisha Amohia from comment #28) > (In reply to Marc Véron from comment #27) > > Hi Aleisha, > > Thank you very much for continuous testing. > > > > I could not reproduce your issue from comment #24, see my tests in comment > > #25. If I missed something, please provide information on how you got your > > result. > > > Hi Marc, > > I mean that when a user has been blocked from checkouts because their fine > balance is over the limit, I feel like a message should show up saying this, > regardless of if OpacRenewalAllowed is set to Allow or not. Hi Aleisha, Is that something that changes with this path ( = a regression) or is the behaviour the same without patch? - If it is a regression, please fail the patch - If the behaviour is the same with and without patch, I propose to file a new Bug on top of this one. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15760] New: sql injection in poac-shelves.pl
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '16

09 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15760 Bug ID: 15760 Summary: sql injection in poac-shelves.pl Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Database Assignee: gmcharlt(a)gmail.com Reporter: hblancoca(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org In a security analisys with accunetix software can detect that opac-shelves.pl permit sql injection attack, an example can be the following: URL encoded GET input sortfield was set to if(now()=sysdate(),sleep(0),0)/*'XOR(if(now()=sysdate(),sleep(0),0))OR'"XOR(if(now()=sysdate(),sleep(0),0))OR"*/ URL encoded GET input sortfield was set to 1,(select case when (3*2*1=6 AND 000227=000227) then 1 else 1*(select table_name from information_schema.tables)end)=1 I believe that is needed to sanitize all variables in that script. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 15311] Let libraries set text to display when OpacMaintenance = on
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '16

09 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15311 Magnus Enger <magnus(a)libriotech.no> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #16 from Magnus Enger <magnus(a)libriotech.no> --- Looks like Mark forgot to change the status. :-) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15126] REST API: Use newer version of Swagger2
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '16

09 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15126 --- Comment #7 from Olli-Antti Kivilahti <olli-antti.kivilahti(a)jns.fi> --- Created attachment 47785 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=47785&action=ed… Swagger Minifier Swagger2 specification minifier. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 3144] anti-spam for opac-suggestions
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '16

09 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3144 --- Comment #40 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Mason James from comment #34) > hiya, are you running this follow-up patch? > > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15035 Not running the follow-up patch, but that doesn't appear to be an issue for 3.14 :/ -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 3144] anti-spam for opac-suggestions
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '16

09 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3144 --- Comment #39 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Christopher Vella from comment #38) > Normal users shouldn't be submitting any data to the negcap field (because > its not visible). Therefore only spammers should be submitting data too it. > If we introduced a banning system, their subsequent spamming attempts would > be stopped. Ah yes. I understand you now. Yeah, that would lower the amount of spam requests you're getting. It seems that we're getting POSTs without the negcap field filled in, which is how we're still getting spam suggestions, but with your idea they may have been banned before they figured that out... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15032] (Plack) Stage MARC records for import breaks in Plack
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '16

09 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15032 --- Comment #18 from Heather Braum <hbraum(a)nekls.org> --- I'm testing on 3.22 and the original bug I posted last fall when testing plack is more -- I'm no longer getting the reported error message. But, as Jonathan reported below, the staged import progress bar is non-existent [sits at 0% and then jumps to 100%] when clicking on the Stage Import button on stage-marc-import.pl. The same behavior happens on manage-marc-import.pl when clicking on the "Import this batch into the catalog" button [progress bar sits at 0% and then suddenly moves to 100%]. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15126] REST API: Use newer version of Swagger2
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '16

09 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15126 --- Comment #6 from Olli-Antti Kivilahti <olli-antti.kivilahti(a)jns.fi> --- Also one thing regarding the structure of the api/v1/-directory: Currently our api/v1/ looks like this: . ├── hypnotoad.conf ├── hypnotoad.pid ├── app.cgi ├── swagger.json ├── doc │ └── #Swagger-UI API discovery tool │ ├── auth_examples #REST API authentication code for different languages │ │ #Discoverable from the Swagger-UI │ └── ruby_example.rb.txt │ └── ajax_example.sj.txt # #└── swagger ##Could we add this?## # └── #swagger.json and subfolders and files If you start adding the Swagger-spec linked files and subfolders here. The directory structure will get very confusing. How about we add a directory where to put the "swagger"-specification files? I understand that the Swagger-UI might not be something which is aimed to be included in the official Koha, but somebody will certainly want to run some real API browsing/discovery service and this is a prefect place to do that. However Swagger-UI works really well and it is improving all the time with a lot of committers in already. We could name the directory "swagger", or even better "OpenAPI", which is the new name of the Swagger2-specification https://github.com/OAI/OpenAPI-Specification -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15126] REST API: Use newer version of Swagger2
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '16

09 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15126 Olli-Antti Kivilahti <olli-antti.kivilahti(a)jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |olli-antti.kivilahti(a)jns.fi --- Comment #5 from Olli-Antti Kivilahti <olli-antti.kivilahti(a)jns.fi> --- Hi! I think your solution looks robust and extendable. I would push the separation of definitions a bit further. This is a good article about how to split the Swagger2-spec: http://azimi.me/2015/07/16/split-swagger-into-smaller-files.html and it is pretty much the same as you did. How about we modified your suggestion so the structure looks like this: . ├── swagger.json ├── info │ └── index.json ├── definitions │ └── index.json │ └── error.json │ └── patron.json ├── parameters │ └── index.json │ └── patron.json └── paths ├── index.json └── patrons.json where definitions/patron.json looks like this: "borrower": { "type": "object", "properties": { "borrowernumber": { "$ref": "#/definitions/borrowernumber" }, "cardnumber": { "$ref": "#/definitions/cardnumber" }, "surname": { "$ref": "#/definitions/surname" }, "firstname": { "$ref": "#/definitions/firstname" }, ... } }, "cardnumber": { "description": "Library assigned ID number for Borrowers", "type": "string" }, "borrowernumber": { "type": "integer", "description": "Borrower internal identifier" }, "surname": { "description": "borrower's last name", "type": "string" }, "surname": { "description": "borrower's first name", "type": "string" } Now that there is a clear separation of logic (and release from insanely obscure git conflict resolutions with swagger.json), we should enforce that we define all parameters and definitions globally under #/parameters and #/definitions instead of defining them under object/path definitions. This way we maximize code reuse. In some cases it might not make much sense (if we only focus on today), like for "surname" and "firstname" in the above example, but some day in the near future somebody might want to reuse those components and then he would have to refactor those changes (or more likely just duplicate code because we are lazy). So as a future-proof solution I feel global definitions are the way to go. We could even push this a bit further, by instead of defining these REST API with the restrictions of the Koha DB, we could use commonly acknowledged linked data schemas, like schema.org to define our objects. https://schema.org/Person This would make it much easier to share the same records, for example between multiple Koha installations. Mainly because of the unique identifier in these objects, like {"url": "https://renki.vaarakirjastot.fi/api/v1/patrons/43441"} This is actually something which is easily enabled due to our awesome REST API and helps build more linked data systems between various API consumers. So if somebody would take our Patron-object, it would have a undeniably unique identifier and wouldn't conflict with Patron-objects originating from other systems. But for now we can focus on splitting our Swagger-spec. -- You are receiving this mail because: You are watching all bug changes.

1 0