Summary: | Opening system preferences page causes session to lose information | ||
---|---|---|---|
Product: | Koha | Reporter: | Owen Leonard <oleonard> |
Component: | System Administration | Assignee: | Galen Charlton <gmcharlt> |
Status: | CLOSED WORKSFORME | QA Contact: | |
Severity: | normal | ||
Priority: | P5 - low | CC: | chris, cnighswonger |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: |
Description
Chris Cormack
2010-05-21 01:22:54 UTC
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 |