Summary: | Allow adding a branch parameter to the web-based self check to indicate library its used at | ||
---|---|---|---|
Product: | Koha | Reporter: | Liz Rea <liz> |
Component: | Self checkout | Assignee: | Nick Clemens (kidclamp) <nick> |
Status: | NEW --- | QA Contact: | Martin Renvoize (ashimema) <martin.renvoize> |
Severity: | normal | ||
Priority: | P5 - low | CC: | cbrannon, chris.rowlands6, david, dcook, george, jdemuth, lisette, oliver.behnke, pierre.genty |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21250 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10257 |
||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Attachments: | Bug 10060: POC |
Description
Liz Rea
2013-04-15 22:47:08 UTC
Is this still continuing to be an issue in master? 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! Ooops, forgot to mention we're using Koha 18.05.01-2 (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 Already done, see "See Also"... Could using a separate self-check user for each branch solve the problem? 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. (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 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. 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 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. (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... You can have a virtualhost config for each for your branches in Apache with different settings for the selfcheck user. bug 16520 suggests it should work with Plack too (others might know more) 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 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. 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. (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 (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. 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. (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! (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? 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? 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. 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 (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. (In reply to Nick Clemens from comment #25) > Created attachment 163308 [details] [review] [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 I wish I could give feedback. Sounds promising. Is this a working patch that can be tested? Nick, can you tell me if this is a working patch to be tested, or just still discussion? It's a proof of concept - I don't remember now, but I know I thought of some issues that would need to be addressed - so I would not say it is ready for testing in any serious way - time allowing (or sponsorship) this could be looked into during the next cycle I would love to see this happen. We've moved over to Koha's self check out and we are losing stats because of it. Something like this should have happened years ago. We noted this problem in 2012 when we started with Koha. This is a annoying limitation for consortiums. When I have a moment, I'll take a look at my local code again. While we have a solution that works well for our multi-branch libraries, I doubt the Koha community will accept our code as is. But I can share what we've got, and collaborate with folk to make a community acceptable version. (In reply to Christopher Brannon from comment #30) > I would love to see this happen. We've moved over to Koha's self check out > and we are losing stats because of it. Something like this should have > happened years ago. We noted this problem in 2012 when we started with Koha. > > This is a annoying limitation for consortiums. Agreed (In reply to Christopher Brannon from comment #30) > I would love to see this happen. We've moved over to Koha's self check out > and we are losing stats because of it. Something like this should have > happened years ago. We noted this problem in 2012 when we started with Koha. > > This is a annoying limitation for consortiums. I totally understand the requirement for consortia, but wondering why you say this affects your stats. Can you explain how you solved it now or where this effect comes from? (In reply to David Cook from comment #31) > When I have a moment, I'll take a look at my local code again. While we have > a solution that works well for our multi-branch libraries, I doubt the Koha > community will accept our code as is. > > But I can share what we've got, and collaborate with folk to make a > community acceptable version. At this point I'd welcome a plugin. :) Thanks for anything you can do. (In reply to Katrin Fischer from comment #33) > (In reply to Christopher Brannon from comment #30) > > I would love to see this happen. We've moved over to Koha's self check out > > and we are losing stats because of it. Something like this should have > > happened years ago. We noted this problem in 2012 when we started with Koha. > > > > This is a annoying limitation for consortiums. > > I totally understand the requirement for consortia, but wondering why you > say this affects your stats. Can you explain how you solved it now or where > this effect comes from? On our 3rd party self check via sip, it was easy to configure instances we could isolate to specific branches, because the self check logged in to a specific sip account at each location, that didn't require a manual login. That software is no longer an option, so going to Koha's self check, we have to use the auto login since most library self checks don't have a keyboard connected. But we only have the option to use one account to login to with the auto login. So, we can capture stats per branch. (In reply to Christopher Brannon from comment #35) > (In reply to Katrin Fischer from comment #33) > > (In reply to Christopher Brannon from comment #30) > > I totally understand the requirement for consortia, but wondering why you > > say this affects your stats. Can you explain how you solved it now or where > > this effect comes from? > That software is no longer an option, so going to Koha's self check, we have > to use the auto login since most library self checks don't have a keyboard > connected. But we only have the option to use one account to login to with > the auto login. So, we can capture stats per branch. As Christopher mentions here, a lot of libraries use AutoSelfCheckID to log into the self-checkout. Since there can only be one AutoSelfCheckID, all checkouts at all the different branches will be checked out from that user. In the stats, this means the branch associated with checkout will always be the same. I've verified this in my own production installs. (Back in 2013, Liz mentioned even worse issues like the circ rules being applied based on the self-checkout user and not the patron. I haven't looked into that, but that's worth looking at too.) -- Locally, we create "Local" system preferences of "AutoSelfCheckID" suffixed with a branchcode, which allows different branches to have different "AutoSelfCheckID". This is a workaround which won't work so well in the Koha community I think. The best place to put it would probably be the "branches" table, but we'll have to consider the security/permissions ramifications of that, since the current permission required is "manage_sysprefs" and it would move to "manage_libraries". Arguably an understandable change but one worth documenting at the very least. Additionally, each branch must startup their self-checkout using a ?branch= parameter. After that initial visit, the branch parameter gets moved into hidden inputs, but a better place to put it would be in the login session of the self-checkout user. It could be nice to require an additional unguessable code as well so that patrons couldn't manipulate the URL to manipulate the branch used. I wonder if using separate "OPAC views" and the system preference overwrite would also be an approach as a possible workaround? (In reply to Katrin Fischer from comment #37) > I wonder if using separate "OPAC views" and the system preference overwrite > would also be an approach as a possible workaround? In theory, I think that could work. It would require a fair bit of sysadmin work, but that does sound like a feasible workaround in the meantime. (In reply to Katrin Fischer from comment #37) > I wonder if using separate "OPAC views" and the system preference overwrite > would also be an approach as a possible workaround? Could you elaborate? I'm not sure I understand. :) Thanks. (In reply to Christopher Brannon from comment #39) > (In reply to Katrin Fischer from comment #37) > > I wonder if using separate "OPAC views" and the system preference overwrite > > would also be an approach as a possible workaround? > > Could you elaborate? I'm not sure I understand. :) Thanks. She's referring to this: https://wiki.koha-community.org/wiki/Override_sysprefs_in_Apache_config It looks like the wiki actually already has a self checkout example even. Basically, you'd need a different subdomain for each self checkout, and then configure Apache to change sysprefs based on the different subdomains. (In reply to David Cook from comment #40) > (In reply to Christopher Brannon from comment #39) > > (In reply to Katrin Fischer from comment #37) > > > I wonder if using separate "OPAC views" and the system preference overwrite > > > would also be an approach as a possible workaround? > > > > Could you elaborate? I'm not sure I understand. :) Thanks. > > She's referring to this: > https://wiki.koha-community.org/wiki/Override_sysprefs_in_Apache_config > > It looks like the wiki actually already has a self checkout example even. > > Basically, you'd need a different subdomain for each self checkout, and then > configure Apache to change sysprefs based on the different subdomains. Oh yeah. I remember that. This sounds like a nightmare to implement. I think there are less complicated ways to build this into Koha itself and make it easier to implement. I think it's not really a nightmare and it would make what you want to do possible now. The trick is that every branch would have their own self check URL and self check user. (In reply to Christopher Brannon from comment #41) > Oh yeah. I remember that. This sounds like a nightmare to implement. I > think there are less complicated ways to build this into Koha itself and > make it easier to implement. It depends on how your Koha is managed. In theory, it shouldn't be a big drama. In some ways, it could actually offer a lot more control and security. But I agree about having a simpler/more maintainable way of doing it. Unfortunately, since this work is unsponsored, it falls lower than the sponsored priorities, but this is definitely on my radar. (In reply to David Cook from comment #43) > (In reply to Christopher Brannon from comment #41) > > Oh yeah. I remember that. This sounds like a nightmare to implement. I > > think there are less complicated ways to build this into Koha itself and > > make it easier to implement. > > It depends on how your Koha is managed. In theory, it shouldn't be a big > drama. In some ways, it could actually offer a lot more control and > security. > > But I agree about having a simpler/more maintainable way of doing it. > > Unfortunately, since this work is unsponsored, it falls lower than the > sponsored priorities, but this is definitely on my radar. Well, I have to go the more complicated route on this for the time being, but I do think this is basic setup for most self checks - being able to configure to a specific branch and automatically login. I'd be pressed to find a self check out there that requires these hoops. Anything that requires more than 1 person to configure and setup, especially something this basic, is inefficient in my book. At least it is here for someone to consider. Thanks for having it on your radar. (In reply to Christopher Brannon from comment #44) > Well, I have to go the more complicated route on this for the time being, > but I do think this is basic setup for most self checks - being able to > configure to a specific branch and automatically login. I'd be pressed to > find a self check out there that requires these hoops. I'd say that most self-checkouts are proper desktop apps, which would be much more to-purpose than Koha's self-checkout website. -- Funnily enough... I was actually just thinking it would be interesting to build an Electron-based Koha self-checkout app. It's not something that I'd personally do (for money/time reasons), but from a technical perspective it would be an interesting choice for Koha. If you're not already familiar, Electron provides a mechanism for creating cross-platform desktop applications using Javascript, HTML, and CSS (so technologies with which Koha devs are already familiar). I doubt that the Koha community would want to manage yet another thing, but it would be an interesting third-party/side project. We'd need to add some Koha API endpoints for it, but that's not a big drama. Anyway... just thought I'd write that idea down somewhere, and this seemed like a suitable place to do so. |