Default stylesheets do not reference item fields for XSLT display, however, we
spend time translating the values in the item fields.
This patch adds a system preference, PassItemMarcToXSLT. and unless enabled we remove
item fields before processing
To test:
1 - Perform some search on the staff client and opac
2 - Use the console (F12) to view the time spent on the network tab
3 - Note performance
4 - Apply patch, updatedatabase, restart_all
5 - Repeat searches
6 - Note that display has not changed
7 - Note performance, results should display slightly faster
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Mimic current behavior.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Adding two prefs:
resultsMaxItems
resultsMaxItemsUnavailable
Test plan:
Check Preferences/OPAC/Appearance.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
% perl -wc installer/data/mysql/atomicupdate/skeleton.pl
Useless use of anonymous hash ({}) in void context at installer/data/mysql/atomicupdate/skeleton.pl
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The atomicupdate directory will contain all the atomic update files (old
and new version).
That will ease job for the RM and RMaints, no file (except skeletons)
must be in this directory before push.
This patch also fixes an inconsistency we had: the atomic update was run
before the other db revs on the UI but after when the CLI script was
used.
Now we make sure that the CLI does not deal with the atomic update files
when called from the installer (UI)
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch suggests to stop using updatedatabase.pl to add new DB revs.
Each DB rev will be in a separate pl files (installer/data/mysql/db_revs).
The switch should ideally be done from 21.06.00.000.
Each DBrev is executed in a try block and a transaction. If something
went wrong, the whole DB rev is rolled back.
Why do /var/log/koha/kohadev/updatedatabase_*.log (not -error) contain
Status: 500
Content-type: text/html
<h1>Software error:</h1>
etc.
Test plan:
- git checkout c4b4db21d2 (master on 2021-07-08)
- Set the version syspref to 21.0500000:
> update systempreferences set value="21.0500000" where variable="version";
- Apply "Bug 25078: [DO NOT PUSH] DB revs for testing" (restart_all)
- Read the different DBrevs created as examples
- Make sure the different use cases are covered
- execute the updatedatabase script (CLI)
- Set the version syspref to 21.0500000
- Update the DB from the UI
- Set the version syspref to 21.0500000
- execute the updatedatabase script with the --force parameter (for
testing purpose)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We shouldn't continue to update those files as we are going to remove
them soon.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
One big patch for one big move.
The "News" feature (opac_news) has been hijacked to handle some system
preferences (bug 26050). The goal was to take profit of the UI (editor)
and the ability to translate the value.
Disclaimer: This patch is NOT offering the best implementation but, as
we still don't have bug 24975, it cannot be done now. And no, we don't
want to wait for it to move forward here. This patch is going into the
right direction anyway.
This enhancement is going to rename the "News" with a more genertic
"Additional contents". We have two different "categories" of content:
"news" and "html customizations".
What does it bring?
- A split on the UI for disambigate the two types of content (news and
syspref/html customizations)
- A simplification of the edit form: all languages will be translatable
on the same view (like the "notice templates")
- Ground will be prepared for different types of content (if needed later)
- Staff news can be translated
How was the "News" area working before this patch?
The opac_news DB table contained a (very inconsistent) 'lang' column.
The different values were:
- '' => news to display at the OPAC and staff interfaces
- 'koha' => news for staff only
- 'slip' => news for slip notices
- $lang => news for OPAC only, translated in $lang ('en', 'es-ES', etc.)
- "$location_$lang" => A syspref moved to this "news" area. The syspref
is $location, and is translated in $lang. Eg. OpacLoginInstructions_en,
OpacLoginInstructions_fr-FR, opacheader_es-ES
This patch is improving the DB structure with the following changes:
- renaming 'opac_news' with 'additional_contents'
- new 'category' column
=> 'news' or 'html_customizations'
- new 'location' column
=> For 'news': 'staff_and_opac', 'staff_only', 'slip'
=> For 'html_customizations': the old syspref name (eg. 'OpacLoginInstructions').
- new 'code' column (see later for more info)
- the 'lang' column will only contain the language code ('en', 'es-ES',
etc.). BUT a 'default' entry will ALWAYS exist for fallback behaviour.
We are getting closer to the 'notice template' table structure because
we want to match its UI. The 'code' column will bring us the ability to
group the different 'additional_contents' rows. The code for a given
news will be the same, but the (lang, title, content) will differ.
Examples:
News 1 will have, for each of the translated versions
(category, code, location, branchcode)
('news', 'News1', $location, $branchcode||undef)
And the 3 following columns will differ:
(title, content, lang)
('title for news 1', 'content for news 1', 'default')
('titulo para 1', 'contenido para 1', 'es-ES')
Note that the "category" is not strictely necessary, but it seems better
to have the ability to split the different content by category/type
easily.
Additional changes:
- Syspref 'NewsToolEditor' is renamed 'AdditionalContentsEditor'
- Koha::NewItem => Koha::AdditionalContent
- Koha::News => Koha::AdditionalContents
- Script and template renamed from koha-news to additional-contents
- Foreign keys have been renamed
- Subpermission edit_news has been renamed edit_additional_contents
- The UI can now be accessed via a "News" or "HTML customizations" link
from the tools module. The related contents will then be displayed (both
categories are now split)
Changes not done here:
- Primary key 'idnew' could be renamed 'id'
Limitations of the upgrade:
News cannot be grouped by a unique code for existing translations.
=> A given news will be now displayed several times on the translated
interface
Any ideas to improve the upgrade behaviour?
We will have to add a warning in the release notes to tell libraries to
review their news.
Test plan:
0. Don't apply the patches
1. Translate the interfaces in some languages
. Create some news for staff and OPAC
. Create some content for different entry of HTML customizations
Note that you are forced to define a 'default'.
Also note that you are only forced to fill the title (not the content).
This is certainly problematic (see FIXME in the code) as sometime only
the content is displayed.
. Play with the interface (edit, delete, filter)
. Go to the different places the news are displayed, and confirm they
are displayed correctly (staff home, opac home, opac rss)
. Create 1+ news for 'slip', check an item out and 'print slip' (from
the circulation page). You must see the news.
. Go to the different places you are expecting the HTML customizations
to be present and confirm that you see them.
. Switch the lang of the interface and confirm that you now see the
content in the translated version
. Generate the templates in another language, don't translate the
content
. Use this language for the interface and confirm that the 'default'
version is displauyed.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is the only remaining non-XSLT only feature. We should remove the
non-XSLT views that have been deprecated for a while now, and remove
this feature.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Update the database field name from 'delivery_note' to 'failure_code' to
more accurately denote it's use.
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>
The history view of an accountline shows increases and decreases in the
amount outstanding from the perspective of the credit/debit line you are
inspecting.
Apply creates a negative offset amount which acts to 'reduce' both the
outstanding 'debt' for the debit line and the outstanding 'credit' for
the credit line. Starting with a negative offset for the credit thus
makes this nonsenical.
Void creates positive offset amounts which act to 'restore' both the
outstanding 'debt' for the debit line and the outstanding 'credit' for
the credit line.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch drops the now defunkt account_offset_types table and ensure
the type field in account_offsets is instead an enum type column.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
JD Amended DB rev: no need to display a warning, the creation of the
unique key will fail with an appropriate error.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
These tables really shoul;d have some unique keys, we need a test so we can add
those
This ended up being a bigger work than expected, RM feel free to reject or move
to another bug and let the risk of duplicated languages
This is an old one, let's get it in :-)
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Estonian, Latvian, Lithuanian, Inuktitut and Inupiaq are added with
their translations to the Advanced Search languages.
Test Plan:
1. From homepage, go to Advanced search
2. Click on More options next to the Search button
3. Scroll down to the Limits section
4. Click on Language: No limit
5. Find Estonian, Latvian, Lithuanian, Inuktitut and Inupiaq at the
bottom of the dropdown.
6. They should all be there.
7. Estonian and Latvian are repeated, this need to be fixed.
8. They need to be put in alphabetical order.
Signed-off-by: Hayley Mapley <hayleymapley@catalyst.net.nz>
The five languages are present, sorted alphabetically, and are not
repeated.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
run update database script, look for new laguages under 'Language:' in Advanced search.
Languages that should be added are:
1. Estonian
2. Latvian
3. Lithuanian
4. Inuktitut
5. Inupiaq
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There are two things here:
* Branches.pickup_location has a default = 1 in DB, we should not set to undef if 0
or it will be set to 1 when stored.
* The other fields are all text (varchar, mediumtext or longtext) and
can be NULL. They are correct set to NULL when a new library is created
but set to an empty string when the library is modified. That's not
consistent
Test plan:
0. Don't apply the patch
1. Create a new library, set pickup location to "No"
2. Save
=> Pickup location is set to YES
=> In DB notice that the different values you didn't fill in are set to
NULL
3. Edit the library
4. Save
=> In DB notice that the different values you didn't fill in are now set
to an empty string
5. Apply the patch, restart_all
6. Run the updatedatabase script
=> In DB all the empty string values are set to NULL
7. Repeat 1 to 4 and confirm that everything is now working as expected
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Originally, we had:
de-DE/mandatory/sample_notices.sql
fr-CA/obligatoire/sample_notices.sql
fr-FR/1-Obligatoire/sample_notices.sql
it-IT/necessari/notices.sql
nb-NO/1-Obligatorisk/sample_notices.sql
pl-PL/mandatory/sample_notices.sql
ru-RU/mandatory/sample_notices.sql
uk-UA/mandatory/sample_notices.sql
Obviously, the landscape changed in the meantime.
We still have: fr-CA, fr-FR, nb-NO.
Test plan:
Reinstall notices for one of the languages above.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Have run all sql files thru mysql on the command line.
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>
NOTE: We are only changing English here. A follow-up will care for
the translated languages. (English is in yml format, the remainder
not yet.)
We need to change the following notices:
AR_SLIP, AR_CANCELED, AR_PROCESSING, AR_PENDING and AR_COMPLETED.
In AR_COMPLETED the last sentence about picking up has been modified
too.
Test plan:
Reinstall Koha. Choose English. Check notice text.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
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>
This preference controls which formats are actually offered to patrons of
the library via the Article Request feature.
By default, it only contains PHOTOCOPY. This is default behavior.
The request format SCAN will be made possible by this report and can be
added by changing the preference.
Test plan:
Run the dbrev. Check the new pref on Administration.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
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>
The field 'format' will allow to make a distinction between requests for
photocopies and digital scans.
The field 'urls' will be used to save the URLs that allow the client to
download the scanned materials.
Test plan:
Run new install or upgrade existing install with atomic update.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
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>
