It is difficult for 3rd parties to trap a patron restriction reason because it is not easily identifiable. [AF] => Array ( [0] => Greetings from Koha. -- Patron needs to speak to a staff member. [1] => COEUR ) In this case, the explanation for the restriction is "Patron blocked for looking stupid." There is no common header for a restriction. I would suggest that restrictions be preceded by PATRON RESTRICTED:. So, the above example would look like: [AF] => Array ( [0] => Greetings from Koha. -- PATRON RESTRICTED: Patron needs to speak to a staff member. [1] => COEUR )
Now that we have Patron Restriction Types, I would rather see the restriction type included in the AF response instead of the generic "PATRON RESTRICTED". We have some restrictions that don't prevent a person from accessing online resources and some that do. This includes the automatic restrictions like long overdue items or excessive fines. For example: [AF] => Array ( [0] => Greetings from Koha. -- PATRON RESTRICTED: FINES [1] => LIBA) or [AF] => Array ( [0] => Greetings from Koha. -- CONDUCT: Patron is dangerous. Call the police [1] => LIBB) Then we could build SIP rules like these: If AF includes "OVERDUES" - deny access. If AF includes "FINES" - allow access. If AF includes "CONDUCT" - deny access. If AF includes "VERMIN" - allow access. "VERMIN" means bedbugs or other creepy crawlies hitched a ride on the library books they returned last week, so yes, they can use the online services, no they can't check out any more books.