https://lists.katipo.co.nz/pipermail/koha/2017-January/047102.html

Note, from the mailing list: I am not able to recreate this issue.

Clint, could to try and recreate on a sandbox?

What is the line 472 of circ/circulation.pl?

Hello,
We experiment the same problem on our preprod install (3.22).
I'm not sure of this but probably It does not happen when the patron has no permission set (standard case). It could explain why Jonathan was not able to reproduce the error.
But from the moment you set whatever permission to the patron, you will get the error systematically. What is very strange is that the error persists even if you remove again the permission. I also try to empty the browser cache and cookies, restart starman service, close the browser and run again : seems that, when the patron has ever had any permissions in the past, he's condamned to cause the error (!!?).

Olivier Crouzet

as a temporary workaround, I put this in the intranetuserjs syspref :

$('#mainform').submit(function(event){
    if ( ! $('#barcode').val().length ) {
        event.preventDefault();
        window.location.replace("/cgi-bin/koha/circ/circulation.pl");
    }
});

Olivier Crouzet

(In reply to Koha Team Lyon 3 from comment #4)
> Hello,
> We experiment the same problem on our preprod install (3.22).

Are you able to test against master?
Can you recreate in a sandbox?

> I'm not sure of this but probably It does not happen when the patron has no
> permission set (standard case). It could explain why Jonathan was not able
> to reproduce the error.

When the blank page is displayed there is no borrowernumber parameter passed to circulation.pl, so it should not depend on the patron's info.

I tested against master (on a vbox) and at first sight, it seems OK. At least, no error, even if we set a permission to the patron.

But the issue is real on 3.22 (our preprod version is 3.22.12). A parameter is really passed to circulation.pl (probably in post method) and I can now assert that this parameter is the flags value (?!!). Don't ask me how it is but it is.
In the first comment from ClintD, the "1" string corresponds with no doubt to superlibrarian flags value.

To reproduce, you can try that. 
1) take a patron without any permissions and check that the error issue does not already occurs.
2) set a permission to him. Tick for instance the "reservesforothers" one (flags value = 64)
3) go back to checkout tab, put your cursor in the barcode input and press Enter :
you will get this :
Can't use string ("64") as a HASH ref while "strict refs"....
4) remove the permission
5) redo step 3. you will now get this :
Can't use string ("0") as a HASH ref while "strict refs"....

Confirmed and recreated on 16.11.x

Created attachment 60647 [details] [review]
Bug 18022: Fix possible crash if CircAutoPrintQuickSlip=clear screen

If CircAutoPrintQuickSlip is set to clear screen, the $borrowernumber variable
is reset but $borrower.
In 16.11.x and before that causes the app to crash, because
$borrower->{flags} is set to a hashref by GetMemberDetails, if
$borrowernumber is set.

This case is better handled in master (17.05) but side-effects could
happen: if $borrowernumber is reset, $borrower should be reset too.

The way to drive this behaviour is terrible and lot of things should be
done to clean this area. This patch is a quick and easy fix to make it
backportable easily.

Test plan:
On master, no change expected
On 16.11 and before:
0. Set CircAutoPrintQuickSlip=clear screen
1. Create a new patron
2. Set permission for this patron to 'reservesforothers' (or something
else).
3. Go on the circulation tab
4. Do not fill the barcode input and submit
=> Without this patch you will get an error
Can't use string ("64") as a HASH ref while "strict refs"....
=> With this patch apply you will get a blank screen (expected
behaviour).

I would recommend to test this patch with the other value of
CircAutoPrintQuickSlip as well

Tested on 16.11.x
Works as expected :
with CircAutoPrintQuickSlip system preference to "clear the screen." :
the screen is cleared
with CircAutoPrintQuickSlip system preference to "open a print quick slip/slip window." :
a print window is opened.

Olivier Crouzet

Can't say that terrible hacks look good, but at least we could move this patch to the queue of Katrin..

Please ping me on IRC about patches for 16.11.x - almost missed this! :)

This patch has been pushed to 16.11.x and will be in 16.11.07.

Pushed to 3.22.x for 3.22.20

Pushed to 16.05.x, for 16.05.12 release