[Koha-bugs] [Bug 30708] Creation of a new 'Preservation' module

[bugzilla-daemon at bugs.koha-community.org]

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

--- Comment #19 from Jonathan Druart <jonathan.druart+koha at gmail.com> ---
Created attachment 152944
  -->
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=152944&action=edit
Bug 30708: Vue app

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/

-- 
You are receiving this mail because:
You are watching all bug changes.