We use a two-branch library setup, both with auto-self-checkout enabled, so patrons log in with their cardnumber via the pre-defined staff user account (see below). The problem is that since the internal self-checkout user also has to be assigned to exactly one branch, that branch will be used as "current location" when a patron checks out a book. So, it's the self-service account's branch that's used instead of the patron's/borrower's branch. From looking at the code it seems that C4::Circulation->AddIssue() is using "C4::Context->userenv->{branch}" where "$borrower->{'branch'}" should probably be used instead, since the current user's branch isn't relevant (even wrong) in the auto-self-checkout context. FYI, we use the following config (if relevant at all): - Koha 18.05.01-2 - AutoSelfCheckAllowed: Allow (AutoSelfCheckID/AutoSelfCheckPass) - CircControl: the library the item is from - HomeOrHoldingBranch: the library the item is from Thank you.
It's probably a good idea to verify that all uses of "C4::Context->userenv" (anywhere) are compatible with the auto-self-checkout system as the underlying assumption that the current user is always a concrete patron or librarian isn't applicable in that scenario. Cheers
I think using the current user's branch would not be correct - it's possible that patrons from one home library visit other branches for lending books. For another solution see: https://wiki.koha-community.org/wiki/Override_sysprefs_in_Apache_config
(In reply to Katrin Fischer from comment #2) > I think using the current user's branch would not be correct - it's possible > that patrons from one home library visit other branches for lending books. I understand your point but what you describe is an edge case, compared to the current implementation which is always wrong for the patrons of all but one branch. > For another solution see: > https://wiki.koha-community.org/wiki/Override_sysprefs_in_Apache_config I fail to see how that can be solution. Our scenario comprises a single library with two branches, which seems to me as a standard well supported setup. Those branches share the same Koha instance and OPAC. There's therefore just a single web server. How am I supposed to modify the request headers for the branch-local self-service terminals when they simply display the same website? Thanks
(In reply to Oliver Behnke from comment #3) > (In reply to Katrin Fischer from comment #2) > > I think using the current user's branch would not be correct - it's possible > > that patrons from one home library visit other branches for lending books. > > I understand your point but what you describe is an edge case, compared to > the current implementation which is always wrong for the patrons of all but > one branch. Sorry, but I don't think it's an edge case. It's very usual for a lot of the libraries that patrons use more than one branch. > > > For another solution see: > > https://wiki.koha-community.org/wiki/Override_sysprefs_in_Apache_config > > I fail to see how that can be solution. Our scenario comprises a single > library with two branches, which seems to me as a standard well supported > setup. Those branches share the same Koha instance and OPAC. There's > therefore just a single web server. How am I supposed to modify the request > headers for the branch-local self-service terminals when they simply display > the same website? > > Thanks You'd change your Apache configuration to keep your normal URL as it is, but have 2 separate URLs for each branch of your library. Say: branch1.library.org and branch2.library.org - using those with the sys pref overwrite at the self check stations would then help select the right patron. But this discussion is getting out of scope here - Apache setup should be better discussed on the mailing list.
I didn't mean to ignore your case, I just wanted to point out that the current situation is even worse :-) Thanks again Katrin. As I said in #10060, I'm going to have a closer look at VirtualHost workaround. I don't think this discussion is getting of course since you're providing a workaround for the issue we discuss here. I think that eventually your idea in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10060#c17 should be implemented as a solution to this issue, though. Cheers
Yes, the Apache solution is more of a workaround than a nice solution. I like the idea of the parameter, but it probably won't be implemented without someone funding it.
Could anyone provide further funding details? Monetary or developer time? Any required effort estimates? IOW, how would "funding" work? I had a brief look at the code some time ago and this particular part seemed rather strewn across various places. I'd give it a shot myself if only I could be sure where to look first of all :-) Cheers
(In reply to Oliver Behnke from comment #7) > Could anyone provide further funding details? Monetary or developer time? > Any required effort estimates? IOW, how would "funding" work? As Koha is open source, you have a lot of different options. You could switch the 'Change sponsored' field here to 'Seeking developer' or 'Seeking cosponsors', but I am not sure how many check that. You could ask for quotes on the mailing list or contact developers directly for quotes. If you want to have a go yourself, you could join us on IRC for help or ask questions on the mailing list.
FYI, I successfully deployed the Apache-based syspref override workaround. The nice thing about it is that (with Apache 2.4) you don't even need a separate VirtualHost. Just use conditionals in the existing OPAC VirtualHost: <If "-R 'CLIENT_OR_NET_IP_HERE'"> SetEnv OVERRIDE_SYSPREF_AutoSelfCheckID "abc" SetEnv OVERRIDE_SYSPREF_AutoSelfCheckPass "123" RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_AutoSelfCheckID abc" RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_AutoSelfCheckPass 123" </If> Cheers
I should have added that the two bottom statement are for Plack users, so you only need one of the pairs.
Hi Oliver, thx for sharing your solution, I've added it to the wiki: https://wiki.koha-community.org/wiki/Override_sysprefs_in_Apache_config#Examples Can you check?
You could add "See also" refs to the Apache docs covering the expression I used: https://httpd.apache.org/docs/2.4/mod/core.html#if https://httpd.apache.org/docs/2.4/expr.html Also, could you please add the following in-line comments about Plack integration, which is, AFAIK, optional. I also changed the user/pw placeholders to match the existing wiki examples. <If "-R 'CLIENT_OR_NET_IP_HERE'"> # Koha without Plack SetEnv OVERRIDE_SYSPREF_AutoSelfCheckID "xyz" SetEnv OVERRIDE_SYSPREF_AutoSelfCheckPass "abc" # Koha with Plack # (commas must be escaped with '\') RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_AutoSelfCheckID xyz" RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_AutoSelfCheckPass abc" </If> HTH
(In reply to Oliver Behnke from comment #12) > You could add "See also" refs to the Apache docs covering the expression I > used: > > https://httpd.apache.org/docs/2.4/mod/core.html#if > https://httpd.apache.org/docs/2.4/expr.html > > Also, could you please add the following in-line comments about Plack > integration, which is, AFAIK, optional. I also changed the user/pw > placeholders to match the existing wiki examples. > > <If "-R 'CLIENT_OR_NET_IP_HERE'"> > # Koha without Plack > SetEnv OVERRIDE_SYSPREF_AutoSelfCheckID "xyz" > SetEnv OVERRIDE_SYSPREF_AutoSelfCheckPass "abc" > > # Koha with Plack > # (commas must be escaped with '\') > RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_AutoSelfCheckID xyz" > RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_AutoSelfCheckPass abc" > </If> > > HTH Hi Oliver, I didn't get to it yet. If you want, please feel free to edit the wikipage yourself! Account creation is moderated, so it might take a little bit to go through, but it's only an anti-spam measure and everyone is invited to contribute.
Done.
Awesome, thx!
As we found a workaround, I am lowering severity to 'normal' - might be bordering on enh at this point.
*** Bug 24332 has been marked as a duplicate of this bug. ***
Would like to see a more straight forward solution to this.
(In reply to Christopher Brannon from comment #18) > Would like to see a more straight forward solution to this. Agreed - was just linking both as I think it's the same problem and maybe this is still helpful as a workaround.
At the moment, we use a local customization where you use a URL with a branch parameter, and then some local system preferences to use branch-specific users.