]> git.koha-community.org Git - koha.git/log
koha.git
4 years agoBug 26524: Save some processor cycles
Jonathan Druart [Tue, 29 Sep 2020 14:06:19 +0000 (16:06 +0200)]
Bug 26524: Save some processor cycles

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26524: Add Koha::Acquisition::Basket->orders
Tomas Cohen Arazi [Wed, 23 Sep 2020 18:56:41 +0000 (15:56 -0300)]
Bug 26524: Add Koha::Acquisition::Basket->orders

This patch adds a handy accessor for a basket's orders. It can be used
to embed orders on an API call or be used in controller scripts to
replace C4::* methods.

To test:
1. Apply this patches
2. Run:
   $ kshell
  k$ prove t/db_dependent/Koha/Acquisition/Basket.t
=> SUCCESS: Tests pass!
3. Sign off :-D

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>
4 years agoBug 26524: Unit tests
Tomas Cohen Arazi [Wed, 23 Sep 2020 18:56:32 +0000 (15:56 -0300)]
Bug 26524: Unit tests

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>
4 years agoBug 26530: Use patron card number as checkbox label during patron merge
Owen Leonard [Fri, 11 Sep 2020 16:32:29 +0000 (16:32 +0000)]
Bug 26530: Use patron card number as checkbox label during patron merge

This patch makes a minor change the the merge patrons template so that
on the patron selection stage the user can click the card number to
select the radio button.

To test, apply the patch and perform a patron search in the patrons
module.

- In patron search results, select two patrons to merge.
- Click the "Merge selected patrons" button.
- On the page showing the two patrons to merge, click each of the card
  numbers to confirm that it selects the correct radio button.

Signed-off-by: Jennifer <jennifer.marlatt@coronaca.gov>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 25320: (follow-up) Remove obsolete include file
Owen Leonard [Tue, 29 Sep 2020 11:17:34 +0000 (11:17 +0000)]
Bug 25320: (follow-up) Remove obsolete include file

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 25320: Move translatable strings out of merge-record-strings.inc into merge-record.js
Owen Leonard [Thu, 18 Jun 2020 14:28:38 +0000 (14:28 +0000)]
Bug 25320: Move translatable strings out of merge-record-strings.inc into merge-record.js

This patch eliminates the use of a separate include file containing
translatable strings in favor of embedding translatable strings in the
JavaScript itself.

To test, apply the patch and clear your browser cache if necessary.

 - Perform a catalog search in the staff interface.
 - Select two results to merge. Click Edit -> Merge records.
 - Click "Next" on the "Merging records" page.
 - On the "Source records" page click the second tab where all the
   checkboxes are unchecked.
   - Check the box for a tag which is non-repeatable, e.g. 245.
     - You should see a message, "The field is non-repeatable and
       already exists in the destination record. Therefore, you cannot add it."
   - Check the box for a subfield which is non-repeatable, e.g. 245$a.
     - You should see a message, "The subfield is non-repeatable and
       already exists in the destination record. Therefore, you cannot
       add it."

