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

shelf-browser replacement for koha
by Paul Derscheid 21 Apr '22

21 Apr '22

Hi everyone, I developed a replacement for the koha shelf-browser realised as a JavaScript library which is already in production with one of our clients. tcohen asked me to provide necessary infos and resources so others can take a look. The most important part is LMSCoverFlow.js <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/koha-tmpl/opac-tmpl/b…> which is the library itself. For the actual function calls take a look at opac-detail.tt <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/koha-tmpl/opac-tmpl/b…> starting at line 1710. The shelf-browser functionality depends on some scripts, namely coverflowbyshelfitem <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/opac/svc/coverflowbys…> and covergen <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/opac/svc/covergen> The corresponding modules are CoverFlowData.pm <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/C4/CoverFlowData.pm> and CoverGen.pm <https://github.com/LMSCloud/Koha-LMSCloud/blob/master/C4/CoverGen.pm>. I already got lectured on not putting stuff in C4. Next goal is to move everything data related to an API endpoint. The js is actually written in TypeScript using ES6 modules and I will change the visibility of the corresponding repo soon and notify you accordingly. Since the shelf browser is based on itemcallnumbers, it is necessary to assign such to a sufficient amount of titles (9 when I tested on koha-testing-docker). To see how it looks in prod take a look at this OPAC <https://sb-heilbronn.lmscloud.net/>. If my explanation is not sufficient or I should have forgotten something, you can send me a mail or write to me on IRC. My nick is paulderscheid. I’d love to get feedback and I’m open to criticism. Kind Regards. Paul -- LMSCloud GmbH Paul Derscheid - Software Engineer Konrad-Zuse-Platz 8 - D-81829 München e paul.derscheid(a)lmscloud.de w www.lmscloud.de

2 2

How to apply Lending Restrictions
by Ms. Naveen Ali 20 Apr '22

20 Apr '22

Dear members, I would like to put forward the following scenario. Our library has three sections where books are loaned and they each have different policies. All library members have access to all sections. I would like to implement the library policy where 1. staff of one section can issue books of that section only 2. books should also be returned to the same section. There is no general rule; just specific rules for each section. This is what I am doing. I have provided Permanent Library of all book items as the main library name and the Current Library as the section library. I am trying to use the following global parameters to implement our library policies, but am not successful. * AllowReturnToBranch Allow items to be checked in "Only at the item the library is from" (I understand this to be the current library) * AutomaticItemReturn Don't automatically transfer items to their home library when they are checked in. (I understand the home library to be the permanent library) * CircControl Use the calendar and circulation rules of "the library the item is from" (I understand this to be the current library) * HomeOrHoldingBranch Use the checkout and fines rules of " the items holding library" (I understand holding library = current library and home library = permanent library) *It seems that CircControl and HomeOrHoldingBranch paramter are same. I also can't find how to restrict a library staff member from Setting his library to any that he wants by using the "Set Library" Option available. Also how to prevent staff from issuing books belonging to other libraries. With best regards, Naveen Ali ITM-JE (EAKL) Inst Representative for HEC Digital Library Resources. NEDUET, Karachi.

2 1

Vote: Use Vue3 for the new ERM (Electronic Resource Management) module
by Victor Grousset/tuxayo 20 Apr '22

20 Apr '22

Hi :) At last meeting, today, it has been voted to give a go to have Vue3 JS framework be used for the new ERM module. Here is the same question to have a wider reach than only the people that were able to attend. So, agreed with that? Or any objections? Let's wait a few days and if no major objection, Jonathan will be able to continue the ERM module knowing Vue won't be a problem for the patch acceptance in Koha. meeting logs: http://irc.koha-community.org/koha/2022-04-20#i_2416969 Email asking for the vote and listing all the resources about the ERM project https://lists.koha-community.org/pipermail/koha-devel/2022-April/046998.html Cheers, -- Victor Grousset/tuxayo

1 0

Terminology: addition of "use restriction, not debarment"
by Victor Grousset/tuxayo 20 Apr '22

20 Apr '22

Hi :) After last dev meeting of the 6th, the following addition has been done: https://wiki.koha-community.org/w/index.php?title=Terminology&action=histor… Whole page: https://wiki.koha-community.org/wiki/Terminology Cheers, -- Victor Grousset/tuxayo

1 0

Plack Middleware to isolate library branches via path
by Thomas Klausner 20 Apr '22

20 Apr '22

Hi! A customer wants to access branches/branchgroups via a subpath, instead of the more common / documented way of setting up a subdomain per branch: https://wiki.koha-community.org/wiki/Override_sysprefs_in_Apache_config So instead of https://aaa.library.example.com/ they want https://library.example.com/aaa/ (for ~10 branches) This boils down to: - matching the path and munging the URL - setting some ENV vars (OPAC_SEARCH_LIMIT, OPAC_CSS_OVERRIDE, etc) - munging the HTML generated by Koha to fix the links While this could be implemented via carefull application of various Apache modules (mod_proxy, mod_rewrite, mod_proxy_html) I feel more comfortable implementing this in Perl in a Plack Middleware. The result is not very pretty, but seems to work (see attached code...) But to load the middleware, I have to enable it in /etc/koha/plack.psgi and thus change a core file (or copy upstream plack.psgi and edit the copy, which still means that we'll have to apply our changes after each update) In theory we could add some config to load custom Middlewares, but as the load order of Middlewares is very relevant, this seems hardly doable - unless we start with one middleware config slot at the location I need :-) Anyway, I think we'll just go with maintaining a custom plack.psgi, unless anybody here has any other ideas / best practices / solutions on how to mount library branches at location/sub-dirs... I'm also not sure if this feature is on any roadmap etc. Greetings, domm -- #!/usr/bin/perl https://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

