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>
This retains the "last patron" link, but extends it to add a dropdown
containg the last 10 patrons.
A future enhancement to control how many patrons to retain would
complement this well.
1) Enable showLastPatron
2) Visit two patrons details pages
3) Note "Last patron" link displays and links to the last visited patron
4) Log out
5) Apply this patch
6) Log in
7) Visit the patron details page for a few patrons
8) Note the "Last patron" link behaves as is did previously
9) Note the split button has a pulldown with the other previous patrons
10) Verify that only the last 10 patrons are retained in the pulldown
11) Verify that if you visit a patron who is already in the list
they get moved to the top of the list
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch updates a few more pop-up window templates to standardize the
markup of footer controls. The patch also updates the way catalog.js
triggers the "Add to list" pop-up so that it uses the same
window-opening JS function that similar pages do, since the default
gives us consistent popup features.
To test, apply the patch and perform a catalog search in the staff
interface which will return multiple results.
- Check the box next to one or more results.
- Click the "Add to list" button.
- Test the various options here: Add to an existing list, a new list,
or choose "More lists."
- In each case the pop-up window which appears should have a
consistent fixed footer with "Save" and "Cancel" buttons.
- Confirm that these controls can be navigated to using the tab key.
- Confirm that each one works correctly.
- Go to Administration -> Z39.50/SRU servers -> New SRU server.
- Click the "Modify" button by the "SRU Search fields mapping" field.
- Inspect and test the resulting pop-up window.
- Switch the "Record type" dropdown to "Authority," click the
"Modify" button again, and test this version of the pop-up window
too.
Signed-off-by: Émily-Rose Francoeur <emily-rose.francoeur@inLibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch updates MARC21 cataloging plugin templates so that submit and
cancel controls are consistently displayed in a fixed footer.
To test, apply the patch and go to Cataloging.
- Create or edit a bibliographic record
- Test the cataloging plugins for these fields:
- 000 (Leader)
- 006
- 007
- 008
- In each case, confirm that the correct popup window is shown when
you click the plugin link.
- Confirm that clicking the "Cancel" button closes the window without
copying any data to the field in the MARC editor.
* Note that if the plugin is also triggered by cursor focus in the
input field, some data may be automatically filled anyway.
- Confirm that filing in data and clicking "Submit" will copy the
correct information into the field.
- Go to Authorities and create or edit an authority record.
- Test the plugin for these fields:
- 000 (Leader)
- 008
- Perform the same tests as above.
I don't think the marc21_field_008_classifications is used at all, but
the template has been updated anyway. To test, edit your authority
record to use the plugin:
- Administration -> Authority types -> Default -> MARC structure -> 008
-> Subfields -> Edit.
- Under Advanced constraints -> Plugin, select
"marc21_field_008_classifcations.pl"
- Re-test the behavior of the authority editor's tag 008 plugin to
confirm that this plugin is used and works correctly.
Signed-off-by: Émily-Rose Francoeur <emily-rose.francoeur@inLibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds the requirements that updating a system preference
requires a CSRF token. (Also, adding and deleting local system preferences.)
0. Apply patch
1. koha-plack --reload kohadev
2. Add local system preference
3. Update local system preference
4. Delete local system preference
5. Update normal system preference
6. Note no errors
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We'd missed an escape case in one of the calls to .split for the pipe
delimited split operations.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch moves the parsing of standard search_field into the buildPatronQuery subroutine
and adds a check for 'standard' field before adding attributes to the search
To test:
1 - Add a new attribute type and make it searchable
2 - Add a value to a patron
3 - Search for this value using 'Standard' fields, confirm you get the patron
4 - Search for the value using 'Cardnumber' field, confirm you get the patron - BAD!
5 - Apply patch
6 - Repeat cardnumebr search, confirm patron not found - Yay!
7 - Search standard, confirm patron is found
8 - Add a new field to 'DefaultPatronSearchFields
9 - Confirm it appears in patron search dropdown
10 - Confirm a search of this field with the attribute value does not return the patron
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Moving to modalselect also has the effect of moving from comma delimited
to pipe delimitation for the preference contents
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a replacement for jQueryUI sortable, a standalone
library called Sortable. The patch updates pages which previously used
jQueryUI for sorting.
The patch updates the style of most sortable elements to use the
"grip-vertical" Font Awesome icon.
To test, apply the patch and test the following pages, confirming that
sortable elements are sortable and that the newly sorted state is saved
correctly:
- Administration -> System prefernces -> I18N/L10N
- With multiple languages installed, test that languages listed in the
'language' and 'OPACLanguages' preferences can be sorted and that
after saving your changes the interface relfects your changes: In
the footer and header of the OPAC and in the footer of the staff
interface.
- Administration -> MARC bibliographic framework -> MARC structure ->
Edit subfields of a tag.
- Test using a tag with multiple subfields, e.g. MARC21 245.
- Test that you can click and drag to reorder the tabs in the
subfield edit view.
- Test that when you save your changes, including changes to the
"New" tab position, that fields are ordered correctly both in the
display on this page and in the basic MARC editor.
- Perform the same tests on Authorities: Administration -> Authority
types -> MARC structure -> Edit subfields of a tag.
- Authorities -> New (or edit) authority
- Multiple subfields of a tag should be sortable.
- Multiple copies of the same tag should be sortable relative to each
other.
- Confirm that your changes are saved correctly and that the detail
view of your updated authority record is correct.
- Perform the same tests on Cataloging -> New (or edit) record in the
basic MARC editor.
- Enable the StockRotation system preference if necessary.
- Go to Cataloging -> Stock rotation
- If necessary, create a new rota and add multiple stages
- In the "Manage stages" view you should be able to click and drag
to reorder stages. The new position should be saved immediately
via AJAX.
Signed-off-by: paul <paul.poulain@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If checkin or renew failed, we should not refresh the table or it will
hide the error message.
Test plan:
Apply the DO NOT PUSH patch
Do a renew
=> No error in the table
Apply this patch
Do a renew
=> You see the error
Revert the DO NOT PUSH patch
Do a renew
=> The table is refreshed
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Our toolbar component is not flexible enough, we cannot:
* have something else than a router-link
* have a link outside of the app (it needs to be a Vue route)
This patch adds a ToolbarButton component that is used for existing
button. But other buttons can be added without being a router-link.
Test plan:
No change in behaviour here! Test the buttons in the 4 existing toolbar
(in the ERM module)
Sponsored-by: BULAC - http://www.bulac.fr/
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