TESTING TRANSLATABILITY

 - Update a translation, e.g. fr-FR:

   > cd misc/translator
   > perl translate update fr-FR

 - Open the corresponding .po file for JavaScript strings, e.g.
   misc/translator/po/fr-FR-messages-js.po
 - Locate strings pulled from prog/js/merge-record.js for
   translation, e.g.:

   #: koha-tmpl/intranet-tmpl/prog/js/merge-record.js:72
   msgctxt "Bibliographic record"
   msgid ""
   "The field is non-repeatable and already exists in the destination
   record. "
   "Therefore, you cannot add it."
   msgstr ""

 - Edit the "msgstr" string however you want (it's just for testing).
 - Install the updated translation:

   > perl translate install fr-FR

 - Switch to your newly translated language in the staff client and
   repeat the test plan above. The translated string should appear.

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>
4 years agoBug 26291: (follow-up) Correct stray MSG instances
Owen Leonard [Tue, 29 Sep 2020 11:29:29 +0000 (11:29 +0000)]
Bug 26291: (follow-up) Correct stray MSG instances

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26291: Move translatable strings out of z3950_search.inc into z3950_search.js
Owen Leonard [Mon, 24 Aug 2020 18:25:35 +0000 (18:25 +0000)]
Bug 26291: Move translatable strings out of z3950_search.inc into z3950_search.js

This patch moves translatable strings out of z3950_search.inc into
z3950_search.js, wrapped in the double-underscore function for
translation.

To test, apply the patch and go to Cataloging.

 - Click "New from Z39.50/SRU"
 - In the search form, uncheck all search targets and submit the form.
   You should get an error: "Please choose at least one external target"
 - Peform a search which will return multiple pages of results.
 - Test  that you can enter a number in the "Go to page" form to
   navigate to a specific page.
 - Enter a non-number in the field and submit. You should get an error,
   "The page entered is not a number."
 - Enter a number in the field which is greater than the number of pages
   of results. Submitting the form should trigger an error, "The page
   should be a number between 1 and 10."

 - Perform the same tests from the other Z39.50 search results
   interfaces:
   - Acquisitions -> Add to basket -> From an external source.
   - Authorities -> New authority -> New from Z39.50/SRU.

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

  > cd misc/translator
  > perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from
  koha-tmpl/intranet-tmpl/prog/js/z3950_search.js for translation,
  e.g.:

  msgid "The page entered is not a number."
  msgstr ""

- Edit the "msgstr" string however you want (it's just for testing).
- Install the updated translation:

  > perl translate install fr-FR

- Switch to your newly translated language in the staff client
  and repeat the test plan above. The translated strings should
  appear.

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>
4 years agoBug 26164: (and bug 26419) Compiled CSS
Jonathan Druart [Tue, 29 Sep 2020 09:47:41 +0000 (11:47 +0200)]
Bug 26164: (and bug 26419) Compiled CSS

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26562: Removes 'searches' from localStorage on logout
Jonathan Druart [Tue, 29 Sep 2020 09:43:00 +0000 (11:43 +0200)]
Bug 26562: Removes 'searches' from localStorage on logout

A user recently logged in will inherit the "searches" item stored in localStorage.

To recreate:
Log in with user A, do some searches
Note that the "searches" item is filled in with the search queries
Logout and log in with user B
Note that the "searches" item is still there

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26242: Remove one unused occurrences of MSG_NON_RESERVES_SELECTED
Jonathan Druart [Tue, 29 Sep 2020 08:48:04 +0000 (10:48 +0200)]
Bug 26242: Remove one unused occurrences of MSG_NON_RESERVES_SELECTED

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26330: Change encoding of text used as tab triggers in MARC subfield constraints
Owen Leonard [Tue, 1 Sep 2020 11:51:25 +0000 (11:51 +0000)]
Bug 26330: Change encoding of text used as tab triggers in MARC subfield constraints

This patch changes the encoding of the data being used to define
jQueryUI tabs on the MARC subfield constraints page. A jQueryUI bug
prevents non-Latin-1 characters from being used when defining tab
controls. Using Template:Toolkit's "uri" filter converts the data to
usable characters.

To test, apply the patch and go to Administration -> MARC frameworks ->
MARC structure -> tag 952 -> Edit subfields.

- Under the "New" tab, add a subfield code which is outside the basic
  Latin character set, e.g. £, §, æ.
- Save changes.
- Edit any subfield code to load the subfield constraints page again.
- Test that the subfield code tabs work correctly: Clicking each tab
  should load only the corresponding panel.
- Test a variety of tabs including the one you created with the
  non-Latin character.

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26431: Update NewsToolEditor system preference description
Katrin Fischer [Sat, 12 Sep 2020 17:24:36 +0000 (17:24 +0000)]
Bug 26431: Update NewsToolEditor system preference description

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26431: Use split button to offer choice of WYSIWYG or code editor for news
Owen Leonard [Thu, 30 Jul 2020 12:38:22 +0000 (12:38 +0000)]
Bug 26431: Use split button to offer choice of WYSIWYG or code editor for news

This patch modifies the news interface so that the user is offered a
choice of editing news items using the default editor as defined by the
NewsToolEditor system preference or the non-default one.

To test, apply the patch and go to Tools -> News.

- In the list of news items you should see an "Edit" split button in
  each row.
- Clicking the "Edit" part of the button should open the edit view with
  the correct editor as defined by the NewsToolEditor preference.
- Clicking the menu arrow on the button should offer the other editing
  method:
 - If NewsToolEditor is set to "WYSIWYG," the menu should offer "text
   editor."
 - If NewsToolEditor is set to "text editor," the menu should offer
   "WYSIWYG editor."
- Test the button with the NewsToolEditor preference set to both options
  and confirm that the button and menu work correctly.

Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26261: Split calendar.inc into include file and JavaScript file
Owen Leonard [Thu, 20 Aug 2020 20:10:40 +0000 (20:10 +0000)]
Bug 26261: Split calendar.inc into include file and JavaScript file

This patch moves most of the JavaScript out of calendar.inc and into a
new file, calendar.js. English strings in calendar.js are now wrapped in
the double-underscore function to allow for translation.

The patch shouldn't affect datepicker functionality in any way.

To test, apply the patch and test the datepicker in various contexts:

- Reports -> Statistics wizards -> Patrons
- Date of birth "from" and "to" should be linked so that the former
  must come before the latter.
- Patrons -> Add or edit patron
- The date of birth field datepicker shouldn't allow you to pick a
  future year from the dropdown.
- Tools -> Calendar.
- Test that the calendar tool works correctly.
- Test with various settings of the dateformat system preference.

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

  > cd misc/translator
  > perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from
  koha-tmpl/intranet-tmpl/prog/en/js/calendar.js for translation,
  e.g.:

  msgid "August"
  msgstr ""

- Edit the "msgstr" string however you want (it's just for testing).
- Install the updated translation:

  > perl translate install fr-FR

- Switch to your newly translated language in the staff client
  and test the datepicker again. Translated strings like days of
  the week and months should be correct.

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>
4 years agoBug 26164: Replace OPAC table sort icons with SVG
Owen Leonard [Sat, 8 Aug 2020 13:15:43 +0000 (13:15 +0000)]
Bug 26164: Replace OPAC table sort icons with SVG

This patch modifies the OAPC CSS to convert table sorting icons from PNG
to SVG. These icons are added via background-image data-urls, so only
the SCSS file is modified.

To test, apply the patch and rebuild the OPAC CSS
(https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff_interface).

- Clear your browser cache if necessary
- View any DataTable in the OPAC, for instance the table of
  checkouts under the logged-in user's "your summary" tab.
- Confirm that the sorting icons in the table headers look
  correct in each state: Sorted ascending, sorted descending, and
  unsorted.

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>
4 years agoBug 26419: Replace OPAC Koha logo with SVG
Owen Leonard [Tue, 9 Jun 2020 19:37:19 +0000 (19:37 +0000)]
Bug 26419: Replace OPAC Koha logo with SVG

This patch replaces the OPAC Koha logo PNG file with an SVG version.

To test, apply the patch and rebuild the OPAC CSS
(https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff_client).

 - Clear your browser cache if necessary.
 - View any page in the OPAC. The Koha logo in the upper-left corner of
   the screen should look good.

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>
4 years agoBug 26245: Remove unused functions from members.js
Owen Leonard [Wed, 19 Aug 2020 00:33:45 +0000 (00:33 +0000)]
Bug 26245: Remove unused functions from members.js

This patch removes some code from members.js which was unused.

To test, apply the patch and test that the process of adding or editing
a patron is unaffected. Check the Koha codebase for references to these
functions in JavaScript:

CheckDate
unique (note: Not the jQuery function)
check_manip_date
check_password

There should be none.

Signed-off-by: Brandon J <brandon.jimenez@inLibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26120: Remove the use of jquery.checkboxes plugin from tags review template
Owen Leonard [Sat, 1 Aug 2020 00:37:32 +0000 (00:37 +0000)]
Bug 26120: Remove the use of jquery.checkboxes plugin from tags review template

This patch removes the use of the jquery.checkboxes plugin and improves
the handling of tag status markup so that the "Select all pending"
selection link works correctly.

To test, apply the patch and go to Tools -> Tags. To test properly you
should have multiple tags awaiting moderation.

 - The initial view of tags moderation shows only tags awaiting
    moderation. Test that the "select all," "clear all," and "Select all
    pending" links work correctly.
 - Click the "Approve" button for a tag, and the "Reject" button for
   another tag.
 - Test the "Select all pending" link again. Only the tags awaiting
   moderation should be selected.

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>
4 years agoBug 26151: Remove the use of jquery.checkboxes plugin from suggestions management...
Owen Leonard [Wed, 5 Aug 2020 17:27:58 +0000 (17:27 +0000)]
Bug 26151: Remove the use of jquery.checkboxes plugin from suggestions management page

This patch removes the use of the jquery.checkboxes plugin from the
suggestions management page and replaces it with custom JS.

To test, apply the patch and go to Acquisitions -> Suggestions

Under each tab ("Accepted," "Pending," etc.), test that the "Check all"
and "Uncheck all" controls work correctly and only affect the table on
that tab.

Signed-off-by: Brandon J <brandon.jimenez@inLibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26504: Remove the use of jquery.checkboxes plugin from checkout notes page
Owen Leonard [Mon, 21 Sep 2020 19:16:14 +0000 (19:16 +0000)]
Bug 26504: Remove the use of jquery.checkboxes plugin from checkout notes page

This patch removes the inclusion of the jquery.checkboxes plugin from
the checkout notes page. It is unused.

To test, apply the patch and confirm that the AllowCheckoutNotes system
preference is enabled.

- Go to Circulation -> Checkout notes.
- Confirm that the "Select all" and "Clear all" links work correctly.

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>
4 years agoBug 24958: Remember last selected tab in SQL reports
Owen Leonard [Tue, 14 Apr 2020 18:49:35 +0000 (18:49 +0000)]
Bug 24958: Remember last selected tab in SQL reports

This patch modifies the saved reports page so that it remembers, for the
duration of the browser session, the last active tab.

To test you should have multiple reports in multiple report groups.
Apply the patch and go to Reports -> Saved reports.

- Select a tab to filter the table of saved reports to a particular
  report group.
- Navigate away from the page
- Return to the save reports page. The tab you previously selected
  should be selected again.
- Restart your browser and return to the saved reports page. The tab
  should no longer be preselected.

Update: The tabs filtering JavaScript has been moved to a separate
function so that the function can be triggered by both the "create"
event (when the tabs are initialized) and the "activate" event (when a
tab is selected).

Update II: Persistence is now enable through localStorage instead of
Cookies. The localStorage item is now cleared during the logOut
function.

Update III: The logOut() function in staff-global.js is now called by
auth.tt to ensure that tabs are not remembered across sessions.

Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26217: Move translatable strings out of templates into acq.js
Owen Leonard [Fri, 14 Aug 2020 18:12:09 +0000 (18:12 +0000)]
Bug 26217: Move translatable strings out of templates into acq.js

This patch removes the definition of translatable strings out of
templates and into the JavaScript file, using the new JS i81n function.

To test:

- Apply the patch, go to acquisitions, and view a vendor.
- Click "Uncertain prices" in the sidebar menu.
- In the table of orders, enter something in the "price" form field
  which isn't a valid price. You should get an error message.

- Test the validation of fund amounts: Go to Administration -> Budgets
  and create an active budget if necessary.
- Add a fund to that budget. Try to save the fund with a fund amount
  which exceed the amount in the budget.
- You should get an error message: "Fund amount exceeds period
  allocation"
- Add a fund with valid data and then go to Administration -> Funds and
  locate the fun you just created.
- Use the "Actions" menu to add a sub fund to that fund.
- Try to save this new fund with an amount which exceeds the amount in
  the parent fund.
- You should get an error message, "Fund amount exceeds parent
  allocation."

Note: I was unable to properly test the error message "New budget-parent
is beneath budget." I couldn't figure out how to trigger it.

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

> cd misc/translator
> perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from
  koha-tmpl/intranet-tmpl/prog/js/acq.js for translation, e.g.:

  msgid "Fund amount exceeds period allocation"
  msgstr ""

- Edit the "msgstr" string however you want (it's just for testing).
- Install the updated translation:

  > perl translate install fr-FR

- Switch to your newly translated language in the staff client
  and repeat the test plan above. The translated strings should
  appear.

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>
4 years agoBug 26256: Move translatable strings out of templates and into serials-toolbar.js
Owen Leonard [Wed, 19 Aug 2020 18:33:28 +0000 (18:33 +0000)]
Bug 26256: Move translatable strings out of templates and into serials-toolbar.js

This patch removes the definition of translatable strings out of
templates and into the corresponding JavaScript file, using the new JS
i81n function.

To test:

- Apply the patch and go to Serials and search for a subscription.
- Open the detail page for an open subscription.
- Click the "Close" button. You should get a confirmation, "Are you
  sure you want to close this subscription?"
- Confirm that you want to close it.
- When the page reloads, click the "Reopen" button. You should get a
  confirmation, "Are you sure you want to reopen this subscription?"
- Cancel.
- Choose Edit -> Delete subscription. You should get a confirmation,
  "Are you sure you want to delete this subscription?"
- Perform the same tests from the "Serial collection" page.

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

  > cd misc/translator
  > perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from
  koha-tmpl/intranet-tmpl/prog/js/serials-toolbar.js for translation,
  e.g.:

  msgid "Are you sure you want to delete this subscription?"
  msgstr ""

- Edit the "msgstr" string however you want (it's just for testing).
- Install the updated translation:

  > perl translate install fr-FR

- Switch to your newly translated language in the staff client
  and repeat the test plan above. The translated strings should
  appear.

Signed-off-by: Alexis Ripetti <alexis.ripetti@inLibro.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26243: (QA follow-up) Switch quotes to avoid translation issues
Katrin Fischer [Fri, 25 Sep 2020 20:24:20 +0000 (20:24 +0000)]
Bug 26243: (QA follow-up) Switch quotes to avoid translation issues

The QA script warned about text in single quotes which can be
a problem for languages like French that need to be able to use
these quotes in their translations.

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26243: Move translatable strings out of templates and into circulation.js
Owen Leonard [Tue, 18 Aug 2020 18:45:56 +0000 (18:45 +0000)]
Bug 26243: Move translatable strings out of templates and into circulation.js

This patch removes the definition of translatable strings out of
templates and into the corresponding JavaScript file, using the new JS
i81n function.

To test:

- Apply the patch and check out to a patron.
- If there are none on the account, add a new message using the "Add a
  new message" link.
- Click "Delete" for that message.
- You should get a confirmation message, "Are you sure you want to
  delete this message? This cannot be undone."
- If necessary, enable the ExportCircHistory system preference.
- Check out to a patron who has one or more items checked out.
- Wihtout checking any checkboxes, click the "Export" button at the
  bottom of the page.
- You should get an error message, "You must select checkout(s) to
  export."
- Add a restriction the patron's account.
- Delete the restriction. You should get a confirmation message, "Remove
  restriction?"
- Perform the same tests from the patron detail page.

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

  > cd misc/translator
  > perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from
  koha-tmpl/intranet-tmpl/prog/js/pages/circulation.js for translation,
  e.g.:

  msgid "You must select checkout(s) to export"
  msgstr ""

- Edit the "msgstr" string however you want (it's just for testing).
- Install the updated translation:

  > perl translate install fr-FR

- Switch to your newly translated language in the staff client
  and repeat the test plan above. The translated strings should
  appear.

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>
4 years agoBug 26118: Move translatable strings out of tags/review.tt and into tags-review.js
Owen Leonard [Fri, 31 Jul 2020 17:19:00 +0000 (17:19 +0000)]
Bug 26118: Move translatable strings out of tags/review.tt and into tags-review.js

This patch removes the section of the tags review template which defined
strings for translation. They can now be embedded in the JavaScript
file, wrapped in the __() function.

To test, apply the patch and clear your browser cache if necessary.

- Go to Tools -> Tags and perform some actions which will trigger the
  use of translated strings in the interface. For instance:
  - Approving and rejecting tags
  - Testing tags which are approved, rejected, or unclassified.
    - Status messages for these operations should work correctly.

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

> cd misc/translator
> perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from
  koha-tmpl/intranet-tmpl/prog/js/pages/tags-review.js for
  translation, e.g.:

  msgid "Both subfield values should be filled or empty."
  msgstr ""

- Edit the "msgstr" string however you want (it's just for testing).
- Install the updated translation:

> perl translate install fr-FR

- Switch to your newly translated language in the staff client and
  repeat the test plan above. The translated strings should appear.

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>
4 years agoBug 25321: Remove 2 remaining occurrences of strings.inc
Jonathan Druart [Tue, 29 Sep 2020 12:26:58 +0000 (14:26 +0200)]
Bug 25321: Remove 2 remaining occurrences of strings.inc

They were used for browser.js

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 25321: Remove PLACE_HOLD from results.js
Jonathan Druart [Tue, 29 Sep 2020 09:12:23 +0000 (11:12 +0200)]
Bug 25321: Remove PLACE_HOLD from results.js

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 25321: Move translatable strings out of strings.inc into the corresponding JavaScript
Owen Leonard [Fri, 21 Aug 2020 12:11:11 +0000 (12:11 +0000)]
Bug 25321: Move translatable strings out of strings.inc into the corresponding JavaScript

This patch moves string definitions out of strings.inc and into the
corresponding JavaScript files.

To test, apply the patch and test various pages in the staff interface:

A few suggestions:

- Perform a catalog search and view the detail page for a bibliographic record.
  - Confirm that the search results browser in the left-hand sidebar
    work correctly and that the title attributes of the controls are
    correct.
- Locate a patron with multiple checkouts. View the checkout page and
  test the various controls in the table of checkouts: Renew, check in,
  return claims, etc.
- View the list of holds on a patron's account. Test suspending and
  resuming holds.

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

  > cd misc/translator
  > perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from
  koha-tmpl/intranet-tmpl/prog/js/checkouts.js for
  translation, e.g.:

  msgid "Checked in"
  msgstr ""

- Edit the "msgstr" string however you want (it's just for
  testing).
- Install the updated translation:

  > perl translate install fr-FR

- Switch to your newly translated language in the staff client
  and repeat the test plan above. The translated strings should
  appear.

Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26240: Move translatable strings out of sms_providers.tt and into sms_providers.js
Owen Leonard [Tue, 18 Aug 2020 17:09:31 +0000 (17:09 +0000)]
Bug 26240: Move translatable strings out of sms_providers.tt and into sms_providers.js

This patch removes the definition of translatable strings out of
templates and into the corresponding JavaScript file, using the new JS
i81n function.

To test you must have the SMSSendDriver preference populated ("Email" is
fine).

- Apply the patch and go to Administration -> SMS cellular providers.
- Click "New SMS provider."
- The legend on the form's fieldset should read "Add an SMS cellular
  provider."
- Add an SMS provider.
- Edit an SMS provider.
- The legend on the form's fieldset should read "Edit provider <provider
  name>"
- If necessary, edit a patron's SMS settings to use one of your existing
  SMS providers.
- From the list of SMS providers, click to delete the provider which is
  in use.
- The error message should read "Are you sure you want to delete
  <provider name>? <number> patron(s) are using it!"
- Click to delete a provider which isn't in use. The error message
  should read "Are you sure you want to delete <provider>?"

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

  > cd misc/translator
  > perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from
  koha-tmpl/intranet-tmpl/prog/js/sms_providers.js for translation,
  e.g.:

  msgid "Add an SMS cellular provider"
  msgstr ""

- Edit the "msgstr" string however you want (it's just for testing).
- Install the updated translation:

  > perl translate install fr-FR

- Switch to your newly translated language in the staff client
  and repeat the test plan above. The translated strings should
  appear.

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>
4 years agoBug 26242: Move translatable strings out of results.tt and into results.js
Owen Leonard [Tue, 18 Aug 2020 17:43:22 +0000 (17:43 +0000)]
Bug 26242: Move translatable strings out of results.tt and into results.js

This patch removes the definition of translatable strings out of
templates and into the corresponding JavaScript file, using the new JS
i81n function.

To test:

- Apply the patch and perform a catalog search which will return
  multiple results.
- Without checking any checkboxes, click the "Add to Cart" button. You
  should see a message, "No item was selected."
- The same should happen if you select an item from the "Add to list"
  menu or click the "Place hold" button.
- Click the "Select all" link to check all checkboxes.
- Click the "Place hold" button.
- You will inevitably get a "One or more selected items cannot be placed
  on hold." message. If you were to want to complete this process you
  would have to painstakingly sift through each search result to find
  which item couldn't be placed on hold so that you could uncheck the
  corresponding checkbox. Luckily this test plan doesn't require you to
  do that.
- If you don't get an error message you're living in a catalog utopia
  unlike any I have ever seen.

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

  > cd misc/translator
  > perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from
  koha-tmpl/intranet-tmpl/prog/js/pages/results.js for translation,
  e.g.:

  msgid "Nothing is selected"
  msgstr ""

- Edit the "msgstr" string however you want (it's just for testing).
- Install the updated translation:

  > perl translate install fr-FR

- Switch to your newly translated language in the staff client
  and repeat the test plan above. The translated strings should
  appear.

Signed-off-by: Alexis Ripetti <alexis.ripetti@inLibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26237: Move translatable strings out of preferences.tt and into JavaScript files
Owen Leonard [Tue, 18 Aug 2020 15:11:10 +0000 (15:11 +0000)]
Bug 26237: Move translatable strings out of preferences.tt and into JavaScript files

This patch removes the definition of translatable strings out of
templates and into the corresponding JavaScript file, using the new JS
i81n function.

To test (a non-comprehensive list):

- Apply the patch, go to Administration -> System preference
- Modify any system preference. "modified" should appear next to the
  preference name.
- Click the "Save" button. You should get a message, "Saved preference
  <pref name>"
- Hover your mouse over a section heading (e.g. "Features" under
  Accounting). You should see a tooltip, "Click to collapse this
  section."
- Click to collapse the section. The tooltip should change to "Click to
  expand the section."
- Open a new tab for the staff interface and log out.
- In the original tab, modify and try to save a system preference. You
  should get a message, "Error; your data might not have been saved."

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

  > cd misc/translator
  > perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from
  koha-tmpl/intranet-tmpl/prog/js/pages/preferences.js for
  translation, e.g.:

  msgid "Saved preference %s"
  msgstr ""

- Edit the "msgstr" string however you want (it's just for
  testing).
- Install the updated translation:

  > perl translate install fr-FR

- Switch to your newly translated language in the staff
  client and repeat the test plan above. The translated strings
  should appear.

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>
4 years agoBug 26334: Move translatable strings out of members-menu.inc into members-menu.js
Owen Leonard [Tue, 1 Sep 2020 12:24:57 +0000 (12:24 +0000)]
Bug 26334: Move translatable strings out of members-menu.inc into members-menu.js

This patch moves translatable strings out of members-menu.inc into
members-menu.js where they can be translated using the double-underscore
i18n function.

To test, apply the patch and go to Patrons.

- Expand the search options in the search header by clicking the [+]
  link.
- Select "Date of birth" from the "Search fields" dropdown.
  - A tooltip should appear above the search form, "Dates of birth
    should be entered in the format..." with your current date format.
- Remove all "Adult" type patron categories but one.
  - Check out to a child patron.
  - From the "More" menu choose "Update child to adult patron."
  - You should see a confirmation.
- From the checkout screen, from the "More" menu, choose "Renew patron"
  - You should get a confirmation.

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

  > cd misc/translator
  > perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from
  koha-tmpl/intranet-tmpl/prog/js/members-menu.js for translation,
  e.g.:

  msgid "Are you sure you want to renew this patron's registration?"
  msgstr ""

- Edit the "msgstr" string however you want (it's just for testing).
- Install the updated translation:

  > perl translate install fr-FR

- Switch to your newly translated language in the staff client
  and repeat the test plan above. The translated strings should
  appear.

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>
4 years agoBug 26395: Move translatable strings out of letter.tt into letter.js
Owen Leonard [Fri, 4 Sep 2020 19:10:50 +0000 (19:10 +0000)]
Bug 26395: Move translatable strings out of letter.tt into letter.js

This patch moves strings defined for translation in letter.tt
into letter.js for translation using the new double-underscore
i81n function.

Note, the "MSG_NO_NOTICE_FOUND" usage has been removed because it didn't
work.

To test, apply the patch and go to Tools -> Notices & Slips.

- Use the "Copy" dropdown to copy an existing notice to a specific
  library.
- Save the copied notice.
- Return to the "All libraries" view on the Notices & Slips page.
- Repeat the same process above: Copy the same notice to the same
  library.
- When you click save on the "Add notice" page you should get an error
  message, "A letter with the code 'ACCTDETAILS' already exists for
  <library>"

- From the "All libraries" view on the Notices & Slips page, copy the
  text in the "Code" column of an existing notice.
- Click "New notice" and choose the module of the notice you copied
  from.
- On the "Add notice" page, paste the code into the "Code" field and
  enter a name in the "Name" field.
- Click "Save" without making any other changes. You should get an error
  message, "Please fill at least one template."
- Enter some data into one of the message body fields but not message
  subject, and click "Save" again.
- You should get an error, "Please specify title and content for
  <notice>"
- Enter data in the message subject field and click "Save" again.
- You should get an error, "A default letter with the code <CODE>
  already exists."

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

  > cd misc/translator
  > perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from
  koha-tmpl/intranet-tmpl/prog/js/letter.js for translation,
  e.g.:

  msgid "Please fill at least one template."
  msgstr ""

- Edit the "msgstr" string however you want (it's just for testing).
- Install the updated translation:

> perl translate install fr-FR

- Switch to your newly translated language in the staff client
  and repeat the test plan above. The translated strings should
  appear.

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>
4 years agoBug 26230: Move translatable strings out of item_search_fields.tt and into item_searc...
Owen Leonard [Mon, 17 Aug 2020 18:40:10 +0000 (18:40 +0000)]
Bug 26230: Move translatable strings out of item_search_fields.tt and into item_search_fields.js

This patch removes the definition of translatable strings out of
templates and into the corresponding JavaScript file, using the new JS
i81n function.

To test:

- Apply the patch, go to Administration -> Item search fields.
- If necessary, add a new search field.
- From the table of search fields, click the "Delete" button for one of
  the fields.
- You should get a confirmation: "Are you sure you want to delete this
  field?"

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

> cd misc/translator
> perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate the string pulled from
  koha-tmpl/intranet-tmpl/prog/js/item_search_fields.js for translation:

  #: koha-tmpl/intranet-tmpl/prog/js/item_search_fields.js:18
  msgid "Are you sure you want to delete this field?"
  msgstr ""

- Edit the "msgstr" string however you want (it's just for testing).
- Install the updated translation:

  > perl translate install fr-FR

- Switch to your newly translated language in the staff client
  and repeat the test plan above. The translated strings should
  appear.

Signed-off-by: Alexis Ripetti <alexis.ripetti@inLibro.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26229: Move translatable strings out of categories.tt and into categories.js
Owen Leonard [Mon, 17 Aug 2020 14:50:46 +0000 (14:50 +0000)]
Bug 26229: Move translatable strings out of categories.tt and into categories.js

This patch removes the definition of translatable strings out of
templates and into the corresponding JavaScript file, using the new JS
i81n function.

To test:

- Apply the patch, go to Administration -> Patron categories
- Click "New category"
- Enter some special characters in the "Category code" field, e.g.
  "%^&*"
- Try to submit the form without filling in any other details.
- The category code field should have a validation message, "Category
  code can only contain the following characters: letters, numbers, -
  and _."
- The enrollment period fields should have a validation message, "Please
  choose an enrollment period in months OR by date."
- Enter valid data and confirm that the form can be submitted.

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

  > cd misc/translator
  > perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from
  koha-tmpl/intranet-tmpl/prog/js/categories.js for translation, e.g.:

  msgid "Please choose an enrollment period in months OR by date."
  msgstr ""

- Edit the "msgstr" string however you want (it's just for testing).
- Install the updated translation:

  > perl translate install fr-FR

- Switch to your newly translated language in the staff client
  and repeat the test plan above. The translated strings should
  appear.

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>
4 years agoBug 26441: Move translatable strings out of catalog-strings.inc into catalog.js
Owen Leonard [Fri, 11 Sep 2020 19:39:08 +0000 (19:39 +0000)]
Bug 26441: Move translatable strings out of catalog-strings.inc into catalog.js

This patch moves translatable strings out of catalog-strings.inc into
catalog.js, wrapped in the double-underscore function for
translation.

To test that each affected string correctly appears in the interface:

- View the details for a bibliographic record which has items attached.
- From the Edit menu, choose "Delete record." You should get an alert,
  "X item(s) are attached to this record. You must delete all items
   before deleting this record."
- From the Edit menu, choose "Delete all items." You should get an
  alert, "Are you sure you want to delete the X attached items?"

- When logged in as a user with acquisitions and cataloging privileges,
  view the details for a bibliographic record which is used in an order
  in Acquisitions. Delete any items attached.
- Choose "Delete record" from the Edit menu. You should get an alert,
  "Warning: This record is used in X order(s). Deleting it could cause
  serious issues on acquisition module. Are you sure you want to delete
  this record?"
- In Acquisitions, view a basket containing orders. Cancel the
  order for a title in the basket. Open the detail page for the title in
  the cancelled order. Try to delete it. You should get an confirmation,
  "X deleted order(s) are using this record. Are you sure you want to
  delete this record?"
  - Perform the same test as a user with cataloging but not acquisitions
    privileges. The alert should say "X deleted order(s) are using this
    record. You need order managing permissions to delete this record."

- When logged in as a user with cataloging but not acquisitions
  privileges, view the details for a bibliographic record which is used
  in an order in Acquisitions. Delete any items attached.
- Choose "Delete record" from the Edit menu. You should get an alert, "X
  order(s) are using this record. You need order managing permissions to
  delete this record."

- View the details for a bibliographic record which has a hold.
- Choose "Delete all items" from the Edit menu. You should get an alert,
  "X hold(s) on this record. You must delete all holds before deleting
  all items."
- View the details for a bibliographic record which has no items.
- Choose "Delete record" from the Edit menu. You should get an alert,
  "Are you sure you want to delete this record?"
- Choose "Edit items in a batch" from the Edit menu. You should get an
  alert, "This record has no items."

I could not find any instance of the PopupZ3950Confirmed function in
catalog.js being triggered so I don't think the associated string can be
tested.

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

  > cd misc/translator
  > perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from
  koha-tmpl/intranet-tmpl/prog/js/catalog.js for
  translation, e.g.:

  msgid "This record has no items."
  msgstr ""

- Edit the "msgstr" string however you want (it's just for
  testing).
- Install the updated translation:

  > perl translate install fr-FR

- Switch to your newly translated language in the staff client
  and repeat the test plan above. The translated strings should
  appear.

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>
4 years agoBug 26225: Move translatable strings out of biblio_framework.tt and into biblio_frame...
Owen Leonard [Mon, 17 Aug 2020 13:04:27 +0000 (13:04 +0000)]
Bug 26225: Move translatable strings out of biblio_framework.tt and into biblio_framework.js

This patch removes the definition of translatable strings out of
templates and into the corresponding JavaScript file, using the new JS
i81n function.

To test:

- Apply the patch, go to Administration -> MARC bibliographic framework.
- Click Actions -> Export and save the file.
- Click Actions -> Import.
- Select a file which isn't CSV or ODS. You should get an error message,
  "Please select a CSV (.csv) or ODS (.ods) spreadsheet file."
- Select the file you exported previously and click "Import." You should
  see an error message, "Are you sure you want to replace the fields and
  subfields for the default framework structure? ..."
- Click "OK." You should see a message in the modal window, "Importing
  to framework:..."
- Edit your exported framework file in such a way that it isn't a valid
  framework export.
- Repeat the process of importing the file. You should get an error
  message, "Error importing the framework..."

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

  > cd misc/translator
  > perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from
  koha-tmpl/intranet-tmpl/prog/js/biblio_framework.js for translation,
  e.g.:

  msgid "Please select a CSV (.csv) or ODS (.ods) spreadsheet file"
  msgstr ""

- Edit the "msgstr" string however you want (it's just for testing).
- Install the updated translation:

  > perl translate install fr-FR

- Switch to your newly translated language in the staff client
  and repeat the test plan above. The translated strings should
  appear.

https://bugs.koha-community.org/show_bug.cgi?id=26226

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26225: Move translatable strings out of audio_alerts.tt and into audio_alerts.js
Owen Leonard [Mon, 17 Aug 2020 12:26:39 +0000 (12:26 +0000)]
Bug 26225: Move translatable strings out of audio_alerts.tt and into audio_alerts.js

This patch removes the definition of translatable strings out of
templates and into the corresponding JavaScript file, using the new JS
i81n function.

To test:

- Apply the patch, go to Administration -> Audio alerts.
- Click the "Delete selected alerts" button without checking any
  checkboxes. You should see an error: "Check the box next to the alert
  you want to delete."
- Check the checkbox for an existing sound and click "Delete selected
  alerts." You should get a confirmation message, "Are you sure you want
  to delete the selected audio alerts?"
- Click "New alert."
- Without filling any details, click the "Play sound" button. You should
  see an error message, "Please select or enter a sound."

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

> cd misc/translator
> perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from
  koha-tmpl/intranet-tmpl/prog/js/audio_alerts.js for translation, e.g.:

  msgid "Are you sure you want to delete the selected audio alerts?"
  msgstr ""

- Edit the "msgstr" string however you want (it's just for testing).
- Install the updated translation:

  > perl translate install fr-FR

- Switch to your newly translated language in the staff client
  and repeat the test plan above. The translated strings should
  appear.

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>
4 years agoBug 26339: Move translatable strings out of addorderiso2709.tt into addorderiso2709.js
Owen Leonard [Tue, 1 Sep 2020 13:46:35 +0000 (13:46 +0000)]
Bug 26339: Move translatable strings out of addorderiso2709.tt into addorderiso2709.js

This patch moves strings defined for translation in addorderiso2709.tt
into addorderiso2709.js for translation using the new double-underscore
i81n function.

To test, apply the patch and go to Acquisitions -> Vendor -> Basket ->
Add orders from MARC file.

 - Click "Add orders" next to a staged file.
 - Without making any selections, click "Save." You should get an error,
   "There is no record selected."
 - Select a record and click "Save." You should get an error, "Some
   budgets are not defined in item records."
 - Enter a non-numeric value in the "Quantity" field and click "Save."
   You should get an error, "1 quantity values are not filled in or are
    not numbers."

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

  > cd misc/translator
  > perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from
  koha-tmpl/intranet-tmpl/prog/js/addorderiso2709.js for translation,
  e.g.:

  msgid "Some budgets are not defined in item records"
  msgstr ""

- Edit the "msgstr" string however you want (it's just for testing).
- Install the updated translation:

  > perl translate install fr-FR

- Switch to your newly translated language in the staff client
  and repeat the test plan above. The translated strings should
  appear.

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>
4 years agoBug 25317: Move translatable strings out of additem.js.inc
Owen Leonard [Thu, 20 Aug 2020 15:53:28 +0000 (15:53 +0000)]
Bug 25317: Move translatable strings out of additem.js.inc

This patch moves the definition of translatable strings out of
additem.js.inc and into additem.js using the new JS i81n function.
additem.js.inc is removed, being obsolete.

To test:

When creating an order:

- Go to Administration -> System preferences and set "AcqCreateItem" to
  "when placing an order."
- Apply the patch and go to Acquisitions -> Vendor -> Add to basket ->
  From a new (empty) record.
- In the "Item" section, confirm that the buttons at the bottom of the
  form are correct: "Add item," "Clear," and "Add multiple items."
- Click "Add multiple items." The placeholder in the revealed form field
  should read "Number of items to add." The corresponding button should
  be labeled "Add."
- You should see a note, "NOTE: Fields listed in the 'UniqueItemsFields'
  system preference will not be copied."
- Fill out the item entry form and add a number to the "multiple items"
  field. Click "Add."
- A table of items should be displayed with "Edit" and "Delete" buttons
  for each new item.
- Click one of the "Edit" buttons. The item form should be populated
  with the item's data, with an "Update item" button at the bottom.

When receiving an order:

- Go to Administration -> System preferences and set "AcqCreateItem" to
  "when receiving an order."
- Go to Acquisitions -> Vendor -> Receive shipments.
- Select or create an invoice.
- Click "Receive" on an order which has a quantity greater than 1.
- Add two items, duplicating in each at least one value which is marked
  as unique by the "UniqueItemFields" system preference (e.g. fill in
  the same barcode number for each item).
- Click "Save." You should get an alert about duplicated values, and
  there should be an alert message on the page, "barcode 'XXX' is
  duplicated."
- Edit one of the two items and change the barcode to one which already
  exists in your database.
- Click "Save." An alert message should be shown on the page, "barcode
  'XXX' already exists in the database."
- Note: I was unable to find out how to trigger this error, "You can't
  receive any more items." It may be obsolete.

TESTING TRANSLATABILITY

- Update a translation, e.g. fr-FR:

  > cd misc/translator
  > perl translate update fr-FR

- Open the corresponding .po file for JavaScript strings, e.g.
  misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from
  koha-tmpl/intranet-tmpl/prog/js/additem.js for translation,
  e.g.:

  msgid "Add multiple items"
  msgstr ""

- Edit the "msgstr" string however you want (it's just for testing).
- Install the updated translation:

  > perl translate install fr-FR

- Switch to your newly translated language in the staff client
  and repeat the test plan above. The translated strings should
  appear.

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>
4 years agoBug 7143: Update about page for new dev - Alexis Ripetti
Jonathan Druart [Mon, 28 Sep 2020 14:18:51 +0000 (16:18 +0200)]
Bug 7143: Update about page for new dev - Alexis Ripetti

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26322: Permissions not checked correctly for plugins
Tomas Cohen Arazi [Mon, 31 Aug 2020 12:43:09 +0000 (09:43 -0300)]
Bug 26322: Permissions not checked correctly for plugins

This patch fixes the logic in a condition to address the fact that
permissions are not checked for plugins. This was due to bad parenthesis
pairing and the lack of good tests for this.

To test:
1. Apply the regression tests patch
2. Run:
   $ kshell
  k$ prove t/db_dependent/Koha/REST/Plugin/PluginRoutes.t
=> FAIL: Tests fail because of bad logic
3. Apply this patch
4. Repeat (2)
=> SUCCESS: Tests pass!
5. Verify the tests cover the use cases that are needed:
   - Anonymous access
   - Real user with wrong permissions (parameters => 1)
   - Real user with right permissions (borrowers => 1)
=> SUCCESS: Needed use cases so we catch any regression are found
6. Sign off :-D

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26322: Regression tests
Tomas Cohen Arazi [Mon, 31 Aug 2020 12:36:56 +0000 (09:36 -0300)]
Bug 26322: Regression tests

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26556: (bug 25070 follow-up) Fix typo data_addressfield in address includes
Fridolin Somers [Mon, 28 Sep 2020 13:47:34 +0000 (15:47 +0200)]
Bug 26556: (bug 25070 follow-up) Fix typo data_addressfield in address includes

Selecting "main address" city or "alternate address" city does not trigger the automatic population of values to the city, state, and zip fields anymore.
It woks for "alternate contact".

Test plan :
1) Create some cities with all datas : city, state, zip code and country
2) Open patron creation form
3) On "main address", select a city in combobox
4) Check city, state, zip code and country are filled
5) Same with "alternate address"

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 11176: Add active switch on budgets select in suggestions
Fridolin Somers [Thu, 24 Sep 2020 12:21:43 +0000 (14:21 +0200)]
Bug 11176: Add active switch on budgets select in suggestions

When creating a new purchase suggestion, all funds display and are available for selection.
The behaviour of this drop-down menu should mirror that of those drop-down menus elsewhere in acquisitions,
where only funds that are linked to active budgets display to the user.

This patch add the active switch based on what exists in acqui/invoice.tt and acqui/invoice.pl.

Looks like actually in suggestion.pl budgets list was fetches with GetBudgets().
But this is for the filter in 'Acquisition information'.
Budgets selection on suggestion creation/edition must use GetBudgetHierarchy(), like in acqui/invoice.pl,
in order to have the actif status.

Test plan :
1) Create a budget periods active B1 with a fund F1
2) Create a budget periods inactive B2 with a fund F2
3) Go to suggestions module
4) Create a new suggestion
5) Check you see only active fund F1
6) Click on 'Show inactive'
7) Check you see also 'F2 (inactive)'
8) Choose fund F1 and save
9) Select the suggestion and edit
10) Check fund F1 is selected
11) Come back to suggestion table
12) Check filter 'Book fund' under 'Acquisition information' contains all funds

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>
4 years agoBug 11223: Fix the ind1 semantics for 785 in the staff interface
Katrin Fischer [Mon, 21 Sep 2020 04:49:48 +0000 (04:49 +0000)]
Bug 11223: Fix the ind1 semantics for 785 in the staff interface

