---- Reported by oleonard@myacpl.org 2010-01-29 19:01:53 ---- 1. Log in to Koha 2. Query sessions table for current session info: | 6ad9053c6afa310f8f72d035c0ac635f | --- _SESSION_ATIME: 1264791068 _SESSION_CTIME: 1264791068 _SESSION_ID: 6ad9053c6afa310f8f72d035c0ac635f _SESSION_REMOTE_ADDR: 10.0.2.2 <snip> branch: APL branchname: Athens cardnumber: 0006067 emailaddress: oleonard@gmail.com firstname: Owen flags: 261887 id: 0006067 ip: 10.0.2.2 lasttime: 1264791068 number: 51 3. Click link for System Preferences. 4. Query sessions table again: | 6ad9053c6afa310f8f72d035c0ac635f | --- _SESSION_ATIME: 1264791209 _SESSION_CTIME: 1264791068 _SESSION_EXPIRE_LIST: {} _SESSION_ID: 6ad9053c6afa310f8f72d035c0ac635f _SESSION_REMOTE_ADDR: 10.0.2.2 <snip> branch: APL branchname: Athens cardnumber: 3127 emailaddress: oleonard@gmail.com firstname: Owen flags: 261887 id: 3127 ip: 10.0.2.2 lasttime: 1264791209 number: 51 After clicking the system preferences link my "cardnumber" and "id" session info has changed to "3127." I'm marking the bug critical because it worries me to see session data destroyed. However, I don't know what practical repercussions there are. --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:22 UTC --- This bug was previously known as _bug_ 4079 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4079 Actual time not defined. Setting to 0.0 The original assignee of this bug does not have an account here. Reassigning to the default assignee for the component, gmcharlt@gmail.com. Previous assignee was pianohacker@gmail.com. Bug reassigned, setting status to "NEW". Previous status was "ASSIGNED".
Owen, Can you confirm this is still a problem in the current HEAD? It seems to work fine in my test. After login: mysql> select * from sessions where a_session like '%184.0.137.59%'\G; *************************** 1. row *************************** id: 60a18143f41fab9e4aadae2e07d58e17 a_session: --- _SESSION_ATIME: 1288410426 _SESSION_CTIME: 1288410426 _SESSION_ID: 60a18143f41fab9e4aadae2e07d58e17 _SESSION_REMOTE_ADDR: 184.0.137.59 barshelves: [] branch: NO_LIBRARY_SET branchname: NO_LIBRARY_SET cardnumber: koha emailaddress: bheller@americanalpineclub.org firstname: koha flags: 1 id: koha ip: 184.0.137.59 lasttime: 1288410427 number: 0 <snip> 1 row in set (0.00 sec) After navigating to sysprefs editor: mysql> select * from sessions where a_session like '%184.0.137.59%'\G; *************************** 1. row *************************** id: 60a18143f41fab9e4aadae2e07d58e17 a_session: --- _SESSION_ATIME: 1288411789 _SESSION_CTIME: 1288410426 _SESSION_EXPIRE_LIST: {} _SESSION_ID: 60a18143f41fab9e4aadae2e07d58e17 _SESSION_REMOTE_ADDR: 184.0.137.59 barshelves: [] branch: NO_LIBRARY_SET branchname: NO_LIBRARY_SET cardnumber: koha emailaddress: bheller@americanalpineclub.org firstname: koha flags: 1 id: koha ip: 184.0.137.59 lasttime: 1288411789 number: 0 <snip> 1 row in set (0.05 sec)
A discover, after mucking with some JavaScript today and seeing the same transformation from "0006067," my card number to "3127." Turns out if you consider "0006067" to be an octal number and convert it to decimal you get 3127. Google says: http://www.google.com/search?q=3127+in+octal It looks like System Preferences doesn't like a card number starting with zero. That would explain why the bug was hard to reproduce.
This seems to be fine on current master I tried with a user with cardumber 0006067 And edited some sysprefs, it didn't get converted. _SESSION_ATIME: '1350439723' _SESSION_CTIME: '1350439564' _SESSION_ID: 46084274278b5c1a23aeefbe3ff9365a _SESSION_REMOTE_ADDR: 192.168.2.135 branch: L branchname: Levin cardnumber: '0006067' emailaddress: '' firstname: Christopher flags: 261825 id: chris ip: 192.168.2.135 lasttime: '1350439723' number: '1000018045' surname: Cormack