Bug 13108 - Members are restricted even if the debarment is ended - opac-reserve

This is the same issue as bug 12134.

Test Plan:
1) Add a manual restriction to a patron with expiration date in the past
2) Go on the OPAC and connect
3) Try to add an hold on a record (opac-reserve.pl)
3) Note the warning message
    "Sorry, you cannot place holds because your account has been frozen ..."
4) Apply this patch
5) Repeat step 2
6) Note the warning message does not appear anymore

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Makes code cleaner, also works as described.

NOTE: If you set a debarment with date in the past in the GUI,
there will be no entry in borrowers.debarred and you won't be
able to see the problem. Set one with a date in the future and
then alter the date in borrower_debarments and borrowers.debarred.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 13107 - Members are restricted even if the debarment is ended - opac-user

This is the same issue as bug 12134.

Test Plan:
1) Add a manual restriction to a patron with expiration date in the past.
2) Go on the OPAC and connect (opac-user.pl)
3) Note the warning message
    "Your account has been frozen until until XX/XX/XXXX ..."
4) Apply this patch
5) Repeat step 2
6) Note the warning message does not appear anymore

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described.

NOTE: If you set a debarment with date in the past in the GUI,
there will be no entry in borrowers.debarred and you won't be
able to see the problem. Set one with a date in the future and
then alter the date in borrower_debarments and borrowers.debarred.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 13039 - Vendor search: sorting of "item count" and "biblio count" columns can be incorrect

On the vendor search results page if some cells contain textual data the
"item count" and "biblio count" columns will sort incorrectly. This
patch sets an explicit numeric sort on these columns. In doing so this
patch also changes the existing column sorting configuration to use
table header cell classes instead of sorting based on index.

This patch also corrects two instances of unescaped ampersands.

To test, search for a vendor which has multiple baskets, at least one of
which should contain canceled orders. Confirm that sorting by item
count, biblio count, date, and closed all work correctly.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
I have not been able to see the sorting problem, but the
patch causes no regression and everything seems to work nicely.
Passes QA script and tests.

http://bugs.koha-community.org/show_bug.cgi?id=12039
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 13223: Plugin housekeeping: do not redefine wrapper

This report is connected to bug 10480 which will change the general
mechanism of loading plugins, but can be tested independently and ahead
of that proposed change.

Several unimarc plugins use a wrapper sub. The code of this subroutine
is not exactly the same for all plugins: in some cases the routine is
extended for double character strings (dblspace and dblpipe). It would
not hurt to use the extended code for all plugins.

By moving the code to a module, we prevent redefinition
when two or more plugins are loading wrapper in a do-statement.

NOTE: You will not see wrapper redefine errors in your log, since the
plugins do not use the warnings pragma (yet). Since this patch touches
seventeen unimarc plugins, a unimarc signoff is preferred :)

Test plan:
Use some plugins changed in this patch (if not in use already).
Load the MARC editor.
Click on some tag editor-buttons to check unchanged behavior.

Signed-off-by: Frederic Demians <f.demians@tamil.fr>
               Unimarc plugins work as usual. No regression. Simple code
               factorization.

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 13223: [QA Follow-up] Trivial change to one POD line

The line referred to Plugin while it should be FrameworkPlugin.
(I renamed the module in the process but forgot this line.)

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 13223: [QA Follow-up] Adding some unit tests for wrapper

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Trivially amended. Thanks, Katrin.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12132: display guarantees if a patron has them, regardless of category type

If a patron has guarantees, always display them on the patron summary,
even if the patron is of a type that ordinarily would have them.

For example, at present you can cannot directly add a guarantee to
a staff record the way you can do for an adult patron, but if you create
a juvenile patron and add a guarantor to it, you can override that
restriction.  Note that this patch ignores whether that is strictly
desirable behavior.

To test:

[1] Create a juvenile patron.  While editing it, make a staff
    account a guarantor of the new patron.
[2] View patron details for the staff account.  Note that the
    juvenile patron is not displayed as a guarantee.
[3] Apply this patch.
[4] Refresh details for the staff account.  The juvenile should
    now show up.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Frederic Demians <f.demians@tamil.fr>

Galen patch works as described. The way it's implemented seems sensible.
Whatever the reason why a patron has guarantes, it make sense to display
them. So it's better to check the count of guarantes rather than the
current patron type to decide to display guarantes.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, small change, no regressions found.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 7143 : Updating history and about page

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Checked the names with git log and Bugzilla.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>