For 780 and 785 the field should not display when the first indicator
is 1. After checking the code, I found that 785 in staff was missing.
This patches fixes that one.

To test:
- Catalog a record with 785 and 780 fields with one 1st indicator set to
  0 and another to 1.
- Verify in staff and OPAC detail pages that only the fields with 0 display.

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>
4 years agoBug 15437: (follow-up) Move $i subfield display to the beginning and add OPAC
Katrin Fischer [Sun, 13 Sep 2020 15:06:46 +0000 (15:06 +0000)]
Bug 15437: (follow-up) Move $i subfield display to the beginning and add OPAC

This patch builds on Caitlin's to finish the work but keeping as
much from her code as possible.

- Finishes reindenting started in first patch
- Readds a space after the label
- Moves $i to the beginning of the field as suggested by MARC21
  documentation:
  http://www.loc.gov/marc/bibliographic/bd76x78x.html
  The data in subfield $i can be displayed preceding the other
  data contained in the field.
- Adds a span with a class around the $i so people can control
  the formatting

To test:
  - Catalog a record with 780/785 with and without $i.
  - Verify that they display nicely in staff and OPAC, $i should show.
    Also $a and $t will show (unchanged by this patch)

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 15437: MARC21: Show $i for 780/785
Caitlin Goodger [Wed, 18 Jan 2017 20:54:33 +0000 (20:54 +0000)]
Bug 15437: MARC21: Show $i for 780/785

