On writing the regression tests, I noticed the CREATE offset was added
to the template. The idea behind passing the offsets is that we can
print information about the lines that got the credit applied. Having
the CREATE offset is meaningless, and (worse) would require users to add
logic to skip it. And all the payment information is already passed in
the 'credit' variable anyway.
This patch filters the credit_offsets by type, leaving the APPLY ones
only.
To test:
1. Apply up to the regression tests
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/Account.t
=> FAIL: 3 offsets, including the CREATE one, boo!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass! Only the two APPLY offsets are returned!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We already had exceptions on the many-to-many links, but we didn't have
them for the middle table. The underlying dbic relations make it clear
which id's are being used for linking. A 'credit' has 'credit_offsets',
a 'debit' has 'debit_offsets'.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The bug here was worse than originally thought. We were calling the
wrong relation too.. we should probably add some exceptions to catch
this, it confuses me every single time!
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Being based on _new_from_dbic (discussion on bug 28883), makes the
assignment incorrect:
my @account_offsets = $payment->debit_offsets;
This patch explicitly makes the resultset be assigned as a list by
calling *as_list*.
To test:
1. Have UseEmailReceipts disabled
2. Have a patron with a debt of 6
3. Make a payment of 2
=> SUCCESS: All good
4. Enable UseEmailReceipts
5. Repeat 3
=> FAIL: You get something like:
ERROR PROCESSING TEMPLATE: undef error - The method Koha::Account::Offsets->debit is not covered by tests!
Trace begun at /kohadevbox/koha/Koha/Objects.pm line 595
Koha::Objects::AUTOLOAD('Koha::Account::Offsets=HASH(0x561cbe2ac930)') called at input text line 6
eval {...} at input text line 6
eval {...} at input text line 23
6. Apply this patch
7. Repeat 3
=> SUCCESS: It doesn't explode anymore!
8. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a try/catch block when instantiating plugins. Calling
->new on a plugin eventually triggers a call to ->install (this has
always been like this since bug 7804). If the ->install method is
somehow borked, then the process dies. We need to prevent that, and
report back some error took place. That's what this patch does.
The same happens to the ->upgrade.
To test:
1. Install any plugin you like
2. Restart plack (just in case)
=> SUCCESS: All good
3. Manually change its install method to:
sub install {
die "plugin, die!";
}
4. Run:
$ koha-mysql kohadev
> DELETE FROM plugin_data;
(to make sure there's no __INSTALLED__ entry, do on a safe to delete DB).
5. Point your browser to the plugins-home.pl page
=> FAIL: Boom
6. Apply up to the regression tests
7. Run:
$ kshell
k$ prove t/db_dependent/Koha/Plugins/Plugins.t \
t/Koha/Exceptions.t
=> FAIL: Tests fail!
8. Apply this patch
9. Repeat 2
=> SUCCESS: Tests pass!
10. Run:
$ restart_all
11. Repeat 5
=> SUCCESS: The page is not broken
12. Sign off :-D
Note: I used
$ kshell
k$ perl misc/devel/install_plugins.pl
to test as well.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds regression tests for broken ->install and ->upgrade
methods on plugins.
It adds two dummie plugins named BrokenInstall and BrokenUpgrade, for
convenience.
Tests are added to catch the warnings that will be logged when trying to
load this plugins on different scenarios.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch introduces two new exceptions:
- Koha::Exceptions::Plugin::InstallDied
- Koha::Exceptions::Plugin::UpgradeDied
Tests are added for their stringification output.
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/Koha/Exceptions.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
"I don't like this patch at all!"
"We will see a cataloger revolt if we do not find a way to make this
optional for catalogers."
I imagined a hord of catalogers running behind me and I got scared.
This patch will allow to turn the new feature added by bug 25728 off.
Test plan:
Confirm that the new CreateAVFromCataloguing will permit to turn the
feature off.
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Use additional_report to retrieve patron and biblio's info.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch allows staff patrons to cancel multiple holds in bulk.
To test:
1. Apply this patch
2. restart_all
3. In cataloge go to a book and place many holds
CHECK => Holds table shows a column of checkboxes
4. Play with checkboxes (have some fun ;-P)
CHECK => When you manually check all checkboxes, the checkbox in the
header also gets checked.
=> When you uncheck one of the checkboxes, the one in the header also gets unchecked.
=> If no checkbox is checked and you check the one in the header,
all checkboxes get checked.
=> If there are some checkboxes that are checked and others are
not, when you click on the checkbox in the header all checkboxes get
unchecked.
=> If all checkboxes are checked, when you uncheck the one in the
header, all checkboxes get unchecked.
=> Every time you play with checkboxes, the number in the button
"Cancel selected" changes.
5. Check some of the checkboxes and click on cancel selected.
SUCCESS => A background job gets fired to cancel all selected holds.
=> A message should appear with a link to the job.
6. Wait a few seconds and click on the link
SUCCESS => A message appears with the report of the execution of the
background job.
7. Grab a patron and search to hold
8. Select multiple biblios and click on "place hold for <patron>"
CHECK => After holds are confirmed, multiple holds table are shown.. one for
each record. Checkboxes work exactly the same as before, but scoped
for each individual table. Checkboxes from one table will not affect
checkboxes from other tables.
9. Repeat steps 4 to 6.
10. Check In some of the items so the get in Waiting state.
11. Update expirationdate os some of those holds and set it to
ReservesMaxPickUpDelay + 1 days earlier
NOTE => ReservesMaxPickUpDelay = 7 days by default, so sql syntax to update would be
=> update reserves set expirationdate = date_sub(expirationdate, interval 8 day) where reserve_id in (...)
12. Repeat steps 4 to 6 but in waitingreserves.pl, in both tabs.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 23678: (QA follow-up) Add missing template filter
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 23678: (QA follow-up) Add missing filters
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 23678: (QA follow-up) Use correct indentation
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
JD amended patch: also Koha/BackgroundJob/BatchCancelHold.pm
JD Amended patch: Full rebase and adjustements made on top of bug 26080.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch changes the mapping so it is more readable, and also allows
adding things there more easily, like allowing to add code => class
mappings from plugins, when time comes.
To test:
1. Just verify things still work
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(Patch extracted from bug 28445 to make it reusable for bug 23678)
We already had the need for that, when bibliographic records are
modified in batch we wanted to add a "Add to list" feature, and so pass
a list of lists/virtual shelves to the template.
Here (in 28445) we will want to pass the infos of the items that have been modified
to display a table.
Test plan:
0. Create at least one list (virtual shelf)
1. batch update biblios
2. Go to the job detail
3. Notice that dropdown list to add the record to a list
=> No regression found!
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Same as the first patch, for authorities
Test plan:
Delete authority records using the batch record deletion tool
Confirm that the job is now delegated to the task queue and that
everything else is working as before
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
A new include file is created per background job to avoid
background_jobs.tt to grow too much
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch takes advantage of the task queue to delegate the batch
delete biblios tool.
Test plan:
Delete bibliographic records using the batch record deletion tool
Confirm that the job is now delegated to the task queue and that
everything else is working as before
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Koha::ApiKeys is no longer the simple object we need to test
Koha::Object->store, let use Koha::Library::Groups
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes the Koha::OAuth library use the new validation method
To test:
1. In master, enable RESTOAuth2ClientCredentials and have your
superlibrarian patron a client_id/secret pair generated
2. Use Postman to gain an access token with the client_id/secret pair
=> SUCCESS: This works in Koha
3. Use the access token to GET /api/v1/patrons
=> SUCCESS: It works
4. Apply this patchset up to the regression tests
5. Run:
$ updatedatabase
$ koha-plack --restart kohadev
=> SUCCESS: All good
6. Repeat 2
=> FAIL: You get an error trying to acquire an access token. Boo
7. Run:
$ kshell
k$ prove t/db_dependent/api/v1/oauth.t
=> FAIL: Tests fail!
8. Apply this patch
9. Run:
$ koha-plack --restart kohadev
$ kshell
k$ prove t/db_dependent/api/v1/oauth.t
=> SUCCESS: Tests pass!
10. Repeat 2
=> SUCCESS: Your original client_id/secret pair works!
11. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch makes the apikeys.pl display the generated API secret once,
when generated. After that, it won't be displayed by the UI.
To test:
1. Generate a new API key
=> FAIL: The secret is displayed in the API keys table
2. Visit some other page, and go back to the API keys page
=> FAIL: The API key secret is there
3. Apply this patch
4. Go to More > Manage API keys
=> SUCCESS: It no longer displays the secret
5. Generate a new API key
=> SUCCESS: The API key details (including the secret) are displayed.
=> SUCCESS: A message telling to copy the secret because it won't be
displayed again is shown.
6. Repeat 4
=> SUCCESS: The secret is no longer displayed
7. Sign off :-D
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch refactors the Koha::ApiKey class so:
- It encrypts the generated secret
- Allows accessing the plain text secret only immediately after the key
creation (this implies that it won't be accessible if the key is
fetched from the DB).
- It implements an allow list for attributes, that are not read only.
Changing any other of them will make ->store throw an exception.
- A method for validating plain text secrets against the encrypted one
is added.
- A method for accessing the plain text secret is added. Returns undef
if the object is not 'fresh'.
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/db_dependent/Koha/ApiKey.t
=> SUCCESS: Tests pass! Expected behavior is confirmed
3. Sign off :-D
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch limits the accessibility for "Manage API keys" section only
to superlibrarians and the owner of that said API key account.
The way it does it is by checking if user is superlibrarian or if
logged-in user is the same as a patron id/borrower number is the same
as logged-in user number both in template and apikeys.pl and making sure
the link is inaccessible or redirects to the 403 page if user tries to
go there directly.
To reproduce:
1) create/pick existing patron, set Staff access, allows viewing
of catalogue in staff interface (catalogue)" and "Add, modify and
iew patron information (borrowers)" permissions on;
2) enable "RESTOAuth2ClientCredentials" in sysprefs;
3) login with that user into staff interface;
4) check any other patron, go to the "More"->"Manage API keys" and
check that you can see, add delete their API keys;
5) apply patch;
6) with that same user try to access "Manage API keys" page again.
Ensure that you can't access that page of other patrons but can
access your own page and manage your own API keys.
7) log in with superlibrarian now and ensure that you can access every
"Manage API keys" page of every patron and apply changes there.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Remove fields from OPACSuggestionUnwantedFields before creating the
suggestion
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
JD amended patch: remove useless sort
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The following sequence is bad:
46 my $suggestion = $input->Vars;
181 &NewSuggestion($suggestion);
All columns can be set when we insert the suggestion into the DB
We definitely want to avoid the following fields to be set by the final
user: acceptedby, accepteddate, STATUS, etc...
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch prevents an existing user from exploiting the patron edit form in order to
force create new patrons
To test:
Try all combinations of PatronSelfRegistration and PatronSelfRegistrationVerifyByEmail
with and without this patch.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Security patch. Follow-up for 28929.
Including correction for gonenoaddress and two others.
Includes unwanted fields too now.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Bug 28929: (follow-up) Add exec flag to tests
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
* selfreg and selfmod for OPAC
* patron's edition on staff
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested OPAC and staff side. Prevents mangling flags column.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a keydown event listener onto the flatpickr instance and
looks for the down arrow key. When such an event is detected we take
that to mean the user wants to keyboard navigate the calendar widget and
so disable the buggy allowInput option allowing keyboard navigation to
work as expected.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch replaces the use of jQueryUI's datepicker on circulation and
patron-related pages.
The patch modifies Flatpickr's default configuration (in calendar.inc)
so that it has the following features:
- A Flatpickr input with a "futuredate" class will require that the
selected date be after today.
- The Flatpickr input field will be wrapped in a container to
facilitate better CSS styling.
- Generic handling of paired date fields is enabled using
".flatpickrfrom" and ".flatpickrto" field classes. This mimics the
same feature we have for jQueryUI datepickers using ".datepickerfrom"
and ".datepickerto".
This patch also removes an unused function which was repeated in three
templates: validate1.
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).
- Go to Circulation and check out to a patron.
- Open the Restrictions tab and click "Add manual restriction."
- In the "Expiration" field, test that the Flatpickr widget works
correctly and limits to dates after today.
- Enable the SpecifyDueDate preference if necessary.
- Test the behavior of the SpecifyDueDate controls: Setting a date,
clearing a date, session persistence.
- Enable the SuspendHoldsIntranet system preference if necessary.
- Check out to a patron with existing holds.
- Open the Holds tab and click the "Suspend" button for one of the
holds.
- In the modal window which appears, check that the Flatpickr
widget works correctly and limits to dates after today.
- At the bottom of the table of holds, test that the "Suspend all
holds" Flatpickr works correctly and limits to dates after
today.
- Perform this same test from the patron details page.
- Enable the BatchCheckouts system preference if necessary.
- Open a patron record and click "Batch check out" in the left-hand
sidebar menu.
- Test that the "Hard due date" Flatpickr works correctly as a date
and time picker.
- Go to Circulation -> Overdues.
- Test that the date due filters in the sidebar work correctly and
are linked, e.g. the "to" field cannot be before the "from" field.
- Perform the same test here: Circulation -> Holds to pull; and
here: Circulation -> Hold ratios.
- Enable the HouseboundModule system preference if necessary.
- Check out to or view details of a patron.
- Click "Housebound" in the sidebar menu.
- Save delivery day and frequency settings for that patron.
- Click "Add a new delivery."
- Test that the "Date" Flatpickr widget works correctly.
- Go to Patrons -> A patron record -> Edit.
- Test that Flatpickr widgets work on the following fields:
- Date of birth
- Registration date & Expiration date (linked).
- Patron restrictions -> Add manual restriction -> Expiration.
- View a bibliographic record and start the process of placing a hold.
- After selecting a patron, test the "Hold starts on" and "Hold
expires on" date fields. The fields should be linked and each
should limit to future dates.
- Confirm that the dates are saved correctly when you submit the
hold.
- Locate a bibliographic record with multiple holds and view the holds.
- In the table of holds, test each date field: Date, expiration, and
suspend-until.
- Test that Flatpickr's static "formatDate" method is working
correctly:
- Locate a bibliographic record's item so that there is text in both
the "Public note" and "Non-public note" field.
- Check that item out to a patron.
- After the page reloads the public and non-public notes should be
shown under the checkout title highlighted in red.
- Check for references to a "validate1" function. There should be none.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To Test:
1. Go to a record with some subscriptions, have some closed and some
open.
2. Go to the opac-detail page, click on the subscription tab and use
your developer tools to inscept the element.
3. Notice the hierarchy of HTML structure, everything is a sibling of
the next.
4. Apply patch
5. Reload the same opac-detail page and again inscept the element.
6. Now every individual subscription should be wrapped in an element
with the class name of 'subscription'.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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 bug adds a system preference to control ordering of facets and
adds the control to both Zebra and Elasticsearch
To test:
1 - Have a koha that can use both Zebra and ES
2 - Set 'displayFacetCount' to true
3 - Search in ES and Zebra
4 - Note facets in Zebra sorted alphabetically, ES by usage
5 - Apply patch, updatedatabase
6 - Search in ES and Zebra, facets are alphabetically sorted in both
7 - Find new syspref FacetOrder and set to 'by usage'
8 - Search in both engines, facets sorted by usage
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
