Commit graph

16473 commits

Author SHA1 Message Date
b1a3aeb062 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>
2020-09-29 14:28:18 +02:00
d2afd19bc3 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>
2020-09-29 14:28:18 +02:00
ee5914b9b9 Bug 25321: Remove PLACE_HOLD from results.js
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-29 14:28:18 +02:00
5fa99d7d59 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>
2020-09-29 14:28:18 +02:00
9e06e62a7f 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>
2020-09-29 14:28:18 +02:00
c2b14f6a1e 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>
2020-09-29 14:28:18 +02:00
22ff2118a7 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>
2020-09-29 14:28:18 +02:00
f04ea65fa3 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>
2020-09-29 14:28:18 +02:00
8bf7c342bf 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>
2020-09-29 14:28:18 +02:00
2c98f4849d 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>
2020-09-29 14:28:18 +02:00
38566a861a 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>
2020-09-29 14:28:18 +02:00
94f7ad3e60 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>
2020-09-29 14:28:18 +02:00
1eb0fe4e5e 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>
2020-09-29 14:28:18 +02:00
ac12b9c648 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>
2020-09-29 14:28:18 +02:00
2ac76aee66 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>
2020-09-29 14:28:18 +02:00
9d056d0364 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>
2020-09-29 14:28:18 +02:00
a0e4e3b5f8 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>
2020-09-28 16:09:11 +02:00
8dca36661d 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>
2020-09-28 16:09:11 +02:00
Katrin Fischer
80993795dd 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>
2020-09-28 16:09:11 +02:00
Katrin Fischer
ed6d0d42a7 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>
2020-09-28 16:09:11 +02:00
Caitlin Goodger
a03e4f485a 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>
2020-09-28 16:09:11 +02:00
81b14467af 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>
2020-09-28 16:09:11 +02:00
e8522d8231 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>
2020-09-28 16:09:10 +02:00
5baffbee31 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>
2020-09-28 16:09:10 +02:00
Katrin Fischer
d924e892a8 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>
2020-09-28 16:09:10 +02:00
fe84c3acba 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>
2020-09-28 16:09:10 +02:00
5d5a49a7ef 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>
2020-09-28 16:09:10 +02:00
Katrin Fischer
bd6598d018 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>
2020-09-28 16:09:10 +02:00
9bbf909693 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>
2020-09-28 16:09:10 +02:00
1e502efa0a 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>
2020-09-28 16:09:10 +02:00
5da1e809b7 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>
2020-09-28 16:09:10 +02:00
34b9c061f3 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>
2020-09-28 15:07:27 +02:00
be7c705d3b 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>
2020-09-28 15:06:49 +02:00
f8d9a7a427 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>
2020-09-28 15:06:46 +02:00
d9815855bd Bug 16314: Compiled CSS
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-28 11:09:30 +02:00
ae21c3adb1 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>
2020-09-28 11:08:03 +02:00
Katrin Fischer
4f3cb59a97 Bug 26283: Add dateexpiry and dateenrolled to new borrower fields modal
While these may not make sense for all patron field preferences, I think
it's better to have them in general than to have them missing.

To test:
- Check the modal for BorrowerMandatoryField system preference
- Verify dateenrolled and dateexpiry fields are missing
- Apply patch
- Verify the dates are listed now
- Set both to mandatory
- Verify that they are indeed mandatory when adding a new patron now

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>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-18 11:49:29 +02:00
5ece5d7c7f Bug 26421: Use Bootstrap screen reader text class for shelf browser messages
This patch udpates the markup added by Bug 26039, replacing the "hidden"
class, which is no longer functional with Bootstrap 4, with "sr-only," a
class designed specifically for screen reader text.

The patch also corrects a typo, "shelfbrowers" -> "shelf browser"

To test, apply the patch and make sure the OPACShelfBrowser system
preference is enabled.

View the detail page for a bibliographic record with items. In the
holdings table, you should see links labeled "Browse shelf."