Test Plan
1: Inside Administration go to MARC bibliographic framework and on the
default framework under Actions click on MARC structure
2: Search for 780 under search tag and under actions click subfields
3: Find i and click on edit.
4: Under Advanced Constraints select editor and save the changes.
5: Repeat for 785.
6: Find a Bibliograpical record and under Edit select edit record.
7: Under the 7 put values into 780 and 785. For this to work it is
dependant on the patch 17929 so that you can type into the indicators
8: When you save the changes you won't be able to see 780 or 785 on the
Bibliographical details
8: Apply the patch
9: Refresh and 780 and 785 should be there at the bottom under the
content

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26249: Set keep_text class correctly in cat-search.inc
David Cook [Wed, 19 Aug 2020 05:44:57 +0000 (15:44 +1000)]
Bug 26249: Set keep_text class correctly in cat-search.inc

This patch sets the keep_text class correctly in cat-search.inc
for the "Search the catalog" tab

To test:
1) Apply the patch
2) Go to /cgi-bin/koha/catalogue/search.pl
3) Type "A" into the search box for "Search the catalog"
4) Click on the "Check out" tab
5) Note that "A" appears in search box
6) Change "A" to "B" in search box
7) Click on the "Search the catalog" box
8) Note that "B" appears in the search box
9) Note no Javascript errors in the console

