As talked with Martin, this patches were originally developed before we
added the modals/ and str/ dirs, but we need to align it with current
way of doing it. This patch does that.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch updates the circulation system to account for bundle
checkins. We add a content verification step to ensure bundle content is
all present at checkin and we use this comparison to mark missing items
as lost.
Test plan
0) Apply patches up to this point
1) Checkin an item that belongs to a bundle
* An alert should be triggered noting that the item belongs to a
bundle
* The option to remove the item from the bundle should be clear
* Click remove should result in the alert dissapearing and the item
having been removed from the bundle.
2) Checkin an item bundle
* A modal confirmation dialog should appear requesting each item
barcode be scanned
* As items are scanned they should be highlighted in yellow in the
bundle content table
* Upon submission;
* The user will be alerted to any unexpected items that were
scanned and told to put them to one side.
* The user will be alerted that any missing items in the validation
will have been marked as lost.
* The bundle item will be marked as checked in.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Add a 'Resolve' button in the alert dialogue that is displayed when a
lost item with a return claim is checked in. The button will trigger the
usual resolution modal allowing the user to pick their resolution.
This patch splits the resolution modal out of checkouts.js and
checkouts-table.inc so it can be used outside of the checkouts table.
We then reload it, optionally based upon the presence of the claims
preference, where needed. This has the added benefit that it saves a
little bit of page load data in cases where the feature is not enabled.
Test plan
1. As we alter the file locations of the resolution handling code we
need to test that normal claims functionality continue to work as
expected.
2. Test the new functoinality by checking in an item that has been
claimed as returned (but not yet resolved). The dialogue box should
now contain a 'resolve' button next to each claimant and clicking
upon it should trigger the resolution modal where the librarian can
subsequently pick the resolution and submit it.
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch modifies the markup of the "Create a new authorized value"
modal so that a minimum set of fields is required: Authorized value and
description.
The patch also modifies the JavaScript which handles the submission so
that the jQuery Validation plugin can handle the field checks.
The spelling "authorised" is changed to "authorized" following coding
guidelines.
To test, apply the patch and rebuild the staff interface CSS
(https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff_client).
- Locate a record in the catalog which has items and open an item for
editing.
- In the add item form, test the process of adding an authorized
value on the fly with the following fields: Withdrawn, Lost,
Damaged, Use restrictions, Not for loan, Collection code, Shelving
location, and Shelving control number.
- In each case you should be able to type a new value in the
dropdown's search box and be shown the option "Select to create."
- Selecting should trigger a modal window, "Create a new authorized
value."
- Test that both "Authorized value" and "Description" fields are
required, and the form can't be submitted without them.
- Test that an error message shows up when you submit an authorized
value which already exists, e.g. authval "1" for "DAMAGED."
- After triggering this error, click the "Cancel" button and try
creating another new authorized value. When the modal reopens the
form should be reset: No previously-entered data, no error messages.
- Submitting a valid form with a new authorized value should work
correctly. The modal window should close automatically.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch updates the existing register details page to utilise the new
api routes to gather the summary details on demand.
Test plan
1/ Enable cash registers
2/ Add some transactions
3/ Perform a cashup
4/ Click 'Summary' next to the last cashup date
5/ Note the modal appears as it did prior to the patch being applied.
6/ Check the print option still works
7/ Signoff
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We do a bit of refactoring to make the code reusable.
Test plan:
Same as the first patch but when adding/editing an item
QA note: There is a warning from the QA tools
FAIL koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/additem.tt
FAIL js_in_body
A <script> tag found inside head, must be moved to the body (see bug 17858)
I don't think how we could avoid it.
Sponsored-by: Orex Digital
Signed-off-by: Hugo Agud <hagud@orex.es>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
And use an include file to avoid copy/paste
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
