Bug 9562

Summary: System preference 'insecure' shows wrong value after update to v3.10
Product: Koha Reporter: Fred P <fred.pierre>
Component: System AdministrationAssignee: Bugs List <koha-bugs>
Status: CLOSED WONTFIX QA Contact:
Severity: major    
Priority: P2 CC: gmcharlt, katrin.fischer, ztajoli
Version: 3.10   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:

Description Fred P 2013-02-06 22:25:31 UTC
There is an omission in the update script for v3.10, and it affects a critical system preference: 'insecure'

  On our v3.5 server the value corresponding to "Don't Allow" was recorded as "NO" - on the new system the value of "Don't Allow" is 0 (zero).

  WARNING: Changing the value to "Allow" (1) could completely hose your system and could require a new Koha installation!

  The update script did not change the table value from "No" to "0" so the 'insecure' system preference shows up as "Allow" even though the system interprets the "NO" value as "Don't Allow" for login functionality. In other words, we still have to log in, and our Koha system is fully functional.

  However this could lead updating clients to believe that the proper setting is "Allow" when production systems should really use "Don't Allow"

P.S. My past experience of switching to "Allow" was very negative - I could no longer log in to my system at all - luckily it was a test server.
Comment 1 Fred P 2013-02-07 15:26:06 UTC
In discussing this with other Koha administrators, this might be a legacy data issue. As early adopters of Koha we sometimes see issues with legacy data. If it is simple to add a fix to the update script, then it might help other users like us 

I'll try to figure out the coding, but something to the effect of:
Check insecure setting. If systempreferences.insecure is "NO" change to zero '0'
Comment 2 Katrin Fischer 2015-01-06 20:02:52 UTC
This is WONTFIX as the insecure system preference has been totally removed since - bug 9827. Good to see this one gone.