Signed-off-by: Didier Gautheron <didier.gautheron@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26478: Display issue with buttons on the self checkout screens
Owen Leonard [Thu, 17 Sep 2020 10:53:20 +0000 (10:53 +0000)]
Bug 26478: Display issue with buttons on the self checkout screens

This patch adds missing Bootstrap classes to a few buttons on the self
checkout page. Without the classes the buttons are not styled correctly.

To test, apply the patch and open the self checkout page for a patron
with multiple checkouts, some renewable and some non-renewable.

In the table of the user's checkouts the "Renew item" button should be
styled as a green button. The "Check in item" button should be styled as
a blue button.

Try to check out an item which cannot be circulated. On the page warning
you "Item cannot be checked out," the "Return to account summary" button
should be styled as a blue button.

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>
4 years agoBug 26512: Display issue with buttons for OPAC checkout note
Owen Leonard [Wed, 23 Sep 2020 11:48:00 +0000 (11:48 +0000)]
Bug 26512: Display issue with buttons for OPAC checkout note

This patch adds the correct Bootstrap 4 class to the buttons for
submitting checkout notes in the OPAC.

The markup has been updated to use <button> instead of <a> because of a
style conflict with jQueryUI's CSS.

To test, apply the patch and enable the AllowCheckoutNotes system
preference.

- Log in to the OPAC as a patron with checkouts.
- On the "Your summary" page, enter some text into a field in the
  "Notes" column of the checkouts table.
