Commit graph

6 commits

Author SHA1 Message Date
5a8e78fab0 Bug 29030: Make authorized value and description fields required
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>
2021-09-29 12:47:33 +02:00
7878aa0012 Bug 26274: Update register.tt to use the API
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>
2021-02-12 12:33:41 +01:00
c181f7a5e3 Bug 25728: Create AV when adding a new item
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>
2020-08-24 11:19:03 +02:00
Jonathan Druart
dcd1f5d48c Bug 13618: Add html filters to all the variables
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>
2018-08-17 15:55:05 +00:00
e215da87ff Bug 18327: Rename submit button with 'OK'
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2018-04-19 16:37:21 -03:00
4aa45fc489 Bug 18327: Same change for serials-edit
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>
2018-04-19 16:37:21 -03:00