This patch fixes a bug introduced by my patch for Bug 23405: Keyboard
navigation of patron autocomplete results was broken because I
incorrectly assumed that the autocomplete "select" action was redundant
because keyboard navigation would trigger the selected link. It doesn't!
This patch adds the "select" action back to the autocomplete
configuration, explicitly defining a redirect to match the URL which is
followed if the user uses the mouse to click a result.
To test you should have a patron in your database which has no card
number. Make sure CircAutocompl is enabled.
- From the circulation home page, type a patron name in the "Check out"
form and wait for autocomplete search results to display.
- Making a selection from the autocomplete results should work by
clicking with a mouse OR using the arrow keys and TAB or ENTER.
- Test with patrons with and without card numbers.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch modifies the JavaScript behind the patron search
results autocomplete widget which is displayed when typing in the search
header's "Check out" tab.
The script is modified to use the patron's borrowernumber instead of
cardnumber when redirecting to the checkout page.
Instead of copying the patron's card number into the search form and
triggering a submit, the autocomplete output uses direct links to each
result.
To better handle patrons with no card number, the output is modified to
show card number with parentheses only if card number is present.
To test you should have a patron in your database which has no card
number. Make sure CircAutocompl is enabled.
- From the circulation home page, type a patron name in the "Check out"
form and wait for autocomplete search results to display.
- Patrons with a card number should be listed in the format: Surname,
First name (Card number) Address.
- Patrons without a card number should be listed as: Surname, First
name Address.
- Clicking on either kind of result should link you the checkout screen
for that patron.
Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Signed-off-by: Ian Walls <ian@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch cleans up js_includes.inc by removing script "type"
attributes which are now invalid HTML. The patch also removes "CDATA"
markers from script blocks. They have been unnecessary since we stopped
using an XHTML doctype.
To test, apply the patch and look at various pages in the staff client
to confirm that no JavaScript-driven interactions are broken.
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test Plan:
1) Enable audio alerts
2) Note audio alerts don't work
3) Apply this patch
4) Note audio alerts now work
Use complex selectors to test:
#circ_returns p.problem:contains('Not checked out.')
#doc3 > #bd
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
IntranetUserJS was missing (?!)
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>
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 reverts commit ce6ec1e7fa.
https://bugs.koha-community.org/show_bug.cgi?id=21024
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch adds a system preference check around the call to the
JavaScript include which sets the bibs_selected cookie. With
BrowseResultsSelection disabled, the cookie should never be set.
To test you should be using a browser with a tool for inspecting
cookies. View the cookies for your Koha domain under each of these
conditions, clearing cookies between each step:
Without the patch applied:
- With BrowseResultSelection enabled, search for any item. Your cookie
tool should report that you have a bibs_selected cookie stored.
- With BrowseResultSelection disabled, search for any item. You should
have a bibs_selected cookie.
With the patch applied:
- With the BrowseResultSelection system preference enabled, search for
any item. Your cookie tool should report that you have a
bibs_selected cookie stored.
- With BrowseResultSelection disabled, search for any item. You should
have no bibs_selected cookie.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Having to write [% KOHA_VERSION %] for each url is bad because:
- It's easily forgettable when adding new <script> or <link>
- It prevents grep'ing for the full filename
- It violates the DRY principle
- If at some point we want to change the "force js and css reload"
mechanism, it will be tedious
This patch:
- adds a Template::Toolkit plugin that generates <script> and
<link> tags for JS and CSS files, and inserts automatically the Koha
version in the filename
- use the new plugin to remove all occurences of [% KOHA_VERSION %]
- remove the code that was adding KOHA_VERSION as a template variable
Test plan:
1. Apply patch
2. Go to several different pages in Koha (opac and intranet) while
checking your browser's dev tools (there should be no 404 for JS and
CSS files, and the Koha version should appear in filenames) and the
server logs (there should be no "File not found")
3. `git grep KOHA_VERSION` should return nothing
4. prove t/db_dependent/Koha/Template/Plugin/Asset.t
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds the same feature as bug 10858 for the OPAC interface:
after a search, librarians will be able to browse selected results.
The results can be selected from several pages.
By extension it is possible to add results from several pages to a list
or the cart.
When at least one result is selected, a new "Browse selected records" button
becomes usable and change the behaviour of the existing browser.
The whole feature can be turned off with the pref BrowseResultSelection.
Test plan:
- Launch a search (on the staff interface)
- Check some biblios
- Go on another page
- Check some biblios
- Come back to a page you already check results and confirm that they are
still checked
- Click on the "Browse selected records" button
- Check that you are able to browse results you had checked.
You can also:
- add them to the cart
- add them to a list
QA note: the browsers at the OPAC and the one at the staff interface are completely different
That's why the code is not mimicking what has been done on bug 10858.
The behaviour must stay the same anyway.
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch moves a line of template code from js_includes.inc back into
doc-head-close.inc where it belongs.
To test, apply the patch and view a page which uses a template that
depends on html_helpers.inc being processed. For example:
- The set library page
- The holds queue report
- The new patron form
The pages should work correctly.
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 17418 moved some code to js_includes.inc.
But if #findborrower does not exist, you cannot define _renderItem.
Trivial fix.
Test plan:
[1] Find a page where this include is used and #findborrowers is absent.
Like about.pl
[2] Without this patch, you will have a js error in the js console.
[3] With this patch, you should no longer have it.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@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>
In order to prepare to move staff client javascript assets into the
footer, this patch creates a new include file containing all <script>
content. This change should have no visible effect on how pages are
generated.
To test, apply the patch and view various pages in the staff client
(ciruclation, preferences, etc) to confirm that JavaScript is working
correctly.
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>