- Upon typing in the field a button should appear, "Submit note."
- The button should be styled as a green button.
- Submit the note.
- Make a change to the text in the field. A button should appear,
  "Submit changes." It should also be styled correctly.

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>
4 years agoBug 16357: Only use Log4perl middleware if appenders defined
David Cook [Wed, 26 Aug 2020 00:58:36 +0000 (00:58 +0000)]
Bug 16357: Only use Log4perl middleware if appenders defined

This patch checks that the loggers used by the middleware
actually have appenders defined.

Without this patch, if the loggers don't have appenders
defined in the log4perl file, the logs will just be lost.

Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 16357: (QA follow-up) Add log4perl configs during package upgrade
Joonas Kylmälä [Tue, 25 Aug 2020 12:22:29 +0000 (12:22 +0000)]
Bug 16357: (QA follow-up) Add log4perl configs during package upgrade

If plack.psgi is updated to the newer version and the log4perl.conf file
is not then the warnings will not be logged anywhere. This adds the
log4perl configurations that are needed for logging for pre-existing Koha
installation which are upgraded.

Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 16357: (QA follow-up) Only initialize Log4perl module
Joonas Kylmälä [Tue, 25 Aug 2020 12:10:20 +0000 (12:10 +0000)]
Bug 16357: (QA follow-up) Only initialize Log4perl module

Koha::Logger->get was setting up some extra variables
which are not used nor needed for the Plack::Middleware::Log4perl
middleware to work. According to documentation at
https://metacpan.org/pod/Plack::Middleware::Log4perl#SYNOPSIS
only running Log::Log4perl::init, enabling Log4Perl middleware and
setting up the logging category is enough. Koha::Logger->_init runs the
Log::Log4perl::init and enabling and setting category is handled
directly in plack.psgi.

Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 16357: Plack error logs are not time stamped
Mason James [Tue, 25 Aug 2020 06:08:28 +0000 (18:08 +1200)]
Bug 16357: Plack error logs are not time stamped

add libplack-middleware-logwarn-perl dependency to cpanfile

Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 16357: Use separate Log4Perl logger for each Plack app
David Cook [Fri, 26 Jun 2020 02:25:10 +0000 (02:25 +0000)]
Bug 16357: Use separate Log4Perl logger for each Plack app

This patch creates separate timestamped Log4Perl loggers
for each Plack app, so that the Intranet, OPAC, and API are logged
to separate files.

To Test:
0) apt-get install libplack-middleware-logwarn-perl
1) Apply "Alternative" patches
2) Copy PLACK block from etc/log4perl.conf to
/etc/koha/sites/kohadev/log4perl.conf and replace __LOG_DIR__ appropriately
3) Copy debian/templates/plack.psgi to /etc/koha/sites/kohadev/plack.psgi
4) Temporarily add 'warn "TEST"' to opac-main.pl and mainpage.pl
5) koha-plack --restart kohadev
6) Go to /cgi-bin/koha/mainpage.pl and /cgi-bin/koha/opac-main.pl
7) Open /var/log/koha/kohadev/plack-opac-error.log and
/var/log/koha/kohadev/plack-intranet-error.log
7) Observe a log line like the following:
[2020/06/22 03:51:23] [WARN] TEST at <SCRIPT and line #>.

Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 16357: Override __WARN__ in Plack to use Log4Perl
David Cook [Mon, 22 Jun 2020 03:53:16 +0000 (03:53 +0000)]
Bug 16357: Override __WARN__ in Plack to use Log4Perl

This patch overrides __WARN__ in Plack to use Log4Perl to add
timestamps to error output. The Log4Perl config uses a screen
appender so the output still goes to STDERR so that it is still
managed by Starman.

This patch adds a Plack::Middleware::LogWarn package dependency.
(The dependency is very simplistic, so we could always do out own
 version if we would prefer to skip the external dependency.)

To Test:
0) apt-get install libplack-middleware-logwarn-perl
1) Apply patch
2) Copy PLACK block from etc/log4perl.conf to
/etc/koha/sites/kohadev/log4perl.conf
3) Copy debian/templates/plack.psgi to /etc/koha/sites/kohadev/plack.psgi
4) Create some output on STDERR (it might be necessary to add
a 'warn "TEST";' line to the intranet or OPAC)
5) koha-plack --restart kohadev
6) Open /var/log/koha/kohadev/plack-error.log
7) Observe a log line like the following:
[2020/06/22 03:51:23] [WARN] TEST at /kohadevbox/koha/opac/opac-user.pl line 59.

Signed-off-by: Arthur Suzuki <arthur.suzuki@biblibre.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 17458: Remove use of datereceived from order receive page
Katrin Fischer [Tue, 14 Apr 2020 11:42:22 +0000 (11:42 +0000)]
Bug 17458: Remove use of datereceived from order receive page

Before this patch the order receive page (parcel.pl) would show
... Received by: <current user> On: <current date>

This is not really helpful. Whenever you viewed an invoice, it
would tell you it was _you_ who received that _today_.

As we don't store a creator of an invoice and the order lines
in an invoice could have been received by different people (which
we also don't know about), the "Received by" is removed by this patch.

Instead of today's date, we can show the shipment date entered for
the invoice. Again: different order lines could have been received
on different dates for this shipment. So only the shipment date makes
sense as it's on invoice level.

This also makes changes to the page title, breadcrumby and page heading:
When the invoice is closed, they will read:
  Receipt summary for [vendor] ...
When the invoice is not closed, they wil read:
  Receive orders from [vendor] ...

To test:
- Create a basket with some orders in acq
- Close the basket
- Receive shipment and create an invoice
  - Make sure shipment date is not set to today
- Verify the information shown on top of parcel.pl is you and today
- Change staff users
- Go to your invoice, it's now this user and today
- Apply patch
- Received by: should be gone and the On: replaced by Shipment date:
  with the date you selected
- Check the page title, breadcrumbs and headings read all the same 'Receive orders...'
- Finish receiving and close the invoice
- "Go to receipt page"
- Verify they now read "Receipt summary.."

If you have older invoices in your system, it would work
even better with these as you'd see that always today's date
is displaying without the patch.

Signed-off-by: Marjorie <marjorie.barry-vila@collecto.ca>
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>
4 years agoBug 23485: Show barcode in holds to pull
Andrew Fuerste-Henry [Wed, 16 Sep 2020 11:18:49 +0000 (11:18 +0000)]
Bug 23485: Show barcode in holds to pull

Updated to only show one barcode number, with either an "only" or an "or any available" depending on whether it's an item or bib hold.
Also incorporating feedback to simplify the TT logic and remove list formatting.

To test:
1 - Place an item level hold on a bib with several items with the same callnumber
2 - View the holds to pull report
3 - Try to guess which one on the shelf is right?
4 - Apply patch
5 - See the barcode in holds to pull report
6 - You can now grab the correct item (but don't yet)
7 - Place a next available hold on the same title
8 - See the report now shows one possible valid barcode with the text "or any available."
9 - Check in a different item that fills the next available hold
10 - Now the report shows the single item for the borrower

Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 24780: Make items.stocknumber show up in batch item modification
Katrin Fischer [Thu, 24 Sep 2020 21:52:33 +0000 (23:52 +0200)]
Bug 24780: Make items.stocknumber show up in batch item modification

It looks like the field was intentionally removed from the list
of batch editable fields in the past. This makes sense as we
used to have a unique index on it at some point - but we do have
no more.

This removes the exception so that the invendory number behaves
like the other fields on the batch item edit form.

To test:
- Create some items with and without stocknumber
- Go to tools > batch item modification
- Enter the barcodes of your selected items in the list or
  upload a file with them
- Verify that the stocknumber/inventory number is not showing
  in the item edit form below
- Apply patch
- Reload the page - inventory number is there now
- Batch edit the inventory number and verify it works as expected

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>
4 years agoBug 25624: Add --where option to update_patrons_category.pl
Jonathan Druart [Tue, 1 Sep 2020 13:07:49 +0000 (15:07 +0200)]
Bug 25624: Add --where option to update_patrons_category.pl

The script did not allow to find empty fields or use wildcards

With this new option we will now have the ability to filter patrons by
some of their attributes.

Test plan:
1 - Run the script with no parameters and verify the help explains the parameters
2 - Try the script with one or more --where parameters, like:
  --where "firstname='koha'"
3 - Test null values
  --where "firstname IS NULL"
4 - Test like values with wildcards
  --where "firstname LIKE '%a%'
5 - Test like with the word null to find fields containing the word rather than being unset

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>
4 years agoBug 26224: Prevent double submit of header check in form
Nick Clemens [Mon, 17 Aug 2020 10:16:14 +0000 (10:16 +0000)]
Bug 26224: Prevent double submit of header check in form

To test:
 1 - Browse to Home
 1 - In the header bar select the 'Check in' tab
 2 - Type a barcode into the box
 3 - Hit Enter as many as times as you can
 4 - Check the statistics table:
    SELECT * FROM statistics WHERE itemnumber={itemnumber} AND DATE(datetime)=CURDATE();
 5 - Note you have multiple lines for the same item at the same time
 6 - Apply patch
 7 - Reload the page
 8 - Type the barcode
 9 - Press Enter even more fast and more furiously
10 - Check the statistics table
11 - Only one entry, huzzah!

Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26323: (QA follow-up) Fix syntax errors
Katrin Fischer [Fri, 25 Sep 2020 16:28:17 +0000 (16:28 +0000)]
Bug 26323: (QA follow-up) Fix syntax errors

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26323: (follow-up) Add new cases introduced
Martin Renvoize [Fri, 25 Sep 2020 15:53:52 +0000 (16:53 +0100)]
Bug 26323: (follow-up) Add new cases introduced

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26323: Retrieve the correct values for LOST, DAMAGED, LOC and CCODE
Jonathan Druart [Thu, 3 Sep 2020 13:59:22 +0000 (15:59 +0200)]
Bug 26323: Retrieve the correct values for LOST, DAMAGED, LOC and CCODE

Same as previously

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26323: Retrieve the correct NOT_LOAN value
Jonathan Druart [Thu, 3 Sep 2020 13:37:15 +0000 (15:37 +0200)]
Bug 26323: Retrieve the correct NOT_LOAN value

From the template we are assuming that items.notforloan is mapped with
the NOT_LOAN authorised value category, but that is not necessarily the
case.

We must retrieve the correct AV category

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26414: Tidy the tests
Jonathan Druart [Mon, 28 Sep 2020 13:32:52 +0000 (15:32 +0200)]
Bug 26414: Tidy the tests

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26414: Unable to export Withdrawn status using CSV profile
Alexis Ripetti [Fri, 11 Sep 2020 20:11:55 +0000 (16:11 -0400)]
Bug 26414: Unable to export Withdrawn status using CSV profile

When using CSV profiles to export MARC records, it is impossible to export the withdrawn status. I suspect it is because withdrawn is in 952$0 and 0 is considered null rather than an actual 0.

Test Plan :
1) Go to Tools > CSV profiles
2) Click on New CSV profile
3) Enter a profile name (ex. Simple record)
4) In the Profile MARC fields field enter the following (for MARC21)
245a|100a|952o|9520
5) Save your profile
6) Go to Search and search for something
7) Add a couple of things in your cart
8) Go to your cart
9) Click on Download and choose your CSV profile
10) Open the file and notice the 9520 column contains the whole of the 952 field and not just the withdrawn status
11) Apply patch
12) Redo steps 9) and 10)

