* when a file was uploaded and the comparison with catalogue range
requested, the comparison was wrong: the logic was wrong
* items that were not supposed to be scanned (ie: supposed to be on another shelf)
didn't had the author and title, it was hard to retrieve them on the shelved
* some useful fields were missing, like homebranch, location, status
* the CSV export contained all the item information. It should contain the same
informations as the screen
Behaviour now:
* scan a list of barcode & select a range of location
* if a barcode has been scanned and should not be (misplaced item),
the information is displayed
* if you choose "compare barcodes list to result option", the
resulting list contains all items that have been scanned and those
that were supposed to be. Any item not in both list appears with a
specific message on the last column
Signed-off-by: Leila <koha.aixmarseille@gmail.com>
Signed-off-by: Koha Team Amu <koha.aixmarseille@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Passing language=<valid_language_code> as a parameter in any Koha's URL
can be used to set the desired language.
This patch touches
- C4::Templates
- C4::Auth
Adds a new method getlanguagecookie that does exactly that, for use in
get_template_and_user.
Also modifies getlanguage so it checks (a) if there's a 'language'
parameter in the CGI object and (b) checks if its valid and enabled for
the desired interface.
To test:
* Without the patch
- access any koha page
- add ?language=code to the end of the URL (change code for a valid language code
it needs to be installed using perl translate install code, and enabled either for
the staff or opac interface, depending where are you testing)
- Nothing happens with the language parameter
* With the patch
- access any koha page
- add ?language=code (the same as before) and hit enter
- the language should be changed to the one you chose
- if you browse through some links, you will see
koha 'remembers' the language you passed as a parameter
(i.e. the language cookie has been updated).
Sponsored-by: Universidad Nacional de Córdoba
Signed-off-by: Brendan <brendan@bywatersolutions.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Works very well. No errors.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
More comments on last patch.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
If you enable another translation, and disable English, then if you dont
have a cookie set, or your browser is not set to that language, you will
get English. So you can not disable English in either the staff client
or the OPAC.
This patch fixes the language selection to do the right thing.
To test you must have at least one other language installed besides
English. Apply the patch and disable the en translation. Koha should
fall back to one of the enabled translations.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I added a patch description and test plan, missing from the
original patch.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
I have tested with various combinations of activated languages
and have found no regression. If the cookie is set, the right
language is shown accordingly. Else the first language in the
list seems to be picked. It did never fall back to English
in my tests, when English was explicitly deactivated.
Passes all tests and QA script.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
In current implementation (mostly commented out in this patch)
uses heuristic to guess which strings need decoding from utf-8
to binary representation and doesn't support utf-8 characters
in templates and has problems with utf-8 data from database.
With this changes, Koha perl code always uses utf-8 encoding
correctly. All incomming data from database is allready
correctly marked as utf-8, and decoding of utf8 is required
only from Zebra and XSLT transfers which don't set utf-8 flag
correctly.
For output, standard perl :encoding(utf8) handler is used
so it also removes various "wide character" warnings as side-effect.
Test scenario:
1. make sure that you have utf-8 characters in your biblio
records, patrons, categories etc.
2. try to search records on intranet and opac which contain
utf-8 characters
3. install language which has utf-8 characters, e.g. uk-UA
dpavlin@koha-dev:/srv/koha/misc/translator(bug_6554) $
PERL5LIB=/srv/koha/ perl translate install uk-UA
4. switch language to uk-UA and verify that templates
display correctly
5. test search and Z39.50 search and verify that caracters
are correct
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I followed the test plan, adding utf-8 characters to library names,
patron categories, titles, and authorized values. I tried the uk-UA
translation and everything looked good.
When performing Z39.50 searches for titles containing utf-8 characters I
got results which were still occasionally contaminated with dummy
characters [?] but I assume this is Z39.50's fault not the patch's.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Already signed, add mine.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Adds support for custom plugins. At the moment the Plugins
feature supports two types of plugins, reports and tools.
Plugins are installed by uploading KPZ ( Koha Plugin Zip )
packages. A KPZ file is just a zip file containing the
perl files, template files, and any other files neccessary
to make the plugin work.
Test plan:
1) Apply patch
2) Run updatedatabase.pl
3) Create the directory /var/lib/koha/plugins
4) Add the lines
<pluginsdir>/var/lib/koha/plugins</pluginsdir>
<enable_plugins>1</enable_plugins>"
to your koha-conf.xml file
5) Add the line
Alias /plugin/ "/var/lib/koha/plugins/"
to your koha-httpd.conf file
6) Restart your webserver
7) Access the plugins system from the "More" pulldown
8) Upload the example plugin file provided here
9) Try it out!
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This patch moves the YUI assets from koha-tmpl/opac-tmpl/prog/en/lib/yui
to koha-tmpl/opac-tmpl/lib/yui.
NOTE: This was tested on Chrome, FF, and Safari on a Mac, and IE and FF
on Windows.
To test:
1) View a smattering of pages on the OPAC and intranet. If the move
did not work flawlessly, layout will be way off.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
This patch does the following:
1) Enables fallback for includes between different themes and different
languages (with the exact same precedence as for .tt files)
2) Enable fallback for XSLT files between different themes and different
languages (again, same precedence)
3) Change the semantics of the TT [% themelang %] variable so that it always
refers to the preferred theme and language, rather than the fallback
theme/language. As a result, all themes must include all javascript,
css and image resources they use.
Note that these changes actually have no impact whatsoever on an
installation where the default (prog) themes are in use.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
This patch makes the use of opaccolorstylesheet and opaclayoutstylesheet more consistent. They may be: 1) just a file name, 2) a complete local path or 3) a full URL starting with http: for a remote css file.
This makes the syspref opacstylesheet that was only used for a remote css file obsolete.
June 20, 2012 Rebased.
July 18, 2012: Regex allows https too (thanks to Owen Leonard).
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Language choice in Opac an Staff client was not preserved between Browser sessions.
Changed expiry date of cookie 'KohaOpacLanguage' from '' (= expire after session) to '+3y' (3 years from now)
To test:
- In a multilingual Koha istallation, choose a language.
- Log out, close all Browser instances. Go to login screen. Login should show up in same language as before.
- Repeat with other languages.
modified: C4/Templates.pm
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Refactor code to be more idiomatic and clarify its intention was testing
undef against languages causing log warn was creating and assigning to
unnecessary variables calling accept_language with an undef is an
expensive way to get undef returned to the caller test we are asking it
a meabingful question use any rather than first ( we dont care about
firstness it should be unique anyway but it obscures the meaning of the
test ) split takes a pattern not a string
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Having put my hands recently in this part of Koha code, I can confirm
that this patch fix log warnings, and add clarity and conciseness.
http://bugs.koha-community.org/show_bug.cgi?id=7874
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Just add to your Koha configuration file
<template_cache_dir>/path/writable/by/apache/user</template_cache_dir>
in the <config> block, and Koha will use template caching, for about
10% CPU time saving.
on linux servers, /tmp is usually OK
(also fixes an indenting with a TAB)
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
The results of using this are very striking. Based on an insufficient
sample size, it would seem that the time spent in T::T is reduced by a
factor of at least 5.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
This patch introduces a Filter (KohaDates) for use in templates
[% USE KohaDates %]
[% somevariable | $KohaDates %]
This will format the date in the format specified by the systempreference
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
- ensure that without cookie, language selection is based on browser
preferences
- refactor function to obtain langugage for stem in search (opac + intranet)
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
To reproduce the bug:
- Activate en and fr-FR for OPAC
- Clear your browser cookies
- Select your language preference in your browser: fr, fr-fr, en
- Load OPAC main page
- OPAC is displayed in English, rather than French as asked by browser
preferences
Apply the patch and test:
- Clear your browser cookies
- Load OPAC main page
- Pages are displayed in French
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
I dont think we can use only 2 digits, some languages is much longer
zh-hans-TW for example
But the regex should stop it bening able handle nasty chars,
whitelisting safe ones instead
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
I checked the patch doesn't break language switching and language selection.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
I confirm the bug security issue was not here for master, but this fix improve the behaviour, so pushing it
In staff interface, in search (catalogue/search.pl), there is a warning saying:
[Fri Sep 2 18:20:24 2011] search.pl: Use of uninitialized value $key in hash
element at /home/paul/koha.dev/koha-community/C4/Templates.pm line 227.
The problem happens when searching from the quick search toolbar, not when you
search from advanced search.
Investigating, it seems it's because the sort_by is not defined in this case.
This patch
* fixes the problem in Search.pl by setting the parameter only if there is a sort_by field
* modify te Template->param sub to get a better error message. Instead of having just "use of uninitia..." get the value you try to set to an empty key. Much easier to understand which line causes the problem
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Ian Walls <ian.walls@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
When Web browser default selected language doesn't belong to selected
languages list defined by syspref (language / opaclanguages), web pages
are returned in this language, which is wrong...
This patch get this behavior:
- If selected by user language is available (cookie), it is used.
- Otherwise, language is set to default web browser language.
- If this language doesn't belong to languages list (syspref),
English is selected
Some code cleanup.
To test properly: don't forget to delete your cookies, and to test what
happens without and with cookie.
If a language that doesn't exist gets accessed, then it will fall back
to en for the templates, but not for the includes, so everything still
dies. This allows the process to work in this case too.
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
I confirm the bug and the solution. This issue occurs when templates are
partially translated. The main template (.tt) is found for a specific
language, so this language is returned by themetemplate. But in the main
template, some include files (subtemplates) are referenced that can very
well not exist if the translation process had failed to generate them.
This kind of failure is reported by 'translate' script. It's very easy
to miss it, but it's the translator responsability to check it.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
This patch solves the situation that news is in another language than
the Koha interface AND makes that themelanguage routine is always called
the same way in order to prevent mixed display.
It fixes also a bug related to language preselection based on web
browser prefered language.
September 9: Adjusted with input of Frederic Demians.
Septembre 10: Avoid circular dependency, as pointed by Chris Cormack.
Templates related functions are moved from C4::Output to C4::Templates
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Ian Walls <ian.walls@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
As far as I can tell, $dbh is never used again in the scope in which it is
created. This patch simply removes the line.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
I am not very happy with this fix, but it does mean the template are
translatable and we don't get double encoding issues with them anymore
Please test
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
There were a few errors about unitialized variables in C4::Templates.
Signed-off-by: Jared Camins-Esakov <jcamins@bywatersolutions.com>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