2 2

Collecting ideas to have an easier time with large patch submissions. And inventory of large submissions that are stuck.
by Victor Grousset/tuxayo 19 Apr '22

19 Apr '22

Hi :) At the development IRC meeting of 6 April 2022 it was discussed what could be done to help large developments better move forward using the recent experience with recalls patches (bug 19532). Here is what came out of it: - resist scope creep and ask only for necessary changes for inclusion (Minimun Viable Product) - ask to focus discussions on concrete actions for the dev to reach an acceptable MVP - note somewhere all the potential follow ups ideas so that they don't get lost and it easier to move on knowing they are somewhere not lost - bring the development as a topic in meetings and QA team discussions to get focus on it What do you think of these? Any other ideas/guidelines to complete this? What are the large patch submissions that are stuck that you know about? If you could send messages in the past in the ticket, what would you sent that would have hopefully helped it move forward? Here are some other ideas: - When submitting large changes, submit a minimal version first if possible and if a more complete version might be too much. Even if it will be hard to maintain a separate more complete version for your customers. If it gets stuck, it will be worse than doing it in chunks. - Maybe reboot a submission on a new ticket with a chopped down version if noticing you should have went for the previous guideline. - Maybe propose taking on testing complicated stuff of someone else if they do the same for your submission. It will be worth your time if it avoids being stuck for months/years with dozens of rebases on the ticket plus on your customer's Kohas due to it being a effectively a fork. Cheers, -- Victor Grousset/tuxayo

1 0

Google showing "Borrow" option for nearby public libraries
by dcook＠prosentient.com.au 19 Apr '22

19 Apr '22

Hi all, I was looking up a book the other day on Google when I noticed a section called "Borrow" and it showed two local library services where I could borrow the book. I did a bit more Googling today and noticed this: https://developers.google.com/search/docs/advanced/structured-data/book It looks like individual libraries would need to register their interest first, but after that the system would need to serve a feed file that Google would regularly harvest. Does anyone have a Koha library where they're currently doing this? It could make for an interesting Koha plugin. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 2

Release maintenance: Monthly string freeze: shall it be announced also on koha-devel and the general list?
by Victor Grousset/tuxayo 18 Apr '22

18 Apr '22

Hi :) The idea is to push the librarians, admins, and devs to check the translations out if they remember something off. To try to reach out instead of relying on those already interested in translation and subscribed to koha-translate. Currently not all release maintainers announce the string freeze in the same place resulting in confusion. Cheers, -- Victor Grousset/tuxayo

2 2

Call for news - Newsletter April 2022
by Koha Newsletter 13 Apr '22

13 Apr '22

Hi I'm collecting news for the April 2022 Koha Community Newsletter. Please send anything noteworthy to: kohanews (at) gmail (dot) com News criteria: * News items can be of any length. * Images are fine. * Anything and everything Koha. * Submit by the 26th of the month. Text format criteria: * Just structured plain text, or * HTML text to include tables or similar For events: * Consider adding your event to the Koha Community calendar at https://koha-community.org/calendar/ Thank you! Michael Kuhn Editor, Koha Community Newsletter

1 0

Vote on Vue3 (for ERM) at the next dev meeting
by Jonathan Druart 11 Apr '22

11 Apr '22

Hi devs, Could we vote at the next dev meeting that the ERM module will be written in Vue3 and that it will not be a problem for its integration into Koha? This module will contain a lot of CRUD operations and simple forms. And so all the necessary REST API routes will be provided from the beginning. I thought it would be a good candidate to introduce a new and modern solution to Koha. Using it in an isolated module will allow us to try it, find the different problems we can face, fix them, and not force other developers to be onboard if they don't want to. There is already a POC of this module using Vue3, with the different REST API routes, and UI testing using Cypress (see link below). Other solutions are: * Use another JS framework (but in that case you will show us on the "cities" view a simple implementation case) * Use the old/traditional way Links related to ERM and Vue3: * Electronic Resource Management for Koha https://lists.katipo.co.nz/pipermail/koha/2022-February/057447.html * Sandbox - https://staff-erm.sandboxes.biblibre.eu/cgi-bin/koha/erm/agreements.pl * Git remote branch - https://gitlab.com/joubu/Koha/-/commits/erm * Cities rewrites ** Bug 30160 - Rewrite cities admin view in React ** Bug 30225 - Rewrite cities admin view in Vue ** "I played with React" https://lists.koha-community.org/pipermail/koha-devel/2022-February/046926.… * "I played with Cypress (and ERM and Vue)" https://lists.koha-community.org/pipermail/koha-devel/2022-March/046956.html Cheers, Jonathan

2 1