Just a find and replace on the changed system preference name.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
- Rename CircAutocompl system preference to PatronAutocompletion
- Take this system preference into consideration for patron search
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
In a production system, you don't usually search for the same
patron over and over, so there's no sense for the browser
to save a list of searched patrons in the patron quick
search. Therefore, should set autocomplete=off for that
input field.
Signed-off-by: Jose-Mario Monteiro-Santos <jose-mario.monteiro-santos@inLibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Here we go, next step then.
As we did not fix the performance issue when autofiltering
the variables (see bug 20975), the only solution we have is to add the
filters explicitely.
This patch has been autogenerated (using add_html_filters.pl, see next
pathces) and add the html filter to all the variables displayed in the
template.
Exceptions are made (using the new 'raw' TT filter) to the variable we
already listed in the previous versions of this patch.
To test:
- Use t/db_dependent/Koha/Patrons.t to populate your DB with autogenerated
data which contain <script> tags
- Remove them from borrower_debarments.comments (there are allowed here)
update borrower_debarments set comment="html tags possible here";
- From the interface hit page and try to catch alert box.
If you find one it means you find a possible XSS.
To know where it comes from:
* note the exact URL where you found it
* note the alert box content
* Dump your DB and search for the string in the dump to identify its
location (for instance table.field)
Next:
* Ideally we would like to use the raw filter when it is not necessary
to HTML escape the variables (in big loop for instance)
* Provide a QA script to catch missing filters (we want html, uri, url
or raw, certainly others that I am forgetting now)
* Replace the html filters with uri when needed (!)
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch alters the header and footer include files so that JavaScript
can be included in either one or the other. As a proof of concept, the
staff client home page is updated to include JS in the footer instead
of the header.
The processing of JavaScript included on individual pages can now be
similar to how it is done in the OPAC. A block is created with the
page's JavaScript which is then processed in js_includes.inc in the
correct order, after other required js assets.
On pages which have been modified to allow JavaScript to be moved to the
footer you must add a variable to the template: [% SET footerjs = 1 %].
Eventually all staff client templates should be modified so that setting
a flag is not required.
"[% MACRO jsinclude BLOCK %]" is used instead of "[% BLOCK %]" and "[%
PROCESS %]" because MACRO allows the template directives to be
processed correctly when included by intranet-bottom.inc.
To test, apply the patch and view the staff client home page.
- Confirm that you get a confirmation when deleting a news item from the
home page.
- Enable the CircAutocompl system preference and test that patron
autocomplete works from the "Check out" tab from the staff home page
and from other pages where the "Check out" tab is present.
- Test that JavaScript is working correctly on other pages like
Circulation, Preferences, etc.
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The root of this issue is old code in circulation.pl that is no longer
needed and leaves the affected scripts open to future regressions.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Heather Braum <hbraum@nekls.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If you edit notice triggers and then use the "Checko out" tab from the
top bar, you may change your logged in library by accident!
Test Plan:
1) Disable the system preference CircAutocompl
2) Go to the notice triggers
3) Select the triggers for a library other than the one you logged in as
4) Use the "Check out" tab at the top to check out to a patron
5) Note your logged in branch has changed ( you'll need to refresh the
page if the check out search took you directly to one patron ).
6) Apply this patch
7) Repeat steps 2-4
8) Note the branch no longer changes
Tested with both patches applied. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Heather Braum <hbraum@nekls.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Test plan:
1) Apply the patch
2) Type into search form patron's name & check his date of birth in
autocompletion
3) Go to intranet/cgi-bin/koha/members/member.pl & submit
a search with more than one result .. now should in the table appear
patron's date of birth
4) Try show/hide columns section if it works correctly for date of birth
5) Go to intranet/cgi-bin/koha/admin/columns_settings.pl -> go to
patrons section & check there is dateofbirth & it's functionality
Signed-off-by: Frederic Demians <f.demians@tamil.fr>
Works as described. Syspref dateformat respected. Column dateofbirth
configurable, but mandatory on autocompletion search result.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To test:
Apply the patch and see that the text now is there in the search
box when clicking the tabs: check in, check out etc..
(More files changed for persistent text in searchbox)
Sponsored-by: Halland County Library
Signed-off-by: Magnus Enger <magnus@enger.priv.no>
This is something I have wanted quite a few times over the years...
Tested by going to every main area of Koha, entering some random
text into the search box and then clicking on all the available tabs
to check that the entered text is carried over to all the boxes.
There are a couple of places where text is not carried over, but I
guess that might be because one of the boxes is structurally
different to the others. These are:
- "Vendor search" and "Orders search" in Acquisitions
- "Search subscriptions" in Serials
I have not looked at how this is implemented, just that it works as
it should.
Bug 14189 refactor after failed QA.
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Amended patch: replace tabs with spaces
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch upgrades the version of jQueryUI included in the Koha staff
client from v1.8.23 to v.1.10.4. The upgrade introduces a few minor API
changes which require the updates in this patch:
- In CSS, the term "active" is used instead of "selected"
- Autocomplete functions use slightly changed parameters
Changes to the default jQueryUI CSS allows us to remove some instances
of "!important" from jQueryUI-related CSS in the staff client's main CSS
file.
To test:
Testing changes to autocomplete:
- Enable the CircAutocompl system preference. Try searching in the
header's "Check out" tab. Autocomplete should look correct and
function correctly.
- In Circulation -> Overdues: The patron attribute authorized value
filter (must have patron attributes enabled, and a patron attribute
defined which uses authorized values.
- Course reserves -> Course -> Edit: Searching for an instructor
- In the unimarc_field_210c_bis.pl plugin:
1. Link the publisher name field in your MARC structure to
the unimarc_field_210c_bis.pl plugin.
2. Open a MARC record for editing and click the "tag editor" link to
launch the plugin.
3. Type the first few letters of a publisher which exists in your
database. You should get an autocomplete menu of publishers
which match your search.
4. Select one and click the "choose" button to fill the field in the
MARC editor.
- Tools -> Patron lists: Add a list or choose an existing list and add
patrons. Perform a search for a patron.
- Placing a hold: After choose a title and clicking "Place hold,"
search for a patron.
- Tags management: The sidebar filter for "reviewer" should let you
search by patron name.
Other jQueryUI widget changes:
- Check tabs appearance in header search, biblio detail, cataloging, and
circulation patron fines pages.
To confirm other jQueryUI widgets still function correctly:
- Check accordion (collapsing sections) in Patrons -> Patrons requesting
modifications and the MARC subfield structure edit screen.
- Check datepickers, especially in Circulation with the added timepicker.
Test a linked datepicker, for example in Reports -> Stats wizards ->
Circulation where the value in one date field affects what dates are
available in the matching field.
- Check the calendar interface in Tools -> Calendar
To confirm that the new jQueryUI default CSS is more flexible (fixing
Bug 11042), add the following CSS to your IntranetUserCSS system
preference and confirm that the header search active tab border color
changes (hash mark escaped so that it will appear in commit msg):
\#header_search ul.ui-tabs-nav li.ui-tabs-active {
background-color: #FFFFF1;
border: 1px solid #800000;
border-top: 0 !important;
top: -2px;
}
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Steps to reproduce:
1) Log into staff intranet
2) Set logged in branch
3) Browse to tools/overdue notice triggers
4) Select a branch from the pulldown that is not your logged in branch
5) use the "Check out" bar at the top of the page to search for a patron
to check out to
6) Once you have landed here, click the "check out" tab link again, or
the Edit button ( any action really )
7) Note your logged in branch has now changed to the once selected
when editing the notice/status triggers
This is due to the way the patron search passes the branchcode to be
used via the form. This form assumes the branchcode variable is
always the currently logged in branch, which may not and is not
always the case.
Test Plan:
1) Apply this patch
2) Repeat the steps to reproduce above
3) Note your logged in branch does not change
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Funny bug :) This patch fixes the described issue and should not
introduce regression.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
To test:
- Apply, then test the patron search form
Sponsored-by: Universidad Nacional de Córdoba
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
In order to facilitate a more painless process for converting
to jQueryUI I will submit separate patches for various "widgets,"
starting with Autocomplete.
This patch replaces all instances of YUI autocomplete with
a jQueryUI version. The patch includes an up-to-date version
of jQuery and jQueryUI libraries.
The patch also moves some markup in instances where it should
have been removed in favor of a different include.
To test, find the various autocomplete instances and confirm
that they are working:
- Circulation search header autocomplete
- Overdues patron attribute authorized value filter (must
have patron attributes enabled, and a patron attribute
defined which uses authorized values.
- Authorities search plugin. Edit a MARC record and use
an authorities plugin link to do a search for authority
records.
Incomplete: There is a YUI autocomplete instance in a UNIMARC
plugin (unimarc_field_210c_bis.tt) which I couldn't figure out
how to test, even on a sandbox set up with UNIMARC. I could use
help with a follow-up.
http://bugs.koha-community.org/show_bug.cgi?id=7447
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Passes all tests outlined, is quite pretty.
Passes t xt
Signed-off-by: Ian Walls <koha.sekjal@gmail.com>
If CircAutocompl is ON, the circ search form has a hidden <div> for use in
displaying live search results. For some reason WebKit browsers (Safari and
Chrome) treat this hidden element as a something that should create a line
break like any other block-level element. Moving the submit button to
before that hidden <div> fixes the problem without disrupting the display
of the live search results.
This changes some css and markup to make the return box at the top not show when one is on the checkin screen. It also moves the markup for the autocompleting search box to its own file.
Signed-off-by: Galen Charlton <galen.charlton@liblime.com>
