If the surname or firstname of a patron is NULL, the MySQL concat()
function (properly) returns NULL, leading to the patron name not
displaying in the overdue report.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
I know there's talk of getting rid of this patron search method, but I had a
request for this and so here it is.
To test:
verify that branchcode is displayed on patron search results from
circulation.pl.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Maybe not a complete fix, but hopefully an improvement. I couldn't
prevent it from wrapping at smaller browser widths, but I was
able to change the style so that when it does wrap it's a little
more readable.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Two parameters are now escaped in title (html element):
- query_desc
- limit_desc
This is a security correction against XSS.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
The 3 files had use strict missing. The patch add the use strict and modify what's needed to work with it
4XX.pl also has some perlcritic fixes:
Variable declared in conditional statement at line XXX, column 9. Declare variables outside of the condition. (Severity: 5)
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Now it more closely matches the one that's distributed in /etc
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
(not tested. I confirm the code is clean, and tests are not broken)
I've made changes to the basket grouping interface to bring it
in line with other interfaces in Koha. I think it's better to
keep things following a consistent pattern.
On the page which lists basket groups:
- Basket groups listed in a table instead of as custom-styled lists
- Buttons use standard style
- Tabs are generated by jQuery
On the page for managing baskets in a group:
- Markup has been revised to be more consistent with established
patterns.
- Corrections have been made for validity
On the basket view page:
- Display of data has been streamlined a little bit
- An option has been added to the "Basket group" dropdown
for adding a new group
- Markup has been corrected for validity and consistency
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
1) Basket group page
The blue is gone and the new buttons are much better
readable than before.
2) Basket grouping page
Works.
3) Basket view page
I like the new option to create a new group from here.
Nice improvement to the workflow!
I removed a spare 'td' from line 264.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
- Correcting permissions checks on the home page
- Adding default parameter (1) to numberofreviews subroutine
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
This patch adds count indicators on the staff client home page and
the tools page for the number of items pending approval. On the
home page this includes suggestions, comments, and tags. On the tools
page a count of pending comments and tags is shown.
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Counts appear for all types of actionable items listed, all are clickable through to the proper place.
Nice work!
Same fix that was done for normal order page and receive page.
Moving the style element for hiding the subfield into the li tag.
AcqCreateItem = on order
To recreate:
1) stage a marc file with 1 - many records
2) make sure you have an acq framework with hidden fields in 952
3) create new basket
4) order from your marc file
5) check item form below the record list for white space
Signed-off-by: Magnus Enger <magnus@enger.priv.no>
Followed the steps outlined by Katrin above. Before the patch there are gaping
holes left by the hidden fields. After the patch the holes are gone.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
When running the Items with no checkouts report and outputting to
screen, the results do not include any identifying information for
the items. The only information listed is the item count and the
branch location.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
If there is not a fine amount return zero not
undefined or other undefined behaviour
Use more meaningful var names for readability
Signed-off-by: Sophie Meynieux <sophie.meynieux@biblibre.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
On my laptop, this test was failing because some scripts had a conflict marker in a backup ... of a conflict I just fixed!
ignoring any file ending with a ~
245 Subfields in the Intranet Detail Display (MARC21slim2intranetDetail.xsl) are
being reordered on display. Instead of displaying 245$a 245$h 245$b, the
stylesheet was displaying 245$a 245$b 245$h. This patch does not address ISBD
punctuation.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Follow-up patch to address the issue in the staff client.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
245 Subfields in the OPAC Detail Display (MARC21slim2OPACDetail.xsl) are being
reordered on display. Instead of displaying 245$a 245$h 245$b, the stylesheet
was displaying 245$a 245$b 245$h. This patch does not address ISBD punctuation.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Clarified commit message.
A suggestion added through addorder.pl now changes
to the ORDERED status as initially intended (but so
far it stayed as ACCEPTED).
This fixes the list of potential suggestions to order,
the ORDERED ones don't appear anymore.
Bug 6893 : Follow-up: Disabled WHERE clause excluding ORDERED status
In SearchSuggestions, a WHERE clause was excluding the ORDERED
suggestions from the results. Now replaced with 1=1.
(before 6893 correction, the WHERE clause was excluding the
STATUS='CLAIMED' suggestions, but this status cannot be found anywhere
else in the code... so I changed to STATUS='ORDERED' which
seemed more accurate, but it had impacts on OPAC and some Admin tabs)
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Both patches applied cleanly, sqashed them together after testing.
Tested:
1) Creating new suggestions
- from OPAC, shows up in patron account as 'requested', pending in staff
- from staff, shows up in list of pending suggestions
Status in database is ASKED
Note: suggestions made from staff for the same patron have suggestedby = 0
in the database, so are not showing up in the patron account. Is this by
intention? (if not, I think this is a separate bug)
2) Accepting suggestions
- from list
- from edit page
Status in database is ACCEPTED
Patron account shows 'Accepted by the library (Bestseller)'
Note: after changing the status from the list, bug 4068 kicks in and
some tabs and even suggestions are hidden. Going back to the acq start
page and going back to the suggestions page from there helps.
3) Rejecting suggestions
- from list
- from edit page
Status in database is REJECTED
Patron account in OPAC shows 'Suggestion declined'
Note: bug 4068 again.
4) Ordering from suggestions
- new basket
- ordered 2 accepted suggestions
SUCCESS! Great improvement:
- Status in database is now ORDERED
- Already ordered suggestions no longer show up on list of
suggestions to order from.
- Patron account shows 'Ordered by the library (Bestseller)'
- Suggestion management page shows a new tab 'Ordered'
- For the suggestion with a valid 'suggestedby' borrowernumber,
a mail was generated. (bug 7094)
5) Receive ordered suggestions
- received my ordered suggestions
This is is not in the scope of this bug, but for documentation:
- No message was generated to inform the patron
- Status stays ORDERED
- Patron account still shows item as ordered, no change to 4)
Looking at the suggestion.tt I think there should be another status
AVAILABLE.
216 [% ELSIF (suggestion.suggestiontypelabel == "Available") %]Available
Signing off, fixes bug reported. Danke!
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Some of the translated sql files still had 'Item_DUE' instead
of 'Item_Due' causing the staff interface to display 'unknown'
instead of the correct description.
To test:
- Do a new installation, using German, French, Polish, Russian or Ukrainian sample files.
- Actived EnhancedMessagingPreferences
- Create a new patron category and check message descriptions display correctly
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
When importing users from LDAP, Auth_with_ldap.pm doesn't check if value for
categorycode is present in categories table in Koha resulting in referential
integrity error instead of using default value from koha-conf.xml
Test scenario:
1. enable LDAP in koha-conf.xml using <useldapserver>1</useldapserver>
and add <ldapserver> configuration with
<categorycode is="SomeLDAPField">DefaultCategoryCode</categorycode>
2. select/create LDAP user with category in SomeLDAPField which isn't in
Koha
3. try logging in and ensure that assigned category to new user is
DefaultCategoryCode
Signed-off-by: Marijana Glavica <mglavica@ffzg.hr>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
