Bug 10060 - Allow adding a branch parameter to the web-based self check to indicate library its used at
Summary: Allow adding a branch parameter to the web-based self check to indicate libra...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Self checkout (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Nick Clemens
QA Contact: Martin Renvoize
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-15 22:47 UTC by Liz Rea
Modified: 2024-03-18 23:12 UTC (History)
8 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 10060: POC (1.97 KB, patch)
2024-03-18 11:38 UTC, Nick Clemens
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Liz Rea 2013-04-15 22:47:08 UTC
With Syspref settings of: 

CircControl - Use the checkout and fines rules of >> the library you are logged in at.
HomeOrHoldingBranch - Use the checkout and fines rules of >> the library the item was checked out from.

The web self check module isn't obeying these rules - it is using the library of the borrower doing the circulating, not the library assigned to the staff user required to log in to use the self check.

To replicate:

Ensure web self check is enabled 

Set CircControl to >> the library you are logged in at

Set HomeOrHoldingBranch to >> the library the item was checked out from

Create a staff user with "Circulate - remaining permissions," with homebranch as Library A (your choice which of your branches is library A)

Set that user as the auto login user for self check

Hit the self check interface at cgi-bin/koha/sco/sco-main.pl

log in or use the card number for a borrower from Library B, circulate an item.

View the item's circulation history, it will be from Library B instead of Library A
Comment 1 HB-NEKLS 2014-08-28 19:07:04 UTC
Is this still continuing to be an issue in master?
Comment 2 Oliver Behnke 2018-08-10 08:00:48 UTC
For us it's the other way round: we use a two-library-setup, both with auto-self-checkout enabled (based on cardnumber). 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 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):
- CircControl: the library the item is from
- HomeOrHoldingBranch: the library the item is from

Shall I open a dedicated bug report for that I do we (re)use this one...?

Thanks!
Comment 3 Oliver Behnke 2018-08-10 08:05:38 UTC
Ooops, forgot to mention we're using Koha 18.05.01-2
Comment 4 Liz Rea 2018-08-20 21:35:47 UTC
(In reply to Oliver Behnke from comment #2)
> For us it's the other way round: we use a two-library-setup, both with
> auto-self-checkout enabled (based on cardnumber). 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 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):
> - CircControl: the library the item is from
> - HomeOrHoldingBranch: the library the item is from
> 
> Shall I open a dedicated bug report for that I do we (re)use this one...?
> 
> Thanks!

Probably
Comment 5 Oliver Behnke 2018-08-21 11:54:42 UTC
Already done, see "See Also"...
Comment 6 Katrin Fischer 2018-09-20 18:49:04 UTC
Could using a separate self-check user for each branch solve the problem?
Comment 7 Liz Rea 2018-09-20 21:20:34 UTC
No, because the problem is that the user of the selfcheck isn't always owned by the branch that uses the selfcheck user, and the code is using the homebranch of the user. 

It's been a while since we've looked at this, maybe it's fixed now I don't know.
Comment 8 Oliver Behnke 2018-09-21 07:34:05 UTC
(In reply to Katrin Fischer from comment #6)
> Could using a separate self-check user for each branch solve the problem?

Katrin, is this already possible or are you suggesting a new feature? I'd love to try that if it's already supported but I don't see how.

Cheers
Comment 9 Katrin Fischer 2018-09-21 18:43:08 UTC
I haven't tested this. But you could have multiple patrons with the self-check permission and log in with them at different locations, I think.
Comment 10 Oliver Behnke 2018-09-24 08:31:17 UTC
Hi Katrin,

(In reply to Katrin Fischer from comment #9)
> I haven't tested this. But you could have multiple patrons with the
> self-check permission and log in with them at different locations, I think.

I don't see how that should be done. The self-service account is a system-wide setting (AutoSelfCheckID / AutoSelfCheckPass). Also, how should the self-service webpage even distinguish the branch from which a patron opened it? Those patrons are, by definition, not logged in with their own accounts.

Am I missing something?

Thanks
Comment 11 Katrin Fischer 2018-09-24 10:53:52 UTC
I might be missing something as we are only using the self check in one single branch library so far. 

But I might have some usefu info (hopefully):

- The prefs are not mandatory for use with the self check, you only need them for the automatic login to work. Before they were added, staff would log in the right user at the 'self check station'. 

- Prefs can be overwritten with Apache by branch for some use cases. I think the feature started out here: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10325 (we should document this better)


I think the use case the web based self check was developed for was a self check station at the library, that would only be used for self checkouts. Not sure if that fits your use case.
Comment 12 Oliver Behnke 2018-09-24 11:24:18 UTC
(In reply to Katrin Fischer from comment #11)
> - The prefs are not mandatory for use with the self check, you only need
> them for the automatic login to work. Before they were added, staff would
> log in the right user at the 'self check station'. 

Ok, good to know but kind of awkward since the whole point of those self-service terminals is to run unattended. Users would have to notify a librarian (in our case not even physically present) if that session expired for some reason.
 
> - Prefs can be overwritten with Apache by branch for some use cases. I think
> the feature started out here:
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10325 (we should
> document this better)

Hm, I don't see how that should help either since there is only one Koha instance (server and thus self-service web interface).

> I think the use case the web based self check was developed for was a self
> check station at the library, that would only be used for self checkouts.

That's exactly our use case but we have two branches (read: locations), served by the same central Koha instance. Both sites/branches use self-service terminals and thus need independent location handling for the items checked. I don't see why the current system was implemented in such a way that a checked item's location gets derived from the self-service auto-login account, not the patron who does the self-service action...
Comment 13 Katrin Fischer 2018-09-24 16:14:53 UTC
You can have a virtualhost config for each for your branches in Apache with different settings for the selfcheck user.
Comment 14 Katrin Fischer 2018-09-24 16:24:26 UTC
bug 16520 suggests it should work with Plack too (others might know more)
Comment 15 Katrin Fischer 2018-09-24 19:41:41 UTC
Magnus Enger has confirmed he uses this fix for some installations and has put up some notes on the wiki:
https://wiki.koha-community.org/wiki/Override_sysprefs_in_Apache_config
Comment 16 Christopher Brannon 2018-09-24 23:47:37 UTC
If I may, I was thinking of some things that you might consider in this bug.  If I am off target with the scope of this bug, just ignore.

If I wanted to streamline the self check, I would add a list in the self check preferences that would allow me to identify a computer by IP or name, and an account number to act as.  So for example:

192.555.555.10:123456
cplsc1:123456

The OPAC would check the list.  If the computer is showing a specific IP or name (192.555.555.10 or cplsc1 in the above example), it would login as the user with the barcode after the colon.

This is very simplistic as an idea.  I don't know if you would want to create something more robust in authentication, but this could work.  If the machine is not found in the list, it could revert back to current workflow, which is to prompt for login by the circing library before letting patrons login.  If the machine is in the list, it simply comes up ready for the patron to login.

I don't know if this helps, but I thought I would throw it out there.
Comment 17 Katrin Fischer 2018-09-25 05:29:39 UTC
I have talked with Liz about several approaches last night, one idea was to add a branch parameter to the URL to help pick the right branch/staff user. I think IP is a bit problematic for hosted installations as a lot of institutions only appear with a single IP to the outside world these days.
Comment 18 Oliver Behnke 2018-09-25 09:02:57 UTC
(In reply to Katrin Fischer from comment #17)
> one idea was to
> add a branch parameter to the URL to help pick the right branch/staff user.

Yes, that's sounds like a good idea! Meanwhile I'm going to have a closer look at the VirtualHost approach.

Thanks
Comment 19 Katrin Fischer 2023-01-25 22:16:48 UTC
(In reply to Katrin Fischer from comment #17)
> I have talked with Liz about several approaches last night, one idea was to
> add a branch parameter to the URL to help pick the right branch/staff user.
> I think IP is a bit problematic for hosted installations as a lot of
> institutions only appear with a single IP to the outside world these days.

Martin, can you maybe have a look here? I believe we maybe have that option now, but was not sure.
Comment 20 Martin Renvoize 2023-01-26 10:12:00 UTC
I'm not seeing a way to pass branch in the URL I'm afraid... looks like we use the issuer branch so it's currently tied to the self check users branch.
Comment 21 Katrin Fischer 2023-01-28 10:44:14 UTC
(In reply to Martin Renvoize from comment #20)
> I'm not seeing a way to pass branch in the URL I'm afraid... looks like we
> use the issuer branch so it's currently tied to the self check users branch.

Thx!
Comment 22 Christopher Brannon 2024-03-06 17:34:06 UTC
(In reply to Katrin Fischer from comment #17)
> I have talked with Liz about several approaches last night, one idea was to
> add a branch parameter to the URL to help pick the right branch/staff user.
> I think IP is a bit problematic for hosted installations as a lot of
> institutions only appear with a single IP to the outside world these days.

Isn't that a good thing?
Comment 23 Christopher Brannon 2024-03-06 18:57:58 UTC
It is CRITICAL that self check have the ability to auto-login based on url.  We need to be able to use accounts associated with the circulating library so that the library has proper stats and so the items are circulating under the correct circulating rules.

It seems that what we need is a setting under each library that defines which account to login as for self check.

Then we need to do something like allow the library to navigate their self check to /cgi-bin/koha/sco/sco-main.pl?branch=BRANCHCODE, which would tell the page to login to the self check with the credentials from their page.

AutoSelfCheckAllowed set to allow, but having nothing filled in for AutoSelfCheckID or AutoSelfCheckPass could be the queue for Koha to check for credentials under the branch, if specified in the URL.

Thoughts?
Comment 24 Christopher Brannon 2024-03-15 18:58:36 UTC
Another issue with forcing setups with multiple branches to login to their specific library for sco is that the typical self check kiosk does not have a standard keyboard.  This makes it more difficult to login, and adds unnecessary fussing with setup every single morning.
Comment 25 Nick Clemens 2024-03-18 11:38:00 UTC
Created attachment 163308 [details] [review]
Bug 10060: POC

This patch adds a stanza to the SetEnv middleware which checks for a branchcode in the SCO url and captures it.
We then use that branchcode in checkauth to set the userenv to the specified branch (if it is a real branch)

The regex could probably be improved, and the change needs test coverage, but this might be a valid approach to seeting the branch from the URL. Feedback appreciated
Comment 26 David Cook 2024-03-18 23:12:21 UTC
(In reply to Christopher Brannon from comment #23)
> Then we need to do something like allow the library to navigate their self
> check to /cgi-bin/koha/sco/sco-main.pl?branch=BRANCHCODE, which would tell
> the page to login to the self check with the credentials from their page.
> 
> AutoSelfCheckAllowed set to allow, but having nothing filled in for
> AutoSelfCheckID or AutoSelfCheckPass could be the queue for Koha to check
> for credentials under the branch, if specified in the URL.
> 
> Thoughts?

Locally we use /cgi-bin/koha/sco/sco-main.pl?branch=BRANCHCODE and then add a hidden input to each operation after that to include the branch.

We also have AutoSelfCheckID and AutoSelfCheckPass as well still, but we suffix it with a branchcode so that each branch can have its own particular user and password.

Nick's POC is interesting though.