Signed-off-by: David Nind <david@davidnind.com>
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>
4 years agoBug 26418: Fix translatability of REFUND credit type
Martin Renvoize [Wed, 9 Sep 2020 14:34:13 +0000 (15:34 +0100)]
Bug 26418: Fix translatability of REFUND credit type

The description of REFUND type accountline credits introduced with the "issue refund" feature is not translatable.

To test:
- Make sure a language with a complete translation is installed
- Switch to the language
- Go to any user account
- Add a manual invoice
- Pay it off fully or partially
- Click on "issue refund"
- Confirm the refund
- Check the description of the line in the patron account is not translated.

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>
4 years agoBug 26424: Better performance of svc/checkouts
Fridolin Somers [Thu, 10 Sep 2020 13:12:39 +0000 (15:12 +0200)]
Bug 26424: Better performance of svc/checkouts

Ajax script svc/checkouts display checkouts of a patron.
For each item, it fetches a Koha::ItemType object and a Koha::AuthorisedValues object for location,ccode,lost and damaged.

For performance on huge number of checkouts :
Item types should be fetch once before the loop.
authorised values should call Koha::AuthorisedValues->get_description_by_koha_field because it uses a cache.

I've tested with Plack :
Without patch :
100 checkouts = 6 seconds
1000 checkouts = 60 seconds
With patch :
100 checkouts = 5 seconds
1000 checkouts = 44 seconds

Patch also changes the fact that authorised value categories are no longer hardcoded LOC,CCODE,LOST and DAMAGED, they depend on default framework.
Like is doing Bug 26323.

Test plan :
1) Dont apply patch
2) Use sql to define some items lost and damaged
3) Look at checkouts table on a patron with a lot of checkouts
4) Apply patch
5) Look at checkouts table again
6) Check infos are the same : record level item type, item type, location, collection, lost, damaged
7) Check infos are the same in "Number of checkouts by item type"

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26490: Fix column configuration for fines trasactions
Katrin Fischer [Sun, 20 Sep 2020 22:06:32 +0000 (22:06 +0000)]
Bug 26490: Fix column configuration for fines trasactions

Hiding the last columns on the fines transactions in the
patron account in staff didn't work correctly as we had missed
adding Home library to the configuration options when it was
added.

This adds the missing definition and now all columns can be
toggled correctly.

To test:
- Go to any patron account in staff
- Go to Accounting > tab transactions (maybe add some fines)
- Toggle the columns on the table using the menu, especially
  - notes, home library and checkout date
- Go to Administration > Table configuration
- Verify the settings for the table work well from there too -
  with the patch, home_library will show as new option

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>
4 years agoBug 26497: "Hide all columns" throws Javascript error on aqplan.pl
Owen Leonard [Mon, 21 Sep 2020 10:59:56 +0000 (10:59 +0000)]
Bug 26497: "Hide all columns" throws Javascript error on aqplan.pl

This patch updates the JavaScript for checking and unchecking checkboxes
on the Acquisitions planning page so that it doesn't require the
checkboxes plugin.

To test, apply the patch and go to Administration -> Budgets -> Budget
details -> Planning.

On the planning page, test the "Show all columns" and "Hide all columns"
checkboxes. They should work correctly to show and hide the correct
columns.

Signed-off-by: Henry Bolshaw <bolshawh@parliament.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26541: Remove percent sign from discount button
Andrew Fuerste-Henry [Fri, 25 Sep 2020 21:09:03 +0000 (21:09 +0000)]
Bug 26541: Remove percent sign from discount button

Realized I'd left a stray tag, fixed.

To test:
1 - go to borrower account, apply manual fee
2 - go to Transactions tab and see that fee has "% Apply discount" button
3 - apply patch, restart, reload page
4 - button just says "Apply discount"

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>
4 years agoBug 16314: Compiled CSS
Jonathan Druart [Mon, 28 Sep 2020 09:09:30 +0000 (11:09 +0200)]
Bug 16314: Compiled CSS

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 15933: Add +x to the script
Jonathan Druart [Mon, 28 Sep 2020 08:36:40 +0000 (10:36 +0200)]
Bug 15933: Add +x to the script

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26384: Add .t extension to make the script executed by CI
Jonathan Druart [Mon, 28 Sep 2020 08:35:01 +0000 (10:35 +0200)]
Bug 26384: Add .t extension to make the script executed by CI

The test file is not run as it does not have the .t extension

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26505: Suspend hold modal broken in the OPAC
Owen Leonard [Tue, 22 Sep 2020 11:01:30 +0000 (11:01 +0000)]
Bug 26505: Suspend hold modal broken in the OPAC

This patch makes corrections to the markup for the suspend hold modal in
the OPAC. It hadn't been updated during the upgrade to Bootstrap 4.

The JavaScript controlling the "suspend until" datepicker has been
modified because the datepicker pop-up was not positioned correctly in
this new version.

Unrelated: The markup for confirmation modals has been updated to
replace Bootstrap 3's "btn-default" with Bootstrap 4's "btn-secondary."

To test, apply the patch and make sure the SuspendHoldsOpac and
AutoResumeSuspendedHolds system preferences are enabled.

- Log in to the OPAC as a user who has holds.
- On the "Your summary" page open the "Holds" tab.
- In the list of holds, click the "Suspend" button.
- The modal should appear and look correct.
- Test the "Suspend until" field: Clicking in the form field should
  trigger the datepicker. It should be positioned correctly under the
  form field.
- Confirm that the datepicker populates the field.
- Submit the suspension and confirm that the hold is suspended.
- Click the "Cancel" button for a hold. Confirm that the confirmation
  dialog appears correctly.

Edit: Updated class of hidden submit button. Test the page with JS
disabled to test that the "Suspend until" form works correctly.

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>
4 years agoBug 25758: Return on_reserve over too_soon when not calling from automatic_renewals...
Nick Clemens [Fri, 4 Sep 2020 12:47:58 +0000 (12:47 +0000)]
Bug 25758: Return on_reserve over too_soon when not calling from automatic_renewals cron

Bug 19014 altered CanBookBeRenewed to return (auto_)too_soon over on_reserve

For cron purposes this is the correct behaviour.

For display purposes we wish to see on_reserve over too_soon

This patchset adds a switch to 'CanBookBeRenewed' to alter the priority of these statuses

To test:
 1 - set NoRenewalBeforePrecision to date only
 2 - set a circ rule to auto-renewal=yes, no renewal before=0, checkout period to 7 days
 3 - check item out
 4 - confirm item shows Scheduled For Automatic Renewal in issues table
 5 - place a hold on the item for another patron
 6 - reload issues table for patron 1, confirm checkout still shows "scheduled for automatic renewal" rather than "on hold"
 7 - change No Renewal Before value to 7
 8 - reload issues table for patron 1, confirm checkout now shows "on hold"
 9 - Apply patch
10 - restart_all
11 - Reload the issues table - confirm 'on_hold' still shows
12 - Change No Renewal Before to 0
13 - Refresh issues table, still shows 'On hold'
14 - perl misc/cronjobs/automatic_renewals.pl -v
15 - Result shows 'auto_too_soon'
16 - prove -v t/db_dependent/Circulation.t

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 25265: (QA follow-up) Check server type in Elasticsearch::index_records
Marcel de Rooy [Fri, 25 Sep 2020 07:42:44 +0000 (07:42 +0000)]
Bug 25265: (QA follow-up) Check server type in Elasticsearch::index_records

Doing the same change as previously (renaming biblionumber), but fixing
at the same the record fetch. If (theoretically) an authority is passed
without a record, it would have fetched a biblio record.

Test plan:
You need Elasticsearch here.
Replaced this line in AddAuthority:
    $indexer->index_records( $authid, "specialUpdate", "authorityserver", $record );
by
    $indexer->index_records( $authid, "specialUpdate", "authorityserver", undef );
And updated an authority record. Check if you can search for the change.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
JD amended patch: remove trailing whitespace

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 25265: (QA follow-up) Rename biblionumber in ModZebra, index_records
Marcel de Rooy [Fri, 25 Sep 2020 07:02:56 +0000 (07:02 +0000)]
Bug 25265: (QA follow-up) Rename biblionumber in ModZebra, index_records

ModZebra:
The name is very misleading: we can index authid's too here.
And yes, it should not be in C4/Biblio too ;) A first step..

