This patch modifies the item search results page so that user selections
are stored in local storage. This allows the user to make selections on
one page of search results, move to another, and continue to make
selections.
The patch also adds the option to send selected items to batch item
modification or batch item deletion.
Changes to the patron search results template have been made to make
some CSS classes more generic so they can be used by both pages.
To test, apply the patch and rebuild the staff interface CSS.
- Log in to the staff interface as a user with permission to perform
batch item modification and batch item deletion.
- Go to item search and perform a search which will return at
least two pages of results.
- On the search results page you should see a new search header
toolbar with some controls: "Select visible rows," "Clear
selection," "Export all results to" and "Batch operations"
(disabled).
- Without making any selections, confirm that the "Export all results
to" menu items work correctly to export all results to a CSV or a
barcode file.
- Confirm that the "Select visible rows" control works as expected,
selecting all checkboxes on the current page (and on no other pages)
- After selecting all checkboxes the search header controls should be
updated:
- The "Export all..." button should now show the number of
selections: "Export selected results (X) to..."
- The batch operations button should be enabled.
- There should be a new element labeled "Items selected: X" with a
"Clear" link.
- If you uncheck any checkboxes the controls should be updated,
showing the new count of selected records.
- Move to the next page of results and confirm that making selections
on this page works to increment all counters
- Confirm that the "Export selected.." options work and that your CSV
and barcode files now contain only the items you selected.
- Test the batch operations menu:
- Test that the controls correctly reflect the logged-in user's
permissions:
- With permission to batch modify items
- With permission to batch delete items
- With both; with neither
- Both menu options should take you to the correct page and the
list of submitted items should match your selections.
- Test that clicking the "Clear" button next to "Items selected" hides
the items selected box and reverts the "Export all" and "Batch
operations" buttons to their original state.
- Page through the search results to confirm that no checkboxes are
checked.
- Test that your search selections are really persistent:
- Navigate away from the page, return to item search, and perform
another search.
- The "Item selected" box should still show your previous
selections.
- Any items you previously selected which are also in this result
set should have a checked checkbox.
- Click the "Edit search" button from the item search results page
and new search with different parameters.
- The "Items selected" should still show your previous selections.
- Log out of Koha and back in. When you perform an item search now,
there should be no "Item selected"
- Go to Patrons and test patron searching. As you make selections the
"Patrons selected" box should be updated correctly and look correct,
matching the one on the item search page.
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This updates the information messages that are displayed in Staff, OPAC and SCO
regarding renewals and if the item is up for automatic renewal or not.
Add issues.auto_renew to svc/checkouts endpoint response
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch renames the table in the columns configuration to match the id
used in the templates
It also adds a section for the moremember table to alllow config of each page as we do for issues
Lastly we add the table controls as they exist on the issues tables
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch updates the holds table on circulation and moremembers to use
table settings and hides the note column by default to preserve existing views
To test:
1 - Apply patch
2 - Enable system preferece 'OpacHoldNotes'
3 - Place a hold on the opac and enter a note
4 - Confirm it shows on the patron's page
5 - View the patron in staff client
6 - Ensure the holds note does not display on Holds tab in Checkout or Details view
7 - Go to Admin->Table settings->Circulation
8 - Under holds_table confirm 'notes' is hidden by default
9 - Uncheck the box
10 - Refresh patron pages and confirm hold note shows
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds the reservenotes column to svc holds, and ensures they display on
circulation and memeber details
To test:
1 - Enable system preference 'OpacHoldNotes'
2 - Place a hold for a ptron via the OPAC
3 - View the patron in the staff client
4 - Click on the 'Holds' tab
5 - Ensure you can see the hold note
6 - Click on the 'Circulation' tab on the left
7 - Click the 'Holds' tab and confirm you can view the note
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan, k-t-d:
1) Install FreeForm and enable ILLmodule, run:
bash <(curl -s https://raw.githubusercontent.com/ammopt/koha-ill-dev/master/start-ill-dev.sh)
2) Install an ILL availability plugin (e.g. pubmed):
https://github.com/PTFS-Europe/koha-plugin-api-pubmed/releases/tag/1.1.1
3) restart plack:
koha-plack --restart kohadev
4) Create a new ILL batch, visit:
/cgi-bin/koha/ill/ill-requests.pl
5) Click '+New ILL requests batch'
6) Input a name, '42' on the cardnumber and pick a library. Click 'Continue'.
7) On the identifiers textarea, insert '123' and click 'Process identifiers'
8) After the metadata has been retrieved, click the bottom 'Add items to batch' button, click 'Finish and view batch'
10) Go back to ILL requests table, visit:
/cgi-bin/koha/ill/ill-requests.pl
11) On the top right of the table, click 'Columns' and enable Batch
12) Notice the batch column now shows correctly and is clickable
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The JavaScript in both OPAC and staff interface for submitting catalog
concerns contains English strings which are not properly wrapped with
the __() function to allow for translation. This patch fixes both
affected files.
The patch also modifies the dialog classes used in the staff interface
so that the messages are styled consistently.
To test, apply the patch and update a translation, e.g. fr-FR:
- perl misc/translator/translate update fr-FR
- Edit the updated po file for the language you chose, e.g.
misc/translator/po/fr-FR-messages-js.po, to fill in translated
strings for the two catalog concern entries. For example:
koha-tmpl/intranet-tmpl/prog/js/modals/add_catalog_concern.js:38
koha-tmpl/opac-tmpl/bootstrap/js/modals/catalog_concern.js:55
msgid "Your concern was sucessfully submitted."
msgstr ""
- Install the updated po file:
- perl misc/translator/translate install fr-FR
- Enable the translation if necessary under Administration -> System
preferences -> language.
- Enable the "opaclanguagesdisplay" preference if necessary.
- Enable the " CatalogConcerns" preference if necessary.
- Locate a bibliographic record in the staff interface and view the
detail page
- From the toolbar, choose New -> New catalog concern.
- Test submitting the form. When the form is submitted a message
should display on the page: "Your concern was sucessfully submitted"
- Perform the same test in the OPAC, where the "Report a concern" link
is in the right-hand sidebar menu of the bibliographic detail page.
- Perform the same tests, in both OPAC and staff interface, in your
translated language to confirm that the translations show up
correctly.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
Install FreeForm and enable ILLmodule, run:
bash <(curl -s https://raw.githubusercontent.com/ammopt/koha-ill-dev/master/start-ill-dev.sh)
Visit /cgi-bin/koha/ill/ill-requests.pl
Notice the table now renders correctly
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
In case the logged in user does not have manage_sysprefs we should no
display the form in the settings.
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To retrieve the sysprefs, instead of using the svc script. See bug
33606.
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To match what has been done on bug 33169 and bug 34418.
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Adjust code to match changes done by bug 32932.
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Bug 33417 has changed how we handle the toolbars in Vue apps, this patch
is adjusting the 'Preservation' module code on top of it, but also adds
to make it more flexible (see bug 34215).
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Do not stay on the show train view.
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If a AV category is renamed or deleted, the app will freeze with
"TypeError: av_match is undefined"
To prevent that we add an check to prevent the freeze and a warning in
the settings.
We could eventually add a FK on option_source, but the idea was to let
it flexible in case we want to add another source.
This bug can be considered a configuration error anyway.
Sponsored-by: BULAC - http://www.bulac.fr/
Signed-off-by: BULAC - http://www.bulac.fr/
Signed-off-by: Heather Hernandez <heather_hernandez@nps.gov>
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If items with different processings are in a train, there is only the "edit" action button.
It's missing "Remove" and "Copy".
Sponsored-by: BULAC - http://www.bulac.fr/
Signed-off-by: BULAC - http://www.bulac.fr/
Signed-off-by: Heather Hernandez <heather_hernandez@nps.gov>
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We want opened, closed, sent, then finally received trains.
But ordering by desc for opened, and asc for the others.
Which means the last opened will be first, but the closed, send and received will display oldest first.
Sponsored-by: BULAC - http://www.bulac.fr/
Signed-off-by: BULAC - http://www.bulac.fr/
Signed-off-by: Heather Hernandez <heather_hernandez@nps.gov>
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Technical notes: Ideally we would have split TrainsFormAddItem to make some part
reusable, but it turned out into a complicated component that would have
been hard to maintain. It seems easier to have two different components.
Ideas to improve this area are welcome!
Sponsored-by: BULAC - http://www.bulac.fr/
Signed-off-by: BULAC - http://www.bulac.fr/
Signed-off-by: Heather Hernandez <heather_hernandez@nps.gov>
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If a value is not in the AV list, or if it differs slightly, they would
like to force the modification of the value, without creating a new
authorised value.
Note that this could be a candidate for an option at the attribute
level if there are different needs (ie. for some attributes we don't
want to allow an other value).
Sponsored-by: BULAC - http://www.bulac.fr/
Signed-off-by: BULAC - http://www.bulac.fr/
Signed-off-by: Heather Hernandez <heather_hernandez@nps.gov>
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This is not working as it, but we are going to fix the problem when
working on the "Set default values for items added in batch to a train"
Sponsored-by: BULAC - http://www.bulac.fr/
Signed-off-by: BULAC - http://www.bulac.fr/
Signed-off-by: Heather Hernandez <heather_hernandez@nps.gov>
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
It does not seem useful to enforce it at lower level, it is not a
condition that will break the feature, but it does not feel correct to
allow the modification of this value
Sponsored-by: BULAC - http://www.bulac.fr/
Signed-off-by: BULAC - http://www.bulac.fr/
Signed-off-by: Heather Hernandez <heather_hernandez@nps.gov>
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This commit contains the main commit message
The description of the original need is described in documents attached by the sponsor on the bug report specifically "[En] Preservation module - Main principles".
The idea is to develop a whole new module to track the status of the documents that are sent for processings/treatments in order to preserve them (eg. covering).
This is a first step, more are certainly coming later.
The author and sponsors have worked for several months before providing this MVP version. The different discussion and needs can be found at https://tree.taiga.io/project/joubu-koha-preservation-module/kanban
Some ideas of the next steps are also listed.
The first iterations have been done using the classic .pl/.tt Koha style but we finally switched to a new Vue module, for more fun.
These patches made the following main changes:
New files
* Koha objects under Koha/Preservation
* REST API controllers under Koha/REST/V1/Preservation
* preservation/home.pl and preservation/home.tt
* Vue components under js/vue/components/Preservation
* tests under t/db_dependent/Koha/Preservation and t/db_dependent/api/v1/preservation_*
* Cypress tests under t/cypress/integration/Preservation
DB:
* 3 new sysprefs PreservationModule, PreservationNotForLoanWaitingListIn, PreservationNotForLoanDefaultTrainIn
* 1 new permission "preservation" (will be split into subpermissions later)
* 5 new tables:
- preservation_processings
- preservation_trains
- preservation_processing_attributes
- preservation_trains_items
- preservation_processing_attributes_items
Terminology and workflow:
*Processings* are the different treatments an item can receive during its stay in the preservation module
A *processing* is defined by a list of *attributes*. To make the module as easy to use for the librarians in charge of the preservation area a list of processings will be defined when the module will be set up. An *attribute* is a name and a value. That's it. However it also has a type, to define what the value is coming from: *free text*, *authorised value* or *database column*.
For instance if you are defining a processing that will handling the book cover you could have 3 *attributes*:
- first named "Barcode" that will be automatically filled with "items.barcode" (type *database column*"
- second attribute named "color" linked with a new PRES_COLOR authorised value category you would have previously defined with "red", "blue", "green", etc. (type *authorised value*)
- third attribute named "notes", because librarians like notes (type *free text*)
Important: Even if the attribute is linked with a DB column or AV category, the value will be automatically pre filled but will stay editable (could be a config option to restrict the edition, later, if needed).
The *status* of an item will change during the preservation process. First it will arrive in the preservation area and be on a *waiting list*. It is not processed already but is not available anymore for the patrons of the library. That's why we are going to use the "not for loan" (items.notforloan) value for this. This *waiting list* is a fictional concept, it simply lists all the items in the library with a specific *status*.
A *train* is... how they call that at the BULAC, a train (same in French!). And we quite like the word so we kept it. It is what it is: a list of items/waggons, one after each other. We could have picked "cart", "list", but the concepts were already used in different places. We are not strongly attached to the term and it can be modified (but it's spread all over the code already and will be tedious to modify!) if you have a very good suggestion :)
So, a *train* is where items are going after they have been sent to the waiting list. It's a stack of items that will be sent to a provider. When you create a new train you will be asked for the "Status for item added to this train", that will be the "not for loan" value to set to the items added to this train, and a "Default processing" that will be the processing used. But keep in mind that a train can have items that have different processings (specific case, will see later).
When all items have been added to a *train*, you can *close* it. You cannot add items anymore to it! Then you can *send* it, and finally *receive* it. They are just statuses to keep track of the dates, and filter trains by status.
However when a train is received you can *copy* an item to another (opened) train. It means that you have the item on hand but something went wrong, you are not happy with the work done by the supplier and want to send it back, so you create a new train (that can have different items, and it is the case where you will have items in a train that don't all have the same processing!).
Test plan:
A. Prerequisites
0. Just `reset_all` and jump to B, or:
1. Apache configuration
You will need to edit /etc/koha/apache-shared-intranet-git.conf and add the following lines after the RewriteRule for erm (line.24?)
RewriteCond %{REQUEST_URI} !^/cgi-bin/koha/preservation/.*.pl$
RewriteRule ^/cgi-bin/koha/preservation/.*$ /cgi-bin/koha/preservation/home.pl [PT]
The RewriteCond is only useful if you are testing the "print slips" bugs as well, but it cannot hurt to have it!
2. `yarn js:build` to regenerate the Vue app for the preservation module
3. `updatedatabase`
4. `restart_all`
B. Settings
0.
Create 2 different values for NOTLOAN, eg. 'In preservation' and 'In preservation external'
Create different authorised values for a new category, eg. PRES_COLORS: RED, BLUE, GREEN. Feel free to create more categories.
1. You can turn on the "PreservationModule" syspref and go to the Koha homepage to see a new "Preservation" link
2. You landed on the empty home page of the preservation, no worry! We need to fill this page with useful information! (see #2 on the kanban)
3. Go to settings
4. Set "Status for item added to waiting list" to "In preservation"
and "Default status for item added to train": "In preservation external"
Create a new processing and define some attributes. Ideally at least one of each type.
5. Go to "Waiting list" and add some items
6. Go to "Trains" and create several trains (at least 2). Notice that the "Status for item added to this train" value is set to the value defined in the settings, but can be modified. Notice that this status can be set when a train is created but it won't be possible to edit later.
7. Add items to a train. You can only add items that are already in the waiting list. Add values for the attributes. Notice that the attributes linked with a database column are automatically pre filled. Notice that attributes linked with an authorised value are displayed with a dropdown list but that a different value can be set (remember, this is a feature!). Notice that attributes can be multivalued.
8. Add other items to the waiting list, notice the "Add last X items to a train" link at the top of the waiting list table, click it
9. You can now add several items to a train, directly (for instance if you don't really need to pass through the waiting list). Values can be set for the batch, but attributes linked with a database column are not editable (they will be prefilled automatically)
10. Once you have a train with several items, look at the "show train" view and notice the item list. If all of them are using the same processing then a table is displayed, one column per attribute. However if at least one item of the train has a different processing then the items are not listed in a table.
11. Edit items and confirm that the values are correctly saved.
12. Close, send and receive a train
13. Once a train is closed you can no longer add items to it
14. Once a train is received notice that you can "copy" an item to another (opened) train
QA notes:
The patch is huge! New enhancements and improvements have been moved to separate bug reports but this cannot be split. We need a ground base to build on top.
The size is mainly coming from Vue components, Koha::Objects, REST API controllers and specs, and tests. Nothing hard ;)
More to come:
- See the kanban!
- Print slips (bug 33547 and bug 34030)
- Put something on the landing page!
- Link with the acquisition module (suppliers, funds, etc.)
Sponsored-by: BULAC - http://www.bulac.fr/
Signed-off-by: BULAC - http://www.bulac.fr/
Signed-off-by: Heather Hernandez <heather_hernandez@nps.gov>
Signed-off-by: Laurence Rault <laurence.rault@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Check the transit status of the *hold* in addition to the transit status
of the *item*, to avoid displaying a misleading transit status on
item-level holds when the item is actually in transit for a different
hold
To test:
1. Create a record-level hold for Patron A for pickup at a library other
than the logged-in library
2. Check in an item to fill that hold
3. Put an item-level hold on that same item for Patron B at a different
library other than the logged-in library
4. Open Patron A's and Patron B's account details pages in separate tabs
--> Note that the Holds tab on Patron A's account detail page correctly
shows that their hold is in-transit
--> Note that the Holds tab on Patron B's account detail page incorrectly
shows that their hold on the same item is also in-transit
4. Apply patch
5. Clear browser cache
6. Refresh both patrons' account details pages
--> Confirm that the holds tab on Patron A's account still correctly
says their hold is in-transit
--> Confirm that the holds tab on Patron B's account now correctly shows
a blank status for their hold
7. Cancel Patron A's hold
8. Check in the item again to put it in transit for Patron B's hold
9. Reload Patron B's account page
--> Confirm that the holds tab on Patron B's account now correctly says
their hold is in-transit
Signed-off-by: Katariina Hanhisalo <katariina.hanhisalo@xamk.fi>
Signed-off-by: Tuomas Kunttu <tuomas.kunttu@kouvola.fi>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Calendars can be configured in a way that all days are closed.
The simplest way to do that is to configure a repeatable holiday for
every day of the week.
With such calendars, searching for an open day will literally take
forever.
This patch sets a hard limit on how many iterations are allowed before
giving up. This limit is set to the arbitrary value of 5000, which
should be large enough to be able to consider there is no open days if
we haven't found any with that many iterations, and small enough to
allow the loop to end quickly
Test plan:
1. Set system preference 'useDaysMode' to 'Use the calendar to push the
due date to the next open day' ('Datedue'). Make sure the existing
circulation rules do not conflict with that setting.
2. Browse to Tools » Calendar
3. Set every day of the week to "Holiday repeated every same day of the
week"
4. Issue an item to a patron
5. Check the box and select 'Renew selected items'
6. The renewal should fail pretty quickly
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch fixes some inconsistencies in the item search fields
administration page, making sure the page title, breadcrumb navigation,
and page headers are consistent with each other.
The patch makes some changes to the way new item search fields are added
in order to keep the display consistent with other similar interfaces:
The "add" form is no longer shown dynamically from the page listing item
search fields. Clicking the "New search field" toolbar button will now
take you to the same template used for editing existing search fields.
This allows us to put the correct context into page title, breadcrumbs,
and headings.
To test, apply the patch and go to Administration -> Item search fields.
Test the process of adding a new search field and editing an existing
search field.
Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Update statuscode -> status_code on the js files
Update remaining batch_id -> ill_batch_id
Update batch object in Illrequest.pm strings_map
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Update accessors
Add +strings embed
Add x-koha-embed to batches list andpoint
Add embed to API call from the front-end
Update table to get data from _strings
Add x-koha-embed to tests
Add strings_map to Illbatch
Add to_api_mapping to Illbatch
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
- Add batch column to requests table
- Establish if there are any availability or metadata enrichment plugins and pass that to the template
- Verify if we have any backend that can support batches, if not, don't show the option
- Updates to the ILL toolbar
- New ILL batch modal
- New Koha classes
- API specs
Co-authored-by: Andrew Isherwood <andrew.isherwood@ptfs-europe.com>
Signed-off-by: Edith Speller <Edith.Speller@ukhsa.gov.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Some libraries debar Patrons at the end of the year for having unpaid fines,
like in Bug 15157. Currently librarians have to manually remove this type of
debarments after Patron has paid his/her fines.
This patch adds ability to create restrictions which are lifted after
patron pays ceratain amount of fines.
To test:
1. Apply this patch.
2. Restart your services if needed.
3. Navigate to page restrictions.pl.
=> Note that table has two new colums in it, "Lift after payment?" and "Fee limit".
4. Add new restriction which has "Lift after payment?" set
as Yes and fee limit as 5.
5. Create fees for a patron so they exceed fee limit e.g. 10
6. Add restriction made in step 2. for the patron
7. Pay patrons fees partially so that they go under fee limit
=> Note that patrons restriction should now be lifted.
Also prove t/db_dependent/Patron/Borrower_Debarments.t.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Anneli Österman <anneli.osterman@koha-suomi.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Tidied the atomicupdate file.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