When you open the shelf browser there should be a link at the top that
reads "Close shelf browser."

If you have access to a screen reader, test that the hidden text is
announced by the reader. "Browse shelf (Opens below)" and "Close shelf
browser (Hides shelf browser)."

Signed-off-by: Stina Hallin <stina.hallin@ub.lu.se>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-18 11:49:29 +02:00
0310e973a4 Bug 10921: Prevent an order from a closed basket to be edited
We don't allow editing of orders that are part of a closed basket, but
we don't enforce the rule in the controller file.

This patch use output_and_exit to stop the script and display an error
to the end user.

Test plan:
Create a basket, add an order
On the basket view you see the "Modify" link, open it in a separate tab
=> You can edit the basket
Keep this tab open, get back to the other one and close the basket
Reload the tab with the order edition form
=> You cannot longer edit the basket

QA: Do we need a check in addorder.pl as well?

Signed-off-by: Henry Bolshaw <bolshawh@parliament.uk>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-18 11:49:29 +02:00
f90afe5c22 Bug 15933: Add cataloguing plugin to search for existing publishers in other records
This patch adds a new cataloging plugin for MARC21 installations,
marc21_field-260b.pl. When enabled it provides autocomplete for
publisher name, pulling existing data from biblioitems.publishercode.

To test, apply the patch and enable the plugin:

- Go to Administration -> MARC bibliographic framework -> MARC structure
  -> 260 -> Edit subfields -> Subfield b -> Other options.
- Set "Plugin" to marc21_field_260b.pl.
- Go to Cataloging and edit or create a record.
- Under tab 2 click the field for 260$b. Start typing a publisher name.
  A dropdown should appear with matching publishers.
- Selecting one of the results should populate the form field with that
  information.

Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Also works with 264$b.

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-18 11:49:29 +02:00
David Gustafsson
d1c8d7ecce Bug 24807: Add "year" type to improve sorting behaviour
Add a "year" search field type. Fields with this type will only
retain values that looks like years, so invalid values such as
whitespace or word characters will not be indexed.
This for instance improves the behaviour when sorting by
"date-of-publication". If all values are indexed, records with
junk data instead of valid years will appear first among the search
results, drowning out more relevant hits. If assigning this field
the "year" type these records will instead always appear last,
regarless of sort order.

To test:

1) Have at least two biblios, one with a valid year in 008 (pos 7-10)
and another with an invalid one ("uuuu" for example)
2) Perform a wildcard search (*) and sort results by publication date.
3) The record with invalid year of pulication in 008 should appear first
4) Apply patch and run database updates
5) Reindex ElasticSearch
6) Perform the same search as in 2)
7) The record with the invalid year should now appear last

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-18 11:21:31 +02:00
3b273de577 Bug 25744: replace <b> with <strong> in the staff interface
This patch set attempts to replace all the <i> tags with <em> and all
the <b> tags with <strong> in the staff interface.
I attempted to get all the templates, includes, and xslt files.

To test:

1. Review the changes as best as possible, looking for mistakes.
2. grep for <i> and <b> in the modules, includes, and xslt folders. You should get nothing/
3. If you grep '<\/i>' you should only see instances of Font Awesome.
4. If you grep '<\/b>' you should only see instances where caret is used.

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-18 11:08:35 +02:00
a02bd4f71c Bug 25744: Replace <i> with <em> in staff interface
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-18 11:08:35 +02:00
9db369fb58 Bug 26049: Replace li with span class results_summary in UNIMARC intranet XSLT
In all XSLT for record display, fields are created with <span class="results_summary> except in UNIMARC intranet where there is just <li>.

This allows a better CSS customisation and closer code in files for OPAC and intranet.

Actually li gets diplayed with a dot at each line, we don't want this.

Test plan :
1) For each modified file run 'xsltproc file.xsl' and see there is no
   error
