We have volunteers on the circulation desk. They are individual/family members of type 'Adult' not 'Staff'. We are currently running 3.18.11 built from the tar ball on openSUSE 13.2. Their permissions are set to: circulate (all) catalogue reserveforothers (all) borrow updatecharges(all) When they go to check out items, they get logged out with a "timeout" error. But the item is checked out! staffaccess permission doesn't make any difference on or off. It work as it should when the borrowers permission is set, but we don't want volunteers to be able to modify patrons. It was working in 3.18.05. -- Bob Ewart
Hi Bob, I just tried testing this on master - but couldn't reproduce. Maybe it's something specific to 3.18 (or I missed something) - could you file a bug report please? Katrin Am 02.10.2015 um 14:39 schrieb Bob Ewart:
We have volunteers on the circulation desk. They are individual/family members of type 'Adult' not 'Staff'. We are currently running 3.18.11 built from the tar ball on openSUSE 13.2.
Their permissions are set to: circulate (all) catalogue reserveforothers (all) borrow updatecharges(all)
When they go to check out items, they get logged out with a "timeout" error. But the item is checked out!
staffaccess permission doesn't make any difference on or off.
It work as it should when the borrowers permission is set, but we don't want volunteers to be able to modify patrons.
It was working in 3.18.05.
Hi Bob, I was unable to replicate this on 3.18.11. We would need to know more about your setup to help with this, I think. One possible thing, would be that perhaps you need to clear your cache and/or cookies. Cheers, Liz On 05/10/15 02:31, Katrin Fischer wrote:
Hi Bob,
I just tried testing this on master - but couldn't reproduce. Maybe it's something specific to 3.18 (or I missed something) - could you file a bug report please?
Katrin
Am 02.10.2015 um 14:39 schrieb Bob Ewart:
We have volunteers on the circulation desk. They are individual/family members of type 'Adult' not 'Staff'. We are currently running 3.18.11 built from the tar ball on openSUSE 13.2.
Their permissions are set to: circulate (all) catalogue reserveforothers (all) borrow updatecharges(all)
When they go to check out items, they get logged out with a "timeout" error. But the item is checked out!
staffaccess permission doesn't make any difference on or off.
It work as it should when the borrowers permission is set, but we don't want volunteers to be able to modify patrons.
It was working in 3.18.05.
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- -- Liz Rea Catalyst.Net Limited Level 6, Catalyst House, 150 Willis Street, Wellington. P.O Box 11053, Manners Street, Wellington 6142 GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7
Thanks Liz and Katrin I'm beginning to think that it may be a problem with mariadb or something else that was updated recently. I'm currently running openSUSE 13.2 with mariadb 10.0.21 with Koha 3.18.10 built from a tar ball. I tried to setup 3.18.11 and selected "install all optional data" in the web installer for a test case. This generated two errors (see bug 14952 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14952> ) This was working when I created a test database on 3.18.09 last month for my Donor Tracking plugin. It's now failing even on 3.18.08. I know there was a problem with changes made to mysql's STRICT_TRANS_TABLES variable reported in bug 13523 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13523> in January and am wondering if there are any other recent changes. I'm setting up a couple of fresh installs of openSUSE 13.2 and will try to reproduce the problem. I am also going to check my current database structure with the fresh installs. Our database was created somewhere around Koha 3.0 and has been upgraded skipping a few releases. It may be that some changes to the structure or system variables have not be made. -- Bob On 10/05/2015 04:30 PM, Liz Rea wrote:
Hi Bob,
I was unable to replicate this on 3.18.11. We would need to know more about your setup to help with this, I think.
One possible thing, would be that perhaps you need to clear your cache and/or cookies.
Cheers, Liz
On 05/10/15 02:31, Katrin Fischer wrote:
Hi Bob,
I just tried testing this on master - but couldn't reproduce. Maybe it's something specific to 3.18 (or I missed something) - could you file a bug report please?
Katrin
Am 02.10.2015 um 14:39 schrieb Bob Ewart:
We have volunteers on the circulation desk. They are individual/family members of type 'Adult' not 'Staff'. We are currently running 3.18.11 built from the tar ball on openSUSE 13.2.
Their permissions are set to: circulate (all) catalogue reserveforothers (all) borrow updatecharges(all)
When they go to check out items, they get logged out with a "timeout" error. But the item is checked out!
staffaccess permission doesn't make any difference on or off.
It work as it should when the borrowers permission is set, but we don't want volunteers to be able to modify patrons.
It was working in 3.18.05.
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Hi Bob, It's totally that "STRICT_TRANS_TABLES" that's doing this. I just tested on my MariaDB (same v. as yours) with that and I get the errors too now. Cheers, Liz On 07/10/15 02:06, Bob Ewart wrote:
Thanks Liz and Katrin
I'm beginning to think that it may be a problem with mariadb or something else that was updated recently.
I'm currently running openSUSE 13.2 with mariadb 10.0.21 with Koha 3.18.10 built from a tar ball.
I tried to setup 3.18.11 and selected "install all optional data" in the web installer for a test case. This generated two errors (see bug 14952 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14952> ) This was working when I created a test database on 3.18.09 last month for my Donor Tracking plugin. It's now failing even on 3.18.08.
I know there was a problem with changes made to mysql's STRICT_TRANS_TABLES variable reported in bug 13523 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13523> in January and am wondering if there are any other recent changes.
I'm setting up a couple of fresh installs of openSUSE 13.2 and will try to reproduce the problem.
I am also going to check my current database structure with the fresh installs. Our database was created somewhere around Koha 3.0 and has been upgraded skipping a few releases. It may be that some changes to the structure or system variables have not be made.
-- -- Liz Rea Catalyst.Net Limited Level 6, Catalyst House, 150 Willis Street, Wellington. P.O Box 11053, Manners Street, Wellington 6142 GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7
Hi Liz That fixed bug 14952 and it works on a small test case I built using the default data. There were a number of differences in my database structure from the fresh created one, so I wrote a little perl program to fix them. My 'permissions' and 'userflags' tables had some differences in content which I changed. However, I'm still having the original problem of the people on the circulation desk being logged out when trying to check an item out. The item is checked out! Also if they look at the current books checked out, it comes up with a message saying "Loading. You may continue scanning" and never finds the items checked out. Any suggestions? On 10/06/2015 04:44 PM, Liz Rea wrote:
Hi Bob,
It's totally that "STRICT_TRANS_TABLES" that's doing this. I just tested on my MariaDB (same v. as yours) with that and I get the errors too now.
Cheers, Liz
On 07/10/15 02:06, Bob Ewart wrote:
Thanks Liz and Katrin
I'm beginning to think that it may be a problem with mariadb or something else that was updated recently.
I'm currently running openSUSE 13.2 with mariadb 10.0.21 with Koha 3.18.10 built from a tar ball.
I tried to setup 3.18.11 and selected "install all optional data" in the web installer for a test case. This generated two errors (see bug 14952 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14952> ) This was working when I created a test database on 3.18.09 last month for my Donor Tracking plugin. It's now failing even on 3.18.08.
I know there was a problem with changes made to mysql's STRICT_TRANS_TABLES variable reported in bug 13523 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13523> in January and am wondering if there are any other recent changes.
I'm setting up a couple of fresh installs of openSUSE 13.2 and will try to reproduce the problem.
I am also going to check my current database structure with the fresh installs. Our database was created somewhere around Koha 3.0 and has been upgraded skipping a few releases. It may be that some changes to the structure or system variables have not be made.
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Bob Ewart schreef op do 08-10-2015 om 15:59 [-0400]:
However, I'm still having the original problem of the people on the circulation desk being logged out when trying to check an item out. The item is checked out!
How do they connect to the Koha server? Is there a proxy in the middle that could be causing issues, or some reason for them to be changing IP address? Can you watch the session cookies in the browser, is something deleting them? What (if anything) do the Koha error logs say? I wonder if turning on debug would help, too. It might, though it'll cause your error logs to have a lot of noise. What browser are you using, and does a different browser help? (You can turn on debug by adding SetEnv DEBUG "1" to the appropriate virtualhost section in your apache config.) -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
On 10/08/2015 06:51 PM, Robin Sheat wrote:
However, I'm still having the original problem of the people on the circulation desk being logged out when trying to check an item out. The item is checked out! How do they connect to the Koha server? Is there a proxy in the middle
Bob Ewart schreef op do 08-10-2015 om 15:59 [-0400]: that could be causing issues, or some reason for them to be changing IP address? Can you watch the session cookies in the browser, is something deleting them? What (if anything) do the Koha error logs say? I wonder if turning on debug would help, too. It might, though it'll cause your error logs to have a lot of noise.
What browser are you using, and does a different browser help?
(You can turn on debug by adding SetEnv DEBUG "1" to the appropriate virtualhost section in your apache config.)
The Windows 7 workstation at the library is connected to the server on a local area network. My test system is running directly on the server. No proxies are involved. We've tried both Firefox and Chromium with no difference. I wrote a little program to add comments to the koha-error_log file to show what was going on. Then wrote another little program to neaten up the logs. Most of the leading information which takes up most of a line is pretty much duplicated in each entry. I eliminated that and just put the minutes:seconds from the start of the test before the rest of the line. (If I never see another CGI::param called in list context... error, I'll be real happy.) I'm running with Koha 3.18.10 software. The two runs are: 1. New database -- drop database koha, create database koha, run the web installer with all optional data added, added Joe Volunteer 7472 with checkout permissions and myself as 2002 super Librarian and finally imported 3 books to work with 2. My database -- drop database koha, create database koha, source koha.sql (a mysqldump from the library); I put 5 files on my webserver: 1. Test with new database <http://bobsown.net/images/koha-log-std> 2. Test with my database <http://bobsown.net/images/koha-log-error> 3. Unedited log of new database <http://bobsown.net/images/koha-log-std-full> 4. Unedited log of my database <http://bobsown.net/images/koha-log-error-full> 5. Permissions shown in both <http://bobsown.net/images/permissions.txt> As you can see from the logs, there are a couple of xsub entries in the new database run that are not in my run before the volunteer sees the main page. Then I go to patron 2002 for checkout and that looks the same Then I give it a barcode to check out. This is where things go really wrong. With my database it does a Checking Auth in circulation.pl and eventually logs the volunteer out. When I immediately log him back in it never goes to the main page. It goes to the checkout page and appears to go through the same steps as the checkout with the new database. The book is checked out. When I try to show the checkouts, it says "Loading -- you may continue scanning" and does nothing after that. The permissions are different in the two cases. I'm not sure why, but my database was originally created way back around 3.00 and errors may have crept in in the updates. On 10/12/2015 03:01 PM, Katrin Fischer wrote:
Hi Marc,
we could check for the existence of the mandatory data maybe, but some of it might be unselected on purpose by some. For the permission definitions, maybe we could move them out of the database altogether? You won't ever want to change them and they are not translatable currently, although there is a patch waiting to change that:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13632
Katrin That patch may solve my problem
-- Bob Ewart
Bob Ewart schreef op ma 12-10-2015 om 16:05 [-0400]:
The Windows 7 workstation at the library is connected to the server on a local area network. My test system is running directly on the server. No proxies are involved. We've tried both Firefox and Chromium with no difference.
OK, so it's probably not something being dumb about cookies then :) This said, it might pay to trace the network requests in the browse to ensure that there isn't a request that is zapping the cookie.
As you can see from the logs, there are a couple of xsub entries in the new database run that are not in my run before the volunteer sees the main page.
xsub comes from some date conversion code. The sooner we move to better logging and get file prefixes on things, the better :) The "01:26 AUTH_SESSION: ()\t - " bit looks particularly suspicious, especially as there are some "Use of uninitialised value" warns right before it that aren't in your other log. I'd probably start looking around there.
The permissions are different in the two cases. I'm not sure why, but my database was originally created way back around 3.00 and errors may have crept in in the updates.
What happens if you make the permissions match? Probably making the one that doesn't work match the one that does... -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
I need to get to updating the wiki... we experienced a similar timeout issue, with the checkout and check-in commands performing with success, because of the expiration date ("enrollment period") of our patrons. We set some patrons such as staff to expire in 9999 -- it took Koha up to 1 minute to calculate the due date when checking out a book, which led to the time out. The problem was solved when we set the expiration date to 2032 in the Patron Category Administration (in the Koha admin. interface). Sebastian -- Sebastian Hierl, Ph.D. Drue Heinz Librarian, Arthur & Janet C. Ross Library American Academy in Rome Via Angelo Masina 5 00153 Rome Italy T: +39 06 5846 417 F: +39 06 5810 788 On Mon, Oct 12, 2015 at 11:38 PM, Robin Sheat <robin@catalyst.net.nz> wrote:
Bob Ewart schreef op ma 12-10-2015 om 16:05 [-0400]:
The Windows 7 workstation at the library is connected to the server on a local area network. My test system is running directly on the server. No proxies are involved. We've tried both Firefox and Chromium with no difference.
OK, so it's probably not something being dumb about cookies then :)
This said, it might pay to trace the network requests in the browse to ensure that there isn't a request that is zapping the cookie.
As you can see from the logs, there are a couple of xsub entries in the new database run that are not in my run before the volunteer sees the main page.
xsub comes from some date conversion code. The sooner we move to better logging and get file prefixes on things, the better :)
The "01:26 AUTH_SESSION: ()\t - " bit looks particularly suspicious, especially as there are some "Use of uninitialised value" warns right before it that aren't in your other log. I'd probably start looking around there.
The permissions are different in the two cases. I'm not sure why, but my database was originally created way back around 3.00 and errors may have crept in in the updates.
What happens if you make the permissions match? Probably making the one that doesn't work match the one that does...
-- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Sebastian Hierl schreef op di 13-10-2015 om 09:28 [+0200]:
I need to get to updating the wiki... we experienced a similar timeout issue, with the checkout and check-in commands performing with success, because of the expiration date ("enrollment period") of our patrons. We set some patrons such as staff to expire in 9999 -- it took Koha up to 1 minute to calculate the due date when checking out a book, which led to the time out. The problem was solved when we set the expiration date to 2032 in the Patron Category Administration (in the Koha admin. interface).
If you can get it to the point where someone could test it, then it's worth filing a bug on. It shouldn't happen and is certainly fixable. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
Should have been fixed by bug 13242 and bug 14494 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13242 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14494 2015-10-13 23:42 GMT+01:00 Robin Sheat <robin@catalyst.net.nz>:
Sebastian Hierl schreef op di 13-10-2015 om 09:28 [+0200]:
I need to get to updating the wiki... we experienced a similar timeout issue, with the checkout and check-in commands performing with success, because of the expiration date ("enrollment period") of our patrons. We set some patrons such as staff to expire in 9999 -- it took Koha up to 1 minute to calculate the due date when checking out a book, which led to the time out. The problem was solved when we set the expiration date to 2032 in the Patron Category Administration (in the Koha admin. interface).
If you can get it to the point where someone could test it, then it's worth filing a bug on. It shouldn't happen and is certainly fixable.
-- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
On 10/12/2015 05:38 PM, Robin Sheat wrote:
Bob Ewart schreef op ma 12-10-2015 om 16:05 [-0400]:
The Windows 7 workstation at the library is connected to the server on a local area network. My test system is running directly on the server. No proxies are involved. We've tried both Firefox and Chromium with no difference. OK, so it's probably not something being dumb about cookies then :)
This said, it might pay to trace the network requests in the browse to ensure that there isn't a request that is zapping the cookie.
As you can see from the logs, there are a couple of xsub entries in the new database run that are not in my run before the volunteer sees the main page. xsub comes from some date conversion code. The sooner we move to better logging and get file prefixes on things, the better :)
The "01:26 AUTH_SESSION: ()\t - " bit looks particularly suspicious, especially as there are some "Use of uninitialised value" warns right before it that aren't in your other log. I'd probably start looking around there.
The permissions are different in the two cases. I'm not sure why, but my database was originally created way back around 3.00 and errors may have crept in in the updates. What happens if you make the permissions match? Probably making the one that doesn't work match the one that does...
Auth.pm line 770 is trying to display the cardnumber, firstname, surname and branch which it got from $session->param(...). That occurs when checkauth is called. I did make the permissions, userflags and user_permissions tables match. No change. The apache access_logs showed my system had an extra entry to fetch the patron image. I turned the patronimages preference back to /"Don't allow" images to be uploaded and shown for patrons on the staff client/. Then everything worked as it should! When it was turned on, the volunteer should have been able to see my image. It did not display. -- Bob Ewart
participants (6)
-
Bob Ewart -
Jonathan Druart -
Katrin Fischer -
Liz Rea -
Robin Sheat -
Sebastian Hierl