This patch moves the RoutingListNote system preference into HTML
customizations, making it possible to have language- and
library-specific content.
To test you should have some content in the RoutingListNote
system preference before applying the patch. Apply the patch and run
the database update process.
- In the staff client, go to Tools -> HTML customizations and verify
that the content from RoutingListNote is now stored there.
- The HTML customization entry form should offer RoutingListNote
as a choice under "Display location."
- Update and reinstall active translations (for instance fr-FR):
- perl misc/translator/translate update fr-FR
- perl misc/translator/translate install fr-FR
- Enable the translation if necessary under Administration -> System
preferences -> language.
- Edit the RoutingListNote HTML customization and add unique
content to the "fr-FR" tab.
- Go to Serials and create a subscription if necessary.
- From the subscription detail page, click "Create routing list" in the
left-hand sidebar.
- Add one or more recipients to the list and click "Save".
- On the "Preview routing list" page click "Save and preview routing
slip".
- In the pop-up window with the routing list preview you should see the
content you added to the RoutingListNote HTML customization.
- Switch to your updated translation and confirm that the content you
added for your translation shows up correctly.
- Go to Administration -> System preferences and search for
"RoutingListNote." It should return no results.
NOTE: This patch does not keep the default content which was stored by
the RoutingListNote system preference. Having a default value for that
kind of preference is not standard. Instead I have updated the
description of the RoutingSerials preference to add a mention of the
RoutingListNote HTML customization option.
Sponsored-by: Athens County Public Libraries
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch moves the StaffLoginInstructions system preference into HTML
customizations, making it possible to have language-specific content.
To test you should have some content in the StaffLoginInstructions
system preference before applying the patch. Apply the patch and run
the database update process.
- In the staff client, go to Tools -> HTML customizations and verify
that the content from StaffLoginInstructions is now stored there.
- The HTML customization entry form should offer StaffLoginInstructions
as a choice under "Display location."
- Update and reinstall active translations (for instance fr-FR):
- perl misc/translator/translate update fr-FR
- perl misc/translator/translate install fr-FR
- Enable the translation if necessary under Administration -> System
preferences -> language.
- Edit the StaffLoginInstructions HTML customization and add unique
content to the "fr-FR" tab.
- View the staff interface login page. You should see the
content you added to the StaffLoginInstructions HTML customization.
- Switch to your updated translation and confirm that the content you
added for your translation shows up correctly.
- Go to Administration -> System preferences and search for
"StaffLoginInstructions." It should return no results.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
updates "Field suppresion" to "Field suppression"
to test:
- go to Administration/Authority types/Default framework/Tag 090
- verify description for subfield t is Field suppresion, FSP (RLIN)
- apply patch
- reset database or reset_all
- verify description has changed to Field suppression,FSP (RLIN)
Signed-off-by: William Lavoie <william.lavoie@inLibro.com>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This fixes some database update messages to improve their
consistency with the database update guidelines
https://wiki.koha-community.org/wiki/Database_updates
Test plan:
1. Apply the patch.
2. Review the differences to make sure the messages make
sense and are consistent with the database update
guidelines:
2.1 Review the diff attached to the bug
or
2.2 Run: git show
3. Sign off D:
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Leo Stoyanov <leo.stoyanov@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Jan Kissig <bibliothek@th-wildau.de>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Jan Kissig <bibliothek@th-wildau.de>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Attach patch first, and then start up KTD or sandbox to see the
behavior for a new installation
2. Go to Administration > System Preferences and search for
DefaultPatronSearchFields
3. Click to edit
--> Confirm preferred_name is checked in the modal that displays
4. Edit a patron to give them a preferred name that is different from
their first name
5. Search for the patron by the newly set preferred_name
--> Confirm the patron correctly autocompletes and appears in the search
results
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Apply patch, updatedatabase, restart_all
2. Search for staff patron
3. More -> Set permissions
4. Check
- Staff access, allows viewing of catalogue in staff interface
- Add, modify and view patron information
- Manage patrons fines and fee
5. Notice under Manage patrons fines and fee there is a new permission "Voiding Payments"
6. Sign into staff interface as your selected staff patron
7. Search for a non-staff patron -> Accounting
8. Click 'Create manual invoice', add an amount and click 'Save and pay' -> 'Confirm'
9. Go to transactions and notice the option to Void payment appears
10. Go back to your staff patron's permission and unselect 'Voiding Payments'
11. Go to your non-staff patron and notice the option to void payments is gone
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch makes translatable the default patron restriction
types that come installed with Koha.
To test:
1) Search for "Manual restriction" in the translation files
`git grep "Manual restriction" misc/translator/po/fr-CA-installer.po`
--> No results
2) Apply patch
3) Update translations
`gulp po:update --lang fr-CA`
4) Repeat step 1
--> Manual restrictions (as well as the other restriction types
i.e. Overdues, Suspension, Discharge, and Notice failure
suspension) is in the .po file
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
801 should not be mandatory except in data exchange context (IFLA Manual)
In UNIMARC several subfields are mandatory only if the field is used.
This possibility is not available in MAR21, and Koha is currently not
able to manage this information in a useful way : it blocks the
validation of a record if the mandatory subfield is void, regardless
of the mandatory status of the field.
In consequence those subfields must be declared non mandatory in default framework.
Test plan:
1/ Open a UNIMARC Koha without patch. Try to create a record with
minimal information : 200$a and 100$a. A lot a alerts are displayed,
preventing Koha to add the record
2/ Apply the patch
3/ Run reset_all or restart KTD (to remake a fresh koha from scratch)
4/ Try to create a record with minimal information : 200$a and a 100$a.
There should only be 2 alerts, regarding 099$t and 942$c field.
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
If one has multiple databases in use adding columns
bookings.creation_date and bookings.modification_date is added
just to first updated database and skipped in other updates.
This happens because we check if these columns already exist
in database from information_schema. We should instead make
this check with method column_exists.
To test:
1. Apply this patch.
3. Drop columns bookings.creation_date and bookings.modification_date:
ALTER TABLE bookings DROP COLUMN creation_date;
ALTER TABLE bookings DROP COLUMN modification_date;
2. Revert your database back to version 24.0600028:
UPDATE systempreferences SET value = "24.0600014" WHERE variable = "version";
3. Run updatedatabase.pl.
=> Check that columns were added.
If you happen to have two databases:
1. Check if you have columns in your bookings table:
SELECT DISTINCT TABLE_SCHEMA, TABLE_NAME FROM
INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_NAME IN
('creation_date', 'modification_date');
=> Note that columns exist only in one of the databases.
2. Make sure you're using database missing columns
from booking table.
3. Apply this patch.
4. Revert back to version 24.0600028.
5. Run updatedatabase.pl
=> Check that columns were now added to database.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch updates the sample_date, as used in koha-testing-docker, with
the new preferred_name field.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds a needed index to the column.
To test:
1. On a fresh KTD, run:
$ ktd --shell
k$ koha-mysql kohadev
> SHOW CREATE TABLE oauth_access_tokens;
=> FAIL: There's no 'KEY' entry for the `expires` column
2. Apply this patch
3. Run:
k$ updatedatabase
=> SUCCESS: A message tells the index was added
4. Repeat 1
=> SUCCESS: The index was actually added to the DB
5. Run:
k$ reset_all
6. Repeat 1
=> SUCCESS: The index is created at install time too!
7. Run:
k$ updatedatabase
=> SUCCESS: Nothing explodes, no message about index being created
8. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
to test:
1- try to save an agreement with 81+ characters in License Info
2- it does not save
3- apply patch, updatedatabase
4- repeat 1, it works!
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
There is a mismatch in KEY names.
We should use the ones auto-generated by the server, not pass specific
ones.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
- Explicitly set `NOT NULL` constraints for `creation_date` and `modification_date` in `kohastructure.sql` to clarify the implicit behavior of `DEFAULT CURRENT_TIMESTAMP`.
- Adjusted the `modification_date` column definition in the atomic update file to place `NOT NULL` before `ON UPDATE` for consistency.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
- DBIx::Class appears to determine column nullability based on database metadata.
When columns are added via `ALTER TABLE` without explicitly specifying `NOT NULL`,
the metadata may indicate `IS_NULLABLE = "YES"`, causing DBIx::Class to generate
`is_nullable => 1` in the schema files. This behavior might not account for the
implicit `NOT NULL` enforcement of `DEFAULT CURRENT_TIMESTAMP`.
- Adding `NOT NULL` explicitly in the `ALTER TABLE` statements ensures the database
metadata reflects the intended constraints, potentially resolving this issue.
- Additionally, comments in the atomic update and `kohastructure.sql` are aligned
for consistency and clarity.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds the failures in at the same level as the rest of the
revision output (i.e. indented under the specific database revision) and
uses the standard failure coloring instead of the local update_error
class.
This is a proposal and may need more work to clarify and perhaps remove
the duplicated/collected errors at the bottom of the update. Now that we
hard stop if an update fails, I'm not sure collecting errors at the
bottom makes as much sense as it once did?
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Bug 35681 added subroutines to print colored output from database
updates. Incorporate the subroutine say_failure into the error handling
in the upstream code, so that errors caught upstream can take advantage
of this new subroutine and display in red.
To test:
1. Apply patch for test dbrev
2. From the kshell, run updatedatabase
--> The messages for success, info, warning, and failure that were
explicitly printed in the dbrev are colored, but the database error
is not colored.
3. Apply other patches
4. Run updatedatabase again
--> All messages including the database error are now colored
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We add a CAST to the fetch of 0000-00-00 dates in the database. This
prevents an error in MySQL 8.0 throws htat aborts the update.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
