This change fixes a typo from pa_loo to pa_class, so that
the ID attribute of the fieldset is properly set when using PA_CLASS
to group patron attributes.
Test plan:
0. Set up two PA_CLASS values
1. Set up two patron attributes which are viewable/editable on the
OPAC and assign them one class each
2. Go to http://localhost:8080/cgi-bin/koha/opac-memberentry.pl
3. Look at the HTML and note that fieldsets for both PA classes
have the ID of "aai_"
4. Apply the patch
5. Reload the page http://localhost:8080/cgi-bin/koha/opac-memberentry.pl
6. Note that now the fieldsets have ID attributes of
"aai_<PA_CLASS code>".
7. Rejoice as now it's easier to use Javascript and CSS and have valid
HTML!
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
This patch fixes a bug where, context-dependent, LinkWrapper can keep
referencing back to links that should be out of scope.
This was causing odd behaviour whilst writing Bug 14962 - namely, links
returning as the same value in a table of multiple rows due to
LinkWrapper treating linkData.href as one and the same for each row.
TO TEST:
== APPLY PATCH ==
a) enable ERMModule syspref, go to /cgi-bin/koha/erm/erm.pl
b) notice all links and buttons still work as expected
c) go to /cgi-bin/koha/sip2/sip2.pl
d) notice all links and buttons still work as expected
e) go to /cgi-bin/koha/acquisition/vendors
f) notice all links and buttons still work as expected
g) enable PreservationModule syspref, go to
/cgi-bin/koha/preservation/home.pl
h) notice all links and buttons still work as expected
== SIGN OFF ==
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
This patch adds the "Middle name" to the Contact information on moremember.pl,
and it adds "Preferred name:" when it differs from the "First name:". This
provides maximum clarity to staff users.
Test plan:
0. Apply the patch
1. Go to the "Patrons" module and search for or add a new patron
2. Add a firstname, a middle name, and a surname. Also add a "Preferred name"
which matches the firstname.
3. Go to "Details" on the sidebar, and note that "First name", "Middle name",
and "Surname" appear in the "Contact information".
4. Edit the patron and change "Preferred name" to a name that does not
match the "First name"
5. Go to "Details" on the sidebar, and note that "Preferred name" now shows
as well.
6. Enjoy fully comprehending which name is which for the patron!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
- The empty state message was shown when available_lists was empty
but the patron was already on all existing lists
- Add !in_lists guard so the message only displays when the patron
is truly not on any list
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
- When no patron lists exist in the system, the patron lists
tab on the patron detail page renders completely blank
- Other tabs follow the convention of showing a message in
the empty state (e.g. "Patron has nothing on hold.")
- Add an empty state message with a link to create a new
patron list, matching the established pattern
To test:
- Go to a patron detail page and click the "Patron lists" tab
- If no patron lists exist, observe the tab is blank
- Apply patch
- Repeat the above steps
- Verify the tab now shows "Patron is not on any list." with
a link to create a new patron list
- Click the link and create a patron list
- Return to the patron detail page and verify the "Add patron
to list" dropdown now appears instead
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Test plan:
Before applying the patch:
1. Go to acquisitions
2. Go to Purchase Suggestions
3. Create a purchase suggestion (for ease of testing, select Centerville for the library)
4. On the table, click on the suggestion number
5. Observe the suggestion does not populate, including the breadcrumbs, but the url does contain the suggestion number.
6. Apply the patch
7. restart_all
8. Rpeat steps 1-4
9. Observe the suggestion now populates and can be edited.
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
This patch prevents the UI to randomly change the language when reaching
addbooks
The problem is that getlanguage is called BEFORE get_template_and_user,
without, and "interface" (C4::Context->interface) is not set yet.
Open C4/Languages.pm, search "sub getlanguage"
We first read the cache, then if there is no interface we reach
GetTranslatedLanguages that does return languages in a random order,
then we pick the first one
765 @languages = map { $_->{rfc4646_subtag} } @{ getTranslatedLanguages( $interface, $theme ) };
783 $language = shift @languages unless $language;
We must call getlanguage AFTER that the cache is populated.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
The Handler::run change to skip disabled plugins broke the
RecordsFromMarcPlugin subtest in ImportBatch.t. The MarcFieldValues
plugin was installed but never enabled, so Handler::run returned
early. Add $plugin->enable() before calling RecordsFromMarcPlugin.
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
It appears that edi_cron.pl will run disabled EDI plugins. It uses Koha::Plugins::Handler::run that does not check if the plugins is gets are disabled.
Koha::Plugins::Handler::run needs to be fixed to not run disabled plugins.
Test Plan:
1) Apply this patch
2) prove t/db_dependent/Koha/Plugins/Plugins.t
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
This patch fixes the patron header search, so that you can do
patron searches from the header, but empty patron searches
are prevented and show a tooltip.
Test plan:
0. DO NOT APPLY THE PATCH YET
1. Log into the staff interface and try to search for anything
in the "Search patrons" header search
2. Note that nothing happens at all no matter how much you click
3. Apply the patch
4. Refresh the browser page
5. Try to search for anything in the "Seearch patrons" header search
6. Note that it performs the search
7. Empty out the input box and hit Enter or the search button
8. Note that a tooltip appears saying "Please enter a card number or name"
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
Create a list with name=<script>alert("booh!");</script>
Delete it at the OPAC
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
Read the patch. Look for the var in the script.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This change removes useless success_* calls, removes an unnecessary
'use URI::Escape qw( uri_unescape );' in the Perl, adds a missing
response function argument, uses a safe sink for the "verdict" element
to make the content setting a bit cleaner.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Adds a new subtest to t/db_dependent/Koha/Patron.t covering
fixup_cardnumber and the autoMemberNumValue counter:
- Normal increment bumps the counter
- Renaming a patron's cardnumber does not free it for reuse
- Deleting a patron does not free their cardnumber for reuse
- Counter wins when ahead of db_max
- db_max wins when ahead of counter
- Legacy fallback when the syspref row is absent
Also adds autoMemberNumValue to the exceptions list in
t/db_dependent/check_sysprefs.t. The preference is managed internally
by Koha::Patron::fixup_cardnumber -- it is not user-configurable and
has no entry in the admin preference YAML files.
Test plan:
1. prove t/db_dependent/Koha/Patron.t
2. prove t/db_dependent/check_sysprefs.t
3. prove t/db_dependent/Koha/Plugins/Barcode_transform_hooks.t
(confirm the patron_barcode_transform hook is still called twice
during store when autoMemberNum is enabled).
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
(cherry picked from commit 2091ef0fea)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When autoMemberNum is enabled, Koha picks the next cardnumber as
MAX(numeric cardnumber in borrowers) + 1. If patron A's auto-generated
cardnumber is later changed (e.g. they get a physical card) or the
patron is deleted, the original number becomes "free" and the next
self-registrant is assigned it -- inheriting anything third-party
services (OverDrive, Hoopla, unauthenticated self-check) have keyed on
the cardnumber.
This patch makes Koha::Patron::fixup_cardnumber use a monotonic counter
(the autoMemberNumValue syspref) so that once a number has been
auto-generated for any patron, it is never auto-generated again.
The syspref row is locked with SELECT ... FOR UPDATE inside the
existing txn_do, which serialises concurrent callers via InnoDB
row-level locking and addresses the race condition raised against
earlier revisions of this patch.
The formula is: next = MAX(counter, db_max) + 1. When the counter is 0
(pre-upgrade or missing syspref), this degrades gracefully to
db_max + 1 -- the legacy behaviour -- so no feature toggle is needed.
The counter is only bumped when Koha actually auto-generates a
cardnumber; plugin- or caller-supplied values do not touch it.
Test plan:
1. Enable autoMemberNum.
2. Self-register patron A via OPAC, note cardnumber N.
3. Edit patron A in the staff interface, change cardnumber to
something non-numeric like "MANUAL-XYZ".
4. Self-register patron B.
5. Confirm B gets N+1, NOT N.
6. Delete patron A.
7. Self-register patron C.
8. Confirm C gets N+2, NOT A's original number.
9. Install a plugin implementing the patron_barcode_transform hook;
confirm it still runs and its value is honoured (counter is not
bumped when the plugin supplies a cardnumber).
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
(cherry picked from commit ccfbb35de5)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Introduces a new system preference, autoMemberNumValue, which tracks
the highest auto-generated cardnumber ever issued. It is seeded from
the MAX cardnumber across both borrowers and deletedborrowers so
pre-upgrade deletions do not free numbers for re-issuance.
This preference is managed internally by Koha::Patron::fixup_cardnumber
and has no UI (no YAML entry).
Test plan:
1. Apply the atomicupdate:
perl installer/data/mysql/updatedatabase.pl
2. Verify the preference exists:
SELECT * FROM systempreferences WHERE variable = 'autoMemberNumValue';
3. Confirm the seed value matches:
SELECT GREATEST(
COALESCE((SELECT MAX(CAST(cardnumber AS SIGNED)) FROM borrowers
WHERE cardnumber REGEXP '^-?[0-9]+\$'), 0),
COALESCE((SELECT MAX(CAST(cardnumber AS SIGNED)) FROM deletedborrowers
WHERE cardnumber REGEXP '^-?[0-9]+\$'), 0)
);
4. Re-run the atomicupdate and confirm the already-exists warning.
5. Drop the syspref, re-apply the atomicupdate, confirm it seeds
correctly on fresh installs via mandatory/sysprefs.sql.
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Jacob O'Mara <Jacob.omara@openfifth.co.uk>
(cherry picked from commit aa84e99db8)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
/cgi-bin/koha/cataloguing/editor.pl
Click "Macros", "New macro..."
Enter <script>alert("booh");</script>
OK
Click on the macro name, run macro, delete macro, mark as public:
Nothing should trigger an alert
QA:
- $( '#macro-list li[data-name="' + name + '"][data-id="' + id + '"]' ).addClass( 'active' );
+ $( '#macro-list li[data-id="' + id + '"]' ).addClass( 'active' );
Why did we need name and id to select the macro?
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch builds the patron search description more carefully
to avoid XSS
Test plan:
0. Apply the patch
1. Log into Koha and click on "Patrons"
2. Change the "Category" and "Library" to any option but "Any"
and click "Search"
3. Type "test" into the data table "Search:" box
4. Note some text should appear on the screen similar to this content
and format:
Patrons found for: Anywhere: test
Library=Centerville, Category=Board
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
* Add Cypress tests to cover the 404 redirect if the pref is disabled
* Add "invoices" as possible embed option for
/acquisitions/vendors/:vendor_id
Seems relevant as the api def for invoice if expecting for it
api/v1/swagger/definitions/invoice.yaml
* Tell insertObject how to generate an invoice and return it.
Unfortunately we don't have a direct route for that, hence the embed
on /vendors/:vendor_id
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch makes it so that invoice-files.pl returns 404 if
AcqEnableFiles is disabled
Test plan:
0. Apply the patch
1. koha-plack --restart kohadev
2. Go to /cgi-bin/koha/acqui/invoice-files.pl?invoiceid=999
3. Note that you see a 404 page
4. Change "AcqEnableFiles" syspref to "Do"
5. Go to /cgi-bin/koha/acqui/invoice-files.pl?invoiceid=999
6. Note that you now see a "Files for invoice" page
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Local cover images are no longer displayed in OPAC lists since Bug 41078.
In Koha versions prior to 25.05.05, local cover images were correctly displayed in OPAC lists.
This appears to be a regression.
To reproduce
1. Set the system preferences LocalCoverImages and OPACLocalCoverImages to Show.
2. Find a bibliographic record and open the record detail page.
3. Upload a local cover image file for the record.
4. Create a public list and add the record to the list.
5. In the OPAC, open the public list.
--> The local cover image is missing.
6. Apply the patch.
7. Reload the OPAC list page.
--> The local cover image is now displayed correctly.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Test plan:
prove t/db_dependent/Reserves.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
'request' is unblessed in this context. get_type doesnt exist/work.
Test plan:
1) Enable ILLModule and ILLOpacUnauthenticatedRequest
2) Logout, place an OPAC unauthenticated ILL request, visit:
<opac_url>/cgi-bin/koha/opac-illrequests.pl?backend=Standard&op=add_form
3) Input all mandatory fields. Click 'Create'.
4) Notice 'Request type' shows as 'N/A'. This will always be the case regardless of type you pick.
5) Apply patch. Repeat. Notice 'Request type' now shows as expected.
Signed-off-by: Richard Bridgen <richard.bridgen@nhs.net>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
1) Install the following dummy backend plugin:
https://github.com/openfifth/koha-ill-backend-plugin/releases/tag/v2.0.9
2) Sys prefs preparation: Enable ILLModule, ILLOpacUnauthenticatedRequest and check PluginBackend on AutoILLBackendPriority
3) Logout, create a new Unauthenticated ILL request on the OPAC, visit:
<opac_url>/cgi-bin/koha/opac-illrequests.pl?op=create&backend=Standard
4) Fill in the mandatory top fields (first name, last name, email address and library)
5) Pick 'Book' for type and enter 'green' in title. This will cause the dummy plugin to be available in the AutoILL logic.
6) At the bottom of the form, on the "Verification" captcha, purposely input a wrong captcha e.g. '123'
7) Click 'Create'. Notice an odd looking form is presented, this is the dummy backend form, but it should present the 'Standard' form when using AutoILLBackendPriority as that was also the form we were presented with originally.
This happens because currently it's the backend that delegates back to Koha what template to render. When using AutoILLBackendPriority, however, Koha should handle this template delegation instead and present the Standard form.
8) Apply patches. Repeat test plan. Notice that now on step 7 you get the correct form, and error message (coming from Standard, as expected when using AutoILLBackendPriority).
9) Input the correct captcha this time
10) Confirm the created request landed in the PluginBackend backend.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
This is needed or else the OPAC still throws the 'malformed query string' mentioned on the original test plan.
This is because the fix from bug 40865 was only applied to intra datatables.js not the OPAC datatables.
I don't know why this fixes it for the OPAC, but it does.
Joubu, thoughts?
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
1) Install the unpaywall plugin:
https://github.com/openfifth/koha-plugin-ill-avail-unpaywall/releases/tag/1.0.2
2) Configure an email address on the plugin configuration (I believe any email address should work):
<staff_url>/cgi-bin/koha/plugins/run.pl?class=Koha%3A%3APlugin%3A%3ACom%3A%3APTFSEurope%3A%3AAvailabilityUnpaywall&method=configure
3) Enable ILLModule and ILLCheckAvailability sys prefs
4) Create a new ILL request, visit:
<staff_url>/cgi-bin/koha/ill/ill-requests.pl?method=create&backend=Standard
5) Pick type: journal article and enter the DOI: 10.1002/bjs.1800621024
6) Enter a cardnumber e.g. '42' for koha user and any library.
7) Notice the availability screen never renders, a console error is logged on the browser.
8) Apply patch. Refresh. Repeat.
This appears to have stopped working after bug 26553. Using git bisect, after bug 26553 (cc09868152), this started returning a 'bad request: malformed query string' because query params were being sent to the plugin API route (which doesn't consider them). Bug 40865 then fixed the bad request error, but resulted in the console error we see now, which is fixed by this patch.
ajax.dataSrc appears to now be returning an additional level of 'data' due to datatables upgrade (?), this patch changes the dataSrc override to be more in line with the example doc at https://datatables.net/reference/option/ajax.dataSrc
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
The term 'If any unavailable' is not very clear but it is also
very hard to find something short and better.
A next available hold is possible when at least one item is
unavailable (checked out, on order, waiting/transit hold).
A item level hold is possible when the specific item is
unavailable.
Test plan:
Read the patch. The code did not change.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
This change removes the "catalogue/getitem-ajax.pl"
which appears to be an unused file in Koha.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
WNC amended patch - tidied
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
When we edit a serial and we leave the date fields ('Published on' or 'Expected on') empty incorrect date are saved in the database 0000-00-00
instade of current date and we get Error 500
to reproduce
1. Connect to staff interface
2. Go to Serials and create a new subscription
3. Click on Serial collection in the left menu (and note the
Subscription numnber)
4. Select a serial to edit and Click on «Edit serials»
5. In the Serial edition form, delete «Published on > and « Expected on
» dates and save
----> Error 500 page is displayed
6. Check the value of «Published on > and « Expected on » dates in the
database
select planneddate,publisheddate from serial where subscriptionid=<Subscription numnber in step 3>;
------> planneddate publisheddate have «0000-00-00» value
7. Apply the patch
8. run ./installer/data/mysql/updatedatabase.pl
9. repeat step 2, 3, 4, 5, 6
-----> Error 500 page is no more displayed
-----> «Published on » and « Expected on » field have NULL as value
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Test plan (ktd):
1 - Have henry acevedo have no mail and set messaging preference "Hold filled to sms"
2 - Have edna acosta have not messaging preference
3 - Place an hold on two books for edna acosta and henry acevedo, check in both books and select the button to fill the hold
4 - Check in notices and see that both received a notice
5 - Apply tests and run tests -> they should fail
6 - Apply patch, run rest -> they should pass
7 - Unfill both holds and fill them back. Henry should keep receiving notices while Edna should not anymore.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
Two unit tests have been moved/replaced to fit the desired behaviour
- "patron notified when item set to waiting" -> does not fit the desired behaviour.
The desired behaviour for mails/sms is already tested
The desired behaviour for prints is changed to "patron not notified if
no messaging preference is specified"
- "patron not notified a second time (bug 11445)" -> Moved into
_koha_notify_reserve tests
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
To test:
1. Apply patch
2. Search fof the FilterSearchResultsByLoggedInBranch system preference and set it to 'Do'.
3. Do a catalog search and notice the 'Show local items only' button above the "Location" column.
4. Click it to show information ( in that column ) that is only related to the branch you are currently logged in at.
5. In the same result set have some items that are checked out, withdrawn, lost, damaged, and notforlaon.
6. Play more with the search results and ensure everything is accurate.
7. Set the FilterSearchResultsByLoggedInBranch system preference to 'Don't' and confirm that there is no button to filter by branch anymore.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
If you click Edit on a line with a note, the note field is not displayed
in the editing line and is blanked upon save (i.e., the note is lost,
even if you made no edits on the note). Value of the note is stored to
data-attribute which was changed to use Bootstraps own data-attribute.
So now the value must be fetched with keyword "bsContent" instead of
just "content".
To test:
1. Add note for a circulation rule.
2. Edit the rule.
=> Note that notes value is not displayed in editing row.
3. Apply this patch.
4. Edit rule again.
=> Note that notes value is now displayed as expected.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Laura Escamilla <laura.escamilla@bywatersolutions.com>
David Cook
Jake Deery
Paul Derscheid
Lisette Scheer
Jonathan Druart
Martin Renvoize
Kyle M Hall
Lucas Gass
Marcel de Rooy
Laura_Escamilla
Hammat Wele
Pedro Amorim
Baptiste
Emmi Takkinen