A new request with request id 10824 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is :
Title : Koha-devel Digest, Vol 197, Issue 9
Category :
Description : Send Koha-devel mailing list submissions to
koha-devel@lists.koha-community.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
or, via email, send a message with subject or body 'help' to
koha-devel-request@lists.koha-community.org
You can reach the person managing the list at
koha-devel-owner@lists.koha-community.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Koha-devel digest..."
Today's Topics:
1. Plack Middleware to isolate library branches via path
(Thomas Klausner)
2. Re: Plack Middleware to isolate library branches via path
(dcook@prosentient.com.au)
3. How to apply Lending Restrictions (Ms. Naveen Ali)
4. Re: Plack Middleware to isolate library branches via path
(Thomas Klausner)
----------------------------------------------------------------------
Message: 1
Date: Tue, 19 Apr 2022 14:12:45 +0200
From: Thomas Klausner <domm@plix.at>
To: koha-devel@lists.koha-community.org
Subject: [Koha-devel] Plack Middleware to isolate library branches via
path
Message-ID: <20220419121245.GK3952@plix.at>
Content-Type: text/plain; charset="utf-8"
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$_.$/}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IsolateBranch.pm
Type: text/x-perl
Size: 2447 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220419/6cc9a231/attachment-0001.pm>
------------------------------
Message: 2
Date: Wed, 20 Apr 2022 10:56:36 +1000
From: <dcook@prosentient.com.au>
To: "'Thomas Klausner'" <domm@plix.at>,
<koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] Plack Middleware to isolate library branches
via path
Message-ID: <016501d85451$81be5bd0$853b1370$@prosentient.com.au>
Content-Type: text/plain; charset="us-ascii"
Hi Thomas,
The timing of your email is interesting! I was just reflecting the other day
about how Koha can't work off anything but the root path.
However, it's not something that I'm likely to ever work on, as the
subdomains work fine for us. (Although self-checkout URLs using branch-based
paths could be very useful for us.)
I have a Catalyst app where I use the out of the box method $c->uri_for
which constructs an absolute URI using the application root (e.g. /aaa/),
but that would require rewriting Koha's templates. I use that same strategy
for some of my other web apps, which lets the deployment be quite flexible.
(In the case of Catalyst, it auto-detects the path based on the location of
the controller. With CGI apps I have, I rely on a configuration variable.)
With your solution, how do you handle Javascript navigation that doesn't
necessarily rely on HTML? (I can't think of any examples off the top of my
head but I'm sure they must exist, although perhaps only on the Staff
Interface...)
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
-----Original Message-----
From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of
Thomas Klausner
Sent: Tuesday, 19 April 2022 10:13 PM
To: koha-devel@lists.koha-community.org
Subject: [Koha-devel] Plack Middleware to isolate library branches via path
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$_.$/}
------------------------------
Message: 3
Date: Wed, 20 Apr 2022 10:10:49 +0500 (PKT)
From: "Ms. Naveen Ali" <naveen@neduet.edu.pk>
To: koha-devel@lists.koha-community.org, koha@lists.katipo.co.nz
Subject: [Koha-devel] How to apply Lending Restrictions
Message-ID:
<1673116620.1147324.1650431449576.JavaMail.zimbra@neduet.edu.pk>
Content-Type: text/plain; charset="utf-8"
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220420/33a00775/attachment-0001.htm>
------------------------------
Message: 4
Date: Wed, 20 Apr 2022 10:00:31 +0200
From: Thomas Klausner <domm@plix.at>
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Plack Middleware to isolate library branches
via path
Message-ID: <20220420080031.GO3952@plix.at>
Content-Type: text/plain; charset=us-ascii
Hi!
On Wed, Apr 20, 2022 at 10:56:36AM +1000, dcook@prosentient.com.au wrote:
> The timing of your email is interesting! I was just reflecting the other day
> about how Koha can't work off anything but the root path.
:-)
> I have a Catalyst app where I use the out of the box method $c->uri_for
> which constructs an absolute URI using the application root (e.g. /aaa/),
> but that would require rewriting Koha's templates. I use that same strategy
Most web frameworks and/or router implementations provide methods to
generate links, and those methods should honor HTTP headers like
X-Forwarded-For etc. I usually use Plack::Middleware::ReverseProxyPath
https://metacpan.org/pod/Plack::Middleware::ReverseProxyPath
which uses X-Forwarded-Script-Name and X-Traversal-Path to allow for a
very flexible setup, if the apps/routers used support those headers to
generate links (Catalyst does, AFAIK)
But I guess the reason that Koha cannot use somethink like this is that
it generates a lot of links via literal strings in the templates. And
changing this to use a method/function would be a lot of work!
Which is why I choose the rather ugly and probably not very stable
approach to fix (hopefully..) the generated URLs after rendering using a
regex...
> With your solution, how do you handle Javascript navigation that doesn't
> necessarily rely on HTML? (I can't think of any examples off the top of my
> head but I'm sure they must exist, although perhaps only on the Staff
> Interface...)
Currently we don't, but the users are as of now only starting to test
the path-based branches. We'll see what problems they'll encounter. And
we're only using this branch separation on the OPAC.
Greetings,
domm
--
#!/usr/bin/perl https://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
------------------------------
Subject: Digest Footer
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/
------------------------------
End of Koha-devel Digest, Vol 197, Issue 9
******************************************
NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.