Adding the same change here in Koha/SearchEngine/Zebra/Indexer.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 25265: (QA follow-up) Add shebang to Indexer.t
Marcel de Rooy [Fri, 25 Sep 2020 06:29:14 +0000 (06:29 +0000)]
Bug 25265: (QA follow-up) Add shebang to Indexer.t

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 25265: (follow-up) Don't index malformed records
Nick Clemens [Wed, 23 Sep 2020 18:57:26 +0000 (18:57 +0000)]
Bug 25265: (follow-up) Don't index malformed records

This is analogous to 26522, we shoudl skip record that cannot be retrieved for indexing

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 25265: Fix copy paste error for parameter
Nick Clemens [Tue, 22 Sep 2020 17:38:03 +0000 (17:38 +0000)]
Bug 25265: Fix copy paste error for parameter

Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 25265: Rename skip_modzebra_update to skip_record_index
Nick Clemens [Thu, 17 Sep 2020 12:55:53 +0000 (12:55 +0000)]
Bug 25265: Rename skip_modzebra_update to skip_record_index

Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 25265: Prevent double reindex of the same item in batchmod
Nick Clemens [Wed, 5 Aug 2020 12:20:47 +0000 (14:20 +0200)]
Bug 25265: Prevent double reindex of the same item in batchmod

When batch editing, 2 reindex calls are sent to ES/Zebra.
We can easily avoid that reusing the skip_modzebra_update (renamed skip_record_index)

Additionally we should only send one request for biblio, and we should
only do it if we succeed

As the whole batch mod is in a transaction it is possible to fail in which case
Zebra queue is reset, but ES indexes have already been set

In addition to the skip param this patchset moves Zebra and Elasticsearch calls to
Indexer modules and introduces a generic Koha::SearchEngine::Indexer so that we don't
need to check the engine when calling for index

The new index_records routine takes an array so that we can reduce the calls to
the ES server.

The index_records routine for Zebra loops over ModZebra to avoid affecting current behaviour

Test plan:

General tests, under both search engines:
  1 - Add a biblio and confirm it is searchable
  2 - Edit the biblio and confirm changes are searchable
  3 - Add an item, confirm it is searchable
  4 - Delete an item, confirm it is not searchable
  5 - Delete a biblio, confirm it is not searchable
  6 - Add an authority and confirm it is searchable
  7 - Delete an authority and confirm it is not searchable

Batch mod tests, under both search engines
  1 - Have a bib with several items, none marked 'not for loan'
  2 - Do a staff search that returns this biblio
  3 - Items show as available
  4 - Click on title to go to details page
  5 - Edit->Item in a batch
  6 - Set the not for loan status for all items
  7 - Repeat your search
  8 - Items show as not for loan
  9 - Test batch deleting items
    a - Test with a list of items, not deleting bibs
    b - Test with a list of items, deleting bibs if no items remain where all items are only item on a biblio:
     SELECT MAX(barcode) FROM items GROUP BY biblionumber HAVING COUNT(barcode) IN (1)
    c - Test with a list of items, deleting bibs if no items remain where some items are the only item on a biblio:
     SELECT MAX(barcode) FROM items GROUP BY biblionumber HAVING COUNT(barcode) IN (1,2)
 10 - Confirm records are update/deleted as appropriate

Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 25265: Unit tests
Nick Clemens [Thu, 17 Sep 2020 11:43:44 +0000 (11:43 +0000)]
Bug 25265: Unit tests

These cover Koha::SearchEngine::Indexer and ensure that all calls in the code
are routed correctly to the expected search engine

Bug 25265: (follow-up) Skip tests if elastic not configured

Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26510: Transport Cost Matrix editor doesn't show all data when HoldsQueueSkipClos...
Kyle M Hall [Tue, 22 Sep 2020 18:10:10 +0000 (14:10 -0400)]
Bug 26510: Transport Cost Matrix editor doesn't show all data when HoldsQueueSkipClosed is enabled

If HoldsQueueSkipClosed is enabled, and a library happens to be closed
on the day you edit the transport cost matrix, all the values for that
library will not show. Instead they will appear disabled, and if you
were to edit the cell and save a new value in it, it will also
'disappear' when the page is reloaded.

Test Plan:
1) Set today as a holiday for a library
2) Set HoldsQueueSkipClosed to 'open'
3) Go to the transport cost matrix editor
4) Edit a cell where the 'from' is for the closed library
5) Note the value doesn't 'save', it is still in the database though
6) Apply this patch
7) Restart all the things!
8) Reload the transport cost matrix editor
9) The value now appears correctly!

Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26434: Fix plugin dirs addition to @INC
Fridolin Somers [Fri, 11 Sep 2020 14:03:28 +0000 (16:03 +0200)]
Bug 26434: Fix plugin dirs addition to @INC

Plugin dirs defined in koha-conf.xml are added to @INC in order to compile perl code.
Looks like with plack those dirs are added several times.
This may lead to an error "INCLUDE_PATH exceeds 64 directories".

This bug was identified with Carrousel plugin : https://inlibro.com/instructions-carrousel/

Test plan :
1) Enable plack and plugins
2) Look at page about.pl : @INC contains one plugin dir 'var/lib/plugins'
3) Install plugin KitchenSink : https://github.com/bywatersolutions/koha-plugin-kitchen-sink
4) Dont apply patch
5) Use configure on KitchenSink
6) Look at page about.pl : @INC contains server plugin dir 'var/lib/plugins'
7) Apply patch and restart plack
8) Use configure on KitchenSink
9) Look at page about.pl : @INC contains one plugin dir 'var/lib/plugins'

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>
4 years agoBug 26438: Rename temporary Koha::Item variables to avoid conflict
Colin Campbell [Fri, 11 Sep 2020 17:16:28 +0000 (18:16 +0100)]
Bug 26438: Rename temporary Koha::Item variables to avoid conflict

Returns from Koha::Item calls were stored in temporary variables
called $item. Unfortunately they occur in routines already with
an $item variable holding a lineitem and hide that variable although
only required for two lines of code. An error occurs if girfield
is called on the wrong variable. Renamed all three occurences
of $item to $kitem to avoid the error

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26231: Remove incorrect use of AddAuthority() when 001 present
David Cook [Tue, 18 Aug 2020 02:20:32 +0000 (12:20 +1000)]
Bug 26231: Remove incorrect use of AddAuthority() when 001 present

This patch removes the use of AddAuthority with a non-empty
authid argument, since that triggers an update rather than an insert.

In practice, the update also fails, but the error isn't raised,
as the database connection doesn't have RaiseError set.

Test plan:
1) Do not apply patch
2) Try to bulkmarcimport an authority file with a 001
3) Observe that the script reports success but no authority is added
4) Apply the path
5) Try to bulkmarcimport an authority file with a 001
6) Observe that the script reports success and the authority is added

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26341: Database update for bug 21443 is not idempotent and will destroy settings
Kyle M Hall [Tue, 1 Sep 2020 14:42:47 +0000 (10:42 -0400)]
Bug 26341: Database update for bug 21443 is not idempotent and will destroy settings

If the database update for bug 21443 is run, and the library changes any
of the hourly or daily rental fees following the calendar, a second run
of the database update will overwrite those changes.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 26507: Elasticsearch - Index records after storing new item
Nick Clemens [Tue, 22 Sep 2020 14:14:55 +0000 (14:14 +0000)]
Bug 26507: Elasticsearch - Index records after storing new item

Currently Item->store indexes the record before the DB update - that is wrong

To test:
 1 - Find/create a bib with no items
 2 - add an item with barcode "abc123"
 3 - do a general keyword search for "abc123," see your bib is not in the results
 4 - perform a search that includes your bib in the results, confirm it shows as having no items
 5 - click through to bib details, confirm it shows your item here
 6 - edit and save your item
 7 - confirm barcode is now searchable
 8 - apply patches
 9 - Add a new item "cde456"
10 - Confirm it returns in searches
11 - Edit 'cde456' and change barcode to 'fgh789'
12 - Confirm the new abrcode is searchable

Signed-off-by: Lisette Scheer <lisettes@latahlibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 24807: (QA follow-up) Remove uneccessary tests
Nick Clemens [Fri, 18 Sep 2020 10:35:43 +0000 (10:35 +0000)]
Bug 24807: (QA follow-up) Remove uneccessary tests

These tests fail now, the code expects a real response from ES in Indexer.pm
but these tests mock 'bulk' and so don't have the necessary fields.

We are testing the same code above and can just add the _id == biblionumber test

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 19889: (follow-up 2) update DB adjustments
Jonathan Druart [Wed, 23 Sep 2020 19:59:02 +0000 (21:59 +0200)]
Bug 19889: (follow-up 2) update DB adjustments

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 19889: (follow-up) update DB adjustments
Jonathan Druart [Fri, 18 Sep 2020 09:38:57 +0000 (11:38 +0200)]
Bug 19889: (follow-up) update DB adjustments

Fix fields order

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 18958: DBRev 20.06.00.039
Jonathan Druart [Fri, 18 Sep 2020 09:46:10 +0000 (09:46 +0000)]
Bug 18958: DBRev 20.06.00.039

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 18958: (follow-up) Ensure hold fill target reserve_id is set for all hold types
Nick Clemens [Tue, 25 Aug 2020 10:35:02 +0000 (10:35 +0000)]
Bug 18958: (follow-up) Ensure hold fill target reserve_id is set for all hold types

MapItemsToHoldRequests has three sections: Local holds, item level holds, bib level holds

Only one of them was setting the reserve_id. This patch makes al three set it and adds tests

To test:
1 - Repeat test plan on bug
2 - sudo koha-mysql kohadev
    SELECT * FROM hold_fill_targets
3 - Ensure reserve_id is set at appropriate times
4 - prove -v  t/db_dependent/HoldsQueue.t

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 18958: (QA follow-up) Fix number of tests

In HoldsQueue.t

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: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
4 years agoBug 18958: DBIC schema changes
Nick Clemens [Tue, 25 Aug 2020 09:55:42 +0000 (09:55 +0000)]
Bug 18958: DBIC schema changes

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: Jonathan Druart <jonathan.druart@bugs.koha-community.org>