2) Use default XSLT in all system preferences
3) Perform a search and check display with and without patch
4) Click on a record to see details and check display with and without 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>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-18 11:08:35 +02:00
7d78cae284 Bug 26262: (follow-up) Fix course details page, default configuration
Bug 25287 changed the default DataTable configuration in the OPAC so
that tables are paginated by default. This is inconsistent with the way
we currently use DataTables in the OPAC, and the change was probably
unintentional. This patch returns the default pagination configuration
to what it was before: Off.

The patch also updates opac-course-details.tt with the same DOM
configuration as opac-course-reserves.tt.

To test, apply the patch and view the list of course reserves and the
list of titles attached to a course. In both cases there should be no
pagination controls, and the tables should show all results.

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>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-18 11:08:35 +02:00
1bc7e5a645 Bug 26262: Remove wrong dom setting in course reserves (OPAC)
The current setting required pagination to be displayed. This was hidden
probably as a side effect of styling settings. But the docs are clear on
the fact that p and l are intended for displaying pagination controls
and table rows lenght information [1]

As the course reserves datatable is not paginated, this needs to be
fixed properly by removing those controls in the configuration. This
patch does so.

To test:
1. Have some course reserves
2. See them in the OPAC
=> FAIL: Some funky, misaligned pagination artifacts are displayed
3. Apply this patch and reload
=> SUCCESS: Things are back to normal!
4. Sign off :-D

[1] https://datatables.net/examples/basic_init/dom.html

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

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>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-18 11:08:35 +02:00
24556e73d2 Bug 26301: Use CanBookBeRenewed when renewing via self-checkout
Currently, if you have OverduesBlockCirc set to "Ask for confirmation"
and OverduesBlockRenewing set to "allow renewing", you get caught
in a loop where you can never renew an overdue material.

This patch uses CanBookBeRenewed for renewals, rather than CanBookBeIssued,
which means the correct rules are applied to the correct scenario.

To test:

a. Set OverduesBlockCirc to "Ask for confirmation"
b. Ensure "OverduesBlockRenewing" set to "allow renewing"
0. Apply the patch
1. Checkin item barcode 3999900000001
2. Go to http://localhost:8081/cgi-bin/koha/circ/circulation.pl?borrowernumber=51
3. Checkout item barcode 3999900000001 to 1 year ago
4. Go to http://localhost:8080/cgi-bin/koha/sco/sco-main.pl
5. Login as the "koha" user
6. Click on "Renew item"
7. Note that the item is renewed

8. Checkin item barcode 3999900000001
9. Go to http://localhost:8081/cgi-bin/koha/circ/circulation.pl?borrowernumber=51
10. Checkout item barcode 3999900000001 to 1 year ago
11. Go to http://localhost:8080/cgi-bin/koha/sco/sco-main.pl
12. Login as the "koha" user
13. Type "3999900000001" into the box under "Scan a new item or enter its barcode"
14. Click "Submit"
15. Note the system says the item is already checked out and it prompts
you to click "Renew item" in this screen
16. Click "Renew item"
17. Note the system says "Item renewed" near the top of the screen, and the "Due"
date near the bottom of the screen is more recent than the original due date

18. Checkin item barcode 3999900000001
19. Go to http://localhost:8080/cgi-bin/koha/sco/sco-main.pl
20. Login as the "koha" user
21. Type "3999900000001" into the box under "Scan a new item or enter its barcode"
22. Click "Submit"
23. Note the system says "Item checked out" and the item appears in the checkouts
at the bottom of the screen

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-18 11:08:35 +02:00
Katrin Fischer
e5a959486f Bug 26435: (QA follow-up) Terminology: Fix some more borrowers in other preferences
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-18 11:08:35 +02:00
Katrin Fischer
2baad1a39d Bug 26435: (QA follow-up) Fix terminology: borrower to patron in new hint
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-18 11:08:35 +02:00
38be70b55d Bug 26435: Add warning to AutoSelfCheck sysprefs
To test:
1- apply patch, restart
2- look up AutoSelfCheck sysprefs
3- confirm new note in description

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>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2020-09-18 11:08:35 +02:00