Bug 7442 (follow-up) ensuring that summary is display when searching on all types of authorities
This patch corrects a small bug :
Authorities search on all types does not show summary because it is computed
with selected type (which is empty) instead of using found authority type.
Test plan :
- Go to intranet autorities search
- Perform a search on all authorities types
- Look at results
=> Without this patch, results rows do not display the autority summary, only
authorized headings
Bug 7442: fix crash when selecting an authority with 200$x or 200$y (UNIMARC)
From a biblio record, if one wants to add a 600$a information, a pop-up
appears. On this new window, on search terms typed and validated, a table
result is displayed, with a column "Get It!" allowing the selection of an
authority. From here, different cases:
1) If we have a simple authority with 200$a and 200$b subfields, a link
"choose" is displayed, working correctly.
2) If the authority has different occurences of 200$a/200$b, numeric links (1 2
and so on) are displayed, one for each occurence. In the example of my
screenshot, the line with a "Paul, Korky -- Pauline, Korkette" summary
possesses two links : "1" will add "Paul, Korky" whereas "2" will add
"Pauline, Korkette" (couldn't come up with a better name ;)).
3) If the authority has 200$x or 200$y subfields defined, several links are
also created, when it should not be the case. In our example, "Niclausse,
Paul -- Expositions" will create a link "1" for "Niclausse, Paul" and a link
"2" for "Expositions". Clicking on the 2nd link leads to the following
error: Software error: Can't call method "subfields" on an undefined value
at
/home/asaurat/workspace/versions/community/authorities/blinddetail-biblio-search.pl
line 86. Only the cases 1 and 2 should be handled. The creation of links
for subfields like 200$x or 200$y should be removed.
This problem is caused by the use of " -- " has separator of authorities with
several headings, but also in some heading between main part and subdivisions.
This patch corrects this by using an array in authorities summary so that
presentation is computed in template. I've choosen to use the pipe separator
between authorities with several headings. This may be changed to be
configurable.
Test plan :
- Edit an authority type summary : for example subject (heading on 250) :
summary "[250a][ -- 250x]"
- Create an authority A1 with one heading and a subdivision : for example a
subject : 250$a "History" 250$x "20th century"
- Create an authority A2 with several headings. for example a subject : 250$a
"History" 250$a "Legends"
- Rebuild Zebra queue
- Go to OPAC and click on "Authority search" and search on "History"
=> You will find A1 and A2 :
History -- 20th century
History | Legends
- Go to intranet autorities search and search on "History"
=> You will find A1 and A2 :
History -- 20th century
History | Legends
- Edit a record using this autorities type as thesaurus : for example on 606$a
- Click on thesaurus link and search on "History"
=> You will find A1 and A2 :
History -- 20th century ; 0 times ; choose ; Edit authority
History | Legends ; 0 times ; 1 2 ; Edit authority
- Click on link "2" to chosse "Legends"
=> You get "Legends" in heading field : for example 606$a
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
I can confirm the problem and the solution. I have tested the patch on a large
DB with authorities having multiples headings. There is no regression on bug
4838.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Without the patch I couldn't choose between multiple headings
in the authority plugin, but with the patch it works as described.
Stéphane Delaune [Mon, 12 May 2014 14:58:14 +0000 (16:58 +0200)]
Bug 12229: when exporting MARC records (as ISO2709), refuse to output records that would be longer than the MARC limit
Test:
1. Edit a bib record, add 100.000 chars text to 500a
2. Go to Tools -> Export data (or run tools/export.pl on
the command line)
3. Verify that exporting as XML includes the record
4. Verify that exporting as MARC does not include the record,
and that you get the following warning:
export.pl: record (number 2025) length 102668 is larger than the MARC spec allows (99999 bytes) at...
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described. No errors
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 1f72a1c2dd45c3a570746dd575b0fcfb38d13dc4) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Jonathan Druart [Fri, 5 Sep 2014 15:40:05 +0000 (17:40 +0200)]
Bug 12876: Improve unit tests for CanReserveBeCanceledFromOpac
This patch fix the subroutine name and add a restriction on the
arguments: both argument are mandatory!
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com> Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Conflicts:
t/db_dependent/Reserves.t
Bug 12876 - Reserve in waiting/transfer status may be cancelled by user
User may cancel his own reservation at waiting or in transit status
through calling opac-modrequest.pl. Cancel button is disabled in
interface but possibility to cancel should be checked also in
opac-moderequest.pl, before calling CancelReserve().
Similar situation is with opac-modrequest-suspend.pl
This patch provides new soubroutine to chceck if user can cancel given
reserve. It's possible only when he's owner of hold and hold isn't in
transfer or waiting status.
Additionaly there are new test for this function in Reserves.t
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests, QA script and new tests.
Works as described, tested with:
.../cgi-bin/koha/opac-modrequest.pl?reserve_id=XXX
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com> Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Conflicts:
t/db_dependent/Reserves.t
Bug 12873 - Reserve can be cancelled by any logged in user
It is possible to cancel reservations through simply running opac-modreserve.pl with existing reserve_id number. This may provide remove even all reservations from system. The only limitation is that user have to be logged in. Simplest solution is to check whether reserve belongs to user or not.
Test plan:
1. Create reserves by 2 different users, and get their ID's
2. Before patch, hold may by cancelled by anyone who run site:
http://example.com/cgi-bin/koha/opac-modrequest.pl?reserve_id=XXX
3. After patch hold may by cancelled only by user whose reserve is.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 60875757c761a9ad59734e968cf34a831c65e9a6) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch removes the ImportBreeding() routine, which lost its
last caller as of the patch for bug 10462.
To test:
[1] Verify that prove -v t/Breeding.t passes.
[2] Perform a Z39.50 search in the staff interface.
[3] Perform a cataloguing reservoir search in the staff
interface; verifying that cached records from the search
done in step 2 are retrieved.
Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 990bb17e14efb8a2c16236c89ef5869dcfc48ad4) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch removes a redundant copy of the DataTables plugin
jquery.dataTables.columnFilter.js and corrects two templates.
The path to the plugin has been modified in acqui/parcel.tt:
- Go to Acquisitions and search for a vendor.
- Open the detail page for that vendor.
- Click the "Receive shipments" button.
- Select an invoice to view.
- In the table of titles, confirm that the column header search forms
work to filter column data.
In the template for the Staged MARC management page the plugin has been
removed as it is unused. A couple of markup corrects have been made.
Confirm that table sorting is unaffected by going to Administration ->
Staged MARC management, clicking a staged MARC file, and viewing the
table of items in that batch.
There should be no more remaining instances of this path in the
templates:
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
NOTE: I believe the sort order of the Order Line column is
strange, but unrelated to this patch. The search area
functions (filtering, paging, page size, etc.) worked
fine.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 45ce7431d42cd470d7f7326d8935333014b1f62c)
Magnus Enger [Mon, 14 Oct 2013 19:10:31 +0000 (21:10 +0200)]
Bug 10782 - Add a koha-mysqlcheck script
This patch adds the koha-mysqlcheck script, as a "frontend" for
the mysqlcheck command. It can be used to check the integrity of
database tables, as well as to repair them. See "man mysqlcheck"
for more information.
The script takes a Koha instance name as its only required
parameter. Any other parameters provided before the instance
name are passed directly to mysqlcheck, which means that all
the functionality of mysqlcheck is available through this script.
To test the script:
- Apply the patch, build your own packages and install them, or
- copy koha-mysqlcheck to a server already running off packages
- Run some variations of the command, with and without arguments,
and check that the output makes sense. E.g.:
sudo koha-mysqlcheck myinstance
sudo koha-mysqlcheck -e myinstance # Extended checks
sudo koha-mysqlcheck -e -v myinstance # Extended checks and verbose
- See "man mysqlcheck" for other relevant options
To test the man page:
- Run these commands and look at the formatted man page:
$ xsltproc /usr/share/xml/docbook/stylesheet/docbook-xsl/manpages/docbook.xsl \
debian/docs/koha-mysqlcheck.xml
$ man -l koha-mysqlcheck.8
- Make sure this test passes:
$ prove -v xt/verify-debian-docbook.t
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 25c932967f9def41b689b07f4536f398b612944b)
Bug 11646: fix untranslatable confirm popup in field 006 and 008 builders
This patch MARC21 modifies value builders 006 and 008 to make
confirm popup translatable
To test:
1) Update po files for your preferred language, xx-YY
cd misc/translator; perl translate update xx-YY
2) Check that confirm string is NOT present
egrep -B3 "Show values for|material type\?" po/xx-YY*po
3) Apply the patch
4) Repeat 1)
5) Repeat 2), now the strings are present
Also check that english or translated popup is right
Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described.
Bug 11639: fix untranslatable strings in 007 builder
This patch modifies marc21_field_007.tt to make
some missing strings translatable
To test:
1) Using your preferred language, xx-YY, updatepo files
cd misc/translator
perl translate update xx-YY
2) Check that missing strings are NOT present
egrep -i "exact bit depth|pad with zero|use up to 6" po/xx-YY-i-staff-t-prog-v-3006000.po
3) Apply the patch
4) repeat 1)
5) Repeat 2), check that missing strings are present
Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Template change, works as described.
Owen Leonard [Mon, 21 Apr 2014 16:55:23 +0000 (12:55 -0400)]
Bug 12117 - Remove unused image myshadow.png from the staff client
myshadow.png was used by a jQuery plugin which has long been removed.
This patch removes it.
To test, search the Koha source for references to myshadow.png.
There should be none.
Followed test plan, patch removed file as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 5c573a7ad8d50788d3b5a78e58efb8c758a9ec0c) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Julian Maurice [Thu, 25 Jul 2013 07:38:24 +0000 (09:38 +0200)]
Bug 11864: Show parent order line in received orders table
Test plan:
1/ Go to the receipt page of a bookseller
2/ Choose an invoice for which you have already partially
received some orders (or create an order an receive it
partially)
3/ In the received orders table, under column Order line,
you should now see the parent order line number in
parenthesis
Signed-off-by: remy juliette <juliette.levast@iepg.fr> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Bug 7308: (follow-up) tweak style of child fund amounts
This patch changes the styling of the amounts of child funds
in the funds table to use a more visible indication (i.e.,
italics rather than a font color of grey) and to use a
a new CSS class, "child_fund_amount", rather than a hard-coded
style.
Julian Maurice [Thu, 11 Oct 2012 12:14:20 +0000 (14:14 +0200)]
Bug 7308: rework aqbudgets.pl table
admin/aqbudgets.pl should have the following columns:
Base-level allocated (or just Allocated)
Base-level ordered
Total sub-levels ordered
Base-level spent
Total sub-levels spent
Base-level available
Total sub-levels available
Base-level is always calculated for one level, without children.
Total sub-levels should include child funds.
Available is calculated as "allocated - (ordered + spent)".
Signed-off-by: Cedric Vita <cedric.vita@dracenie.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Seems to work alright for me.
Passes QA script and tests, after I fixed 2 tabs in admin/aqbudgets.pl.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 1e808f180540a7552a9c1467ee685ac037d8c042) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Fridolin Somers [Tue, 17 Jun 2014 14:38:54 +0000 (16:38 +0200)]
Bug 12438 - Bad encoding in acquisition basket
We noticed a bad encoding (diacritics replaced by <?>) in acquisition basket when updating a server to Debian Wheezy.
We found it comes from a query containing biblio.title twice.
Maybe the mysql newer version creates this side-effect.
Test plan :
- Create an order on a record containing a diacritic in title
- Look at the basket : cgi-bin/koha/acqui/basket.pl?basketno=x
=> Without the patch the record title is bad encoded (with <?>)
=> With this patch the record title is well encoded
- Check also basket CSV export
Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Good catch!
Works as expected, passes tests and QA script. Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Duplicated biblio.title is a (minor) bug, and should be removed.
The side-effect of it solving an encoding problem might be seen
as problematic: it hides a real problem.
The efforts on 11944 actually solve this encoding problem (11944
merged into master actually fixes this), so I'm pushing it, for
a short term solution for stable, with the hope that we will soon
have 11944 pushed.
BTW, non-diacritic but non-ASCII characters are not broken either.
At the OPAC, if the bootstrap theme is used, the modal
dialog does not allow to use the CAS authentication.
This patch proposes, in case CAS is enabled, to
redirect to the opac-user.pl page (like prog theme).
This is because the popup content should stay small
(thinking about mobile surf), and that CAS url is
actually only computed in opac-user (see C4/Auth.pm)
and it would not be performant to compute it in all
pages.
Test plan:
- set syspref opacthemes to bootstrap
- enable the casAuthentication syspref
- fill the casServerUrl syspref with something like:
https://localhost:8443/cas
- go on the opac home page
- click on "Log in to your account" link (top right)
=> You go to cgi-bin/koha/opac-user.pl page where you
see the cas link
- disable the casAuthentication syspref
- go on the opac home page
- click on "Log in to your account" link (top right)
=> You see a popup for login and password
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Normal login still works with/without CAS.
Passes all tests and QA script.
Kyle M Hall [Mon, 16 Jun 2014 11:30:03 +0000 (07:30 -0400)]
Bug 11292 [QA Followup] - Use noEnterSubmit instead of new keypress handler
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit 6f4baf2c59ff00b64a0beb891605c2dd4a7452a6) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Kyle M Hall [Thu, 22 May 2014 12:35:16 +0000 (08:35 -0400)]
Bug 11292 - barcode scanner clicking 'save'
When cataloging a bib record if you scan an ISBN barcode in the barcode
scanner clicks the 'save' button before the cataloging is done. This did
not happen in 3.10, but is happening again in 3.12.
Test Plan:
1) Open the marc editor
2) Focus on a field, hit the enter key
3) Note the record tries to save
4) Focus on an indicator, hit the enter key
5) Note the record tries to save
6) Apply this patch
7) Repeat steps 2 and 4, note the record no longer
tries to save upon carriage return
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Patch tested with a sandbox.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
(cherry picked from commit a52a0a8811f6ad03c422c62280bc184a9e16996d) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Jonathan Druart [Tue, 14 Jan 2014 12:33:58 +0000 (13:33 +0100)]
Bug 11552: allow searching on original order number after a transfer
If an order is transferred from one basket to another, it should be
possible to retrieve it with the original order number (AKA order
line). This patch makes it so.
Test plan:
- transfer an order
- note the original order number and the new one
- receive the order and, on the parcel page, try to find your order with
the original order number and the new one.
Signed-off-by: sonia bouis <sonia.bouis@univ-lyon3.fr> Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
RM note: this works only for the most recent transfer, so if an order
gets transferred multiple times, earlier order numbers won't retrieve
it.
Kyle M Hall [Fri, 14 Dec 2012 16:56:36 +0000 (11:56 -0500)]
Bug 9288 - Add a script to test SIP from the command line
This is a very basic start to a sip server testing script.
I imagine we will want to make it interactive in end,
essentially replicating what a SIP based self-checkout machine does.
Signed-off-by: Adrien Saurat <adrien.saurat@biblibre.com> Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
This patch adds :w and :p versions to the index for »Lexile number«
(it has only :n so far) and adds indexes for 653 (Index term
uncontrolled), 655 (Index term Genre/Form), 041 (language-audio) and
041 (language-subtitle). It also adds the »curriculum«-index to
Search.pm.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 84bdb555491af52331ece7420e797e838c814229) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Jonathan Druart [Thu, 14 Nov 2013 13:00:46 +0000 (14:00 +0100)]
Bug 11248: fix encoding issue on emailing a list (INTRANET)
Test plan:
- send a list via email with the english version.
- translate templates and retry with another language.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Sending an intranet list from translated templates requires
a new list template for the intranet. I have added the needed
changes in a follow-up.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 9181636874a03cf43e7c26a89364279bfe2aa2ee) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Jonathan Druart [Wed, 5 Mar 2014 14:08:13 +0000 (15:08 +0100)]
Bug 8258: Use patron's library's notice for DUEDGST and PREDUEDGST
If a notice is defined for the library of the patron, it should be
used.
Without this patch, the notice used is the one defined for all
libraries.
Test plan:
1/ Set the advanced notice for a patron using digest.
2/ Check one item out to this patron (backdate the return date according
the days in advance value).
3/ launch advance_notices.pl -c
4/ Verify the notice used is the default one.
5/ Define a notice for the library of the patron for PREDUEDGST
6/ launch advance_notices.pl -c
7/ Verify the notice used is the one previously defined.
8/ Check one item out to this patron (date due = today)
9/ launch advance_notices.pl -c
10/ Verify the notice used is the default one.
11/ Define a notice for the library of the patron for DUEDGST
12/ launch advance_notices.pl -c
13/ Verify the notice used is the one previously defined.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Test case: User from Library A, checked out books
- in library A from A and B
- in library B from B
Verified, that the 'all libraries' notice is still used,
when no specific notice is defined.
Verified, that the patron's home library noticed is used,
when defined.
Note: Before and after the patch we print the branch information
from the patron's home library, so also using the template from
this branch, seems logical. All items over all branches are
processed into one single reminder email, before and after the patch.
Jonathan Druart [Wed, 13 Nov 2013 13:57:55 +0000 (14:57 +0100)]
Bug 11243: make vendor list distinguish between active and canceled items
On the vendor result list, the "Item count" columns contain the sum of
all items ordered for a basket. But if an order is canceled, the item
count is not really meaningful.
This patch just adds, in parenthesis, the number of items canceled.
Test plan:
- create a basket and 3 orders with different number of items
- cancel 1 order
- verify on the supplier list that the number of items is correct and
the number of canceled items is correct too.
Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Note: In case the biblio was deleted when the order was cancelled,
the number of biblios will be off.
Fridolyn SOMERS [Fri, 15 Nov 2013 09:43:21 +0000 (10:43 +0100)]
Bug 11254: make reservoir search normalize ISBNs
When importing records, the ISBN is normalized and stored
into database (see C4::ImportBatch::_add_biblio_fields). But when
searching with ISBN into reservoir, it is not normalized
(see C4::Breeding::BreedingSearch). So search does not match.
This patch adds the normalisation to reservoir search. Also, it
replaces call private method _isbn_cleanup by GetNormalizedISBN,
the correct public method. Also allows the reservoir search
on ISBN with hyphens.
This is intended to fix only reservoir searches.
Revised Test plan
-----------------
1) Back up DB
2) Save copy of attached example somewhere findable
2) Home -> Tools -> Stage MARC records for import
3) Click Browse and select the example MARC file
4) Click Upload file
5) Tweak as desired then click Stage for import
6) Click Manage staged records
7) Click Import this batch into the catalog
8) Home -> Cataloging
9) In the Cataloging search text box type 978-0-691-14289-0 and
click Submit
-- ISBN13 with hypens not found in reservoir
10) In the Cataloging search text box type 9780691142890 and
click Submit
-- ISBN13 without hypens not found in reservoir
11) In the Cataloging search text box type 0-691-14289-0 and
click Submit
-- ISBN10 with hypens not found in reservoir
12) In the Cataloging search text box type 0691142890 and
click Submit
-- ISBN10 without hypens found in reservoir
13) Apply patch
14) Repeat steps 9-12, this time it is always found! :)
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit cac06afeb1f03200cfc7ab48162c184be8d1526b) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 11912: (refactoring followup) make GetMarcISBN implement its advertised API
The current implementation of GetMarcISBN contradicts the documented API.
It currently returns an array of hashes with only one key (marcisbn)
which doesn't add any value to it.
I chose to fix GetMarcISBN to honour the API instead of changing thex
docs, because it seems a really silly change.
To test:
- Run:
prove t/db_dependent/Biblio.t
=> SUCCESS
- catalogue/detail.pl should correctly show ISBNs.
- opac/opac-detail.pl should correctly show ISBNs in both prog and bootstrap.
- opac-opac-sendshelf.pl should correctly show ISBNs in the email.
Sponsored-by: Universidad Nacional de Cordoba Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 774483772b2a7ff8ebdb8a9aeac82881e7c858cf) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 11912: fix problem where GetMarcISBN wrongly prepends a space to ISBNs
This patch makes the logic inside GetMarcISBN simpler and
fixes the issue.
To test:
- Run the regression tests:
prove -v t/db_dependent/Biblio.t
=> FAIL
- Apply the patch
- Run:
prove -v t/db_dependent/Biblio.t
=> SUCCESS
- Verify that opac-detail.pl and catalogue/detail.pl look as usual regarding ISBN
- Sign off
Sponsored-by: Universidad Nacional de Cordoba Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit c4900dc448aa029749ab27f98b59d1be6eb8bb14) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Jonathan Druart [Thu, 9 Jan 2014 16:53:04 +0000 (17:53 +0100)]
Bug 11489: (OPAC prog theme) show facets only if there is a result to display
If all results are hidden, the facets are displayed.
With this patch, the facets are hidden too.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Michot <nmichot@voila.fr> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script. Tested:
- Record with 1 lost item, result list = 1
- Verified without both patches 404 error page is shown
- Verified with 1st patch, no results page is shown
- Verified with 2nd patch, the still showing facets are gone
- Record with 1 lost item, result list > 1
- Record is hidden from result list, but
- result count is wrong
- result numbering is wrong
> This is an old problem, just noting
- Record with 1 lost and 1 available item, result list = 1
- Detail page is shown, only lost item is hidden
- Record with 1 lost and 1 available item, result list > 1
- Only available item is shown in result list
Also checked that the lost item shows up with hidelostitems off.
Kyle M Hall [Tue, 7 Jan 2014 17:19:37 +0000 (10:19 -0700)]
Bug 11489: in OPAC search, display "no results" when the only search result is suppressed
If hidelostitems is enabled, and the result of an opac search is a single
lost item, then the OPAC will display a 404 error, rather than a
"no results" screen.
Test Plan:
1) Catalog a record/item such that it is the only result for some search
e.g. Give it the title 'zxcvb'
2) Enable hidelostitems
3) Mark this item as lost
4) Perform an OPAC search that should result in a redirect to this record
5) Notice you a redirected to a 404 error
6) Apply this patch
7) Repeat step 4
8) Note you new get a "No results found!" page instead
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org> Signed-off-by: Michot <nmichot@voila.fr> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 2277a42c565e18475c49fde031268b8038575e1a) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Jonathan Druart [Tue, 24 Dec 2013 08:58:38 +0000 (09:58 +0100)]
Bug 10138: (follow-up) FIX sql errors
There were 2 INSERT in error.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
I have gone ahead and fixed the typo pointed out by Mathieu:
Endommadgé-> Endommagé
Sample files install without problems, tests look good.
Bug 10138: Add some authorized values in French installer; small fixes in frameworks
This patch adds some categories of values in French installer :
- SUGGEST
- OPAC_SUG
- REPORT_GROUP
- LOST
- DAMAGED
SUGGEST and OPAC_SUG are used by Suggestions module.
REPORT_GROUP is used by Reports module.
It also adds a new status for "ETAT" (en commande)
It creates a 995$2 subfield in french frameworks when it did not exist.
It links existing 995$2 subfield with LOST category.
It cleans up the list of authorised values installed with "Lecture
publique" framework :
- some codes are moved in general 1-Obligatoire/authorised_values.sql
(SUGGEST, REPORT_GROUP)
- some are suppressed, because they are also defined in
1-Obligatoire/authorised_values.sql (langue, COUNTRY, statut)
- the code for inserting the ones left is changed (I suppress the `id`
column)
To test :
1. Take a fresh new Koha
2. Install Koha choosing French installer and UNIMARC Lecture publique
3. Check the authorised values are imported
4. Check the cataloguing frameworks are usable :
especially 995 $2 field, which must be mapped with LOST values :
Perdu, Long retard, Perdu et remboursé, Introuvable
you can also check 101$a (language codes), 102$a (country codes)
5. In OPAC, make a suggestion. See if you can select a cause for your
suggestion ("Bestseller" or "'L'exemplaire en rayon est endommagé")
6. In staff interface, manage some suggestions. See if you can select a
cause for rejection or acceptation ("Bestseller", "Budget
insuffisant" etc)
7. In reports, see if you can sort reports according to values of
REPORT_GROUP ("Circulation", "Catalogue", "Adhérents" etc)
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Comments on second patch.
Bug 12098: (follow-up) put can_show_subscription() into use
This patch puts C4::Serials::can_show_subscription() into use.
Note that there is user-visible change: if a subscription has a
blank library, all users with serials permissions will be able
to view and/or edit it. It remains to be determined whether
we *want* such subscriptions to exist, or if they should only
be tied to specific libraries.
Jonathan Druart [Wed, 16 Apr 2014 14:58:36 +0000 (16:58 +0200)]
Bug 12098: Refactor can_*_subscription in C4::Serials
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tested on top of patches for 12048 and 12080.
Subscription search
- superlibrarian, IndyBranches on/off - always sees all subscriptions
- superserials, IndyBranches on/off - always sees all subscriptions
- no superserials, IndyBranches on - only sees own subscriptions
Note: Subscriptions without branches will only show, when all subscriptions
are visible. In a future enh it might be good to enforce setting a
branch, when IndyBranches is used.
- no superserials, IndyBranches off - always sees all subscriptions
Subscription editing
- superlibrarian, IndyBranches on/off - can edit all subscriptions
- superserials, IndyBranches on/off - can edit all subscriptions
- no superserials, IndyBranches on - can only edit own subscriptons and
subscriptions without branch
NOTE: it would make sense to also allow Edit > Edit as new (duplicate)
here, so one can copy the subscription from another branch to modify
it for the own branch.
Passes tests in t, xt and QA script, also newly provided unit tests.
Bug 12080: restore effect of superserials permission
The superserials permission is meant to allow an operator
to see all subscriptions regardless of branch when IndependentBranches
is on without having to have full superlibrarian permissions. This
patch restores this behavior.
TEST PLAN
---------
1) Apply the patch for bug 12048 (as needed -- it may be pushed)
2) Ensure you have two users: superlibrarian, non-superlibrarian
with all access to the staff client except superserials.
3) Ensure you have serials belonging to a different branch than
the non-superlibrarian.
3) Log into staff client as superlibrarian
4) Click 'Serials'
5) Click the 'Submit' button in the search area.
-- note the number of results.
6) Log into staff client as non-superlibrarian
7) Click 'Serials'
8) Click the 'Submit' button in the search area.
-- note the number should be less, note the number.
9) Give the non-superlibrarian superserials access.
10) Home -> Serials
11) Click the 'Submit' button in the search area.
-- the number will still be the same at the one in step #8.
12) Apply the patch
13) Refresh the page
-- the number should now match the one in step #5.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit f0e574be4a834b28b0e19f2964f5de989f0e6665) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 12048: restore ability of superlibrarian to see other libraries' subscriptions
This patch fixes a regression in master and 3.14. When a user has
superlibrian permissions, a search on serials subscriptions should
display other libraries' subscriptions even when IndependentBranches
syspref is enabled.
To reproduce/test the bug/patch:
1. Enable IndependentBranches (i.e. 'Prevent' staff...)
2. Login as a user not having superlibrarian permission
3. Search for a serial subscription on:
/cgi-bin/koha/serials/serials-search.pl
4. Search a title which has at least 2 subscriptions: one in the user
branch, and one in another branch
5. On the result page, just 1 subscription is displayed: the one
attached to the userbranch
=> this is normal
6. Login as a user having superlibrarian permission
7. Repeat step 3-5.
8. You get the same result as 5. You should have seen all subscriptions.
That's what you get after applying this patch.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
NOTE: I tested a variation. My superlibrarian was a branch that
was not the same as the non-superlibrarian. The serial was
the same branch as the non-superlibrarian. Without the
patch, the superlibrarian saw nothing, with the patch it
saw the serial as expected.
Also, remember the superserials permission can affect the
results. I successfully changed the branch of the
subscription, and then it ceased to show up with
superserials not granted to the non-superlibrarian.
I corrected the system preference name in the text here.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Superlibrarian permission now allows to see all subscriptions
independent from the branch.
Passes all tests and QA script.
But the superserials permission appears broken to me before
and after this patch. If I have superserials - the search
doesn't show all subscriptions. If I don't have superserials
I can still edit any subscription accessing the subscription
detail page through the serial collection page or accessing
the detail page directly by manipulating the URL.
Mark Tompsett [Tue, 21 Jan 2014 05:41:00 +0000 (00:41 -0500)]
Bug 11587: get rid of warnings generated by IsSuperLibrarian with anonymous sessions
This corrects line 1250 of C4/Context.pm to be:
return ($userenv->{flags}//0) % 2;
And thus avoids an uninitialized value used in the modulus.
TEST PLAN
---------
1) Apply the first patch (to update t/Context.t)
2) prove -v t/Context.t
-- This should fail tests 7 and 8
3) Apply this patch (to fix C4/Context.pm)
4) prove -v t/Context.t
-- All tests should succeed
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit bf3b1aac7b7bc422bea26bb2c045be69d93ef0bf) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Simply viewing OPAC detail triggers a modulus warning entry.
This first patch adds two test cases to t/Context.t to test for
this situation.
TEST PLAN
---------
1) Apply this patch (to upgrade t/Context.t)
2) prove -v t/Context.t
-- Tests 7 and 8 will fail
3) Apply main patch (to amend C4/Context.pm)
4) prove -v t/Context.t
-- All tests will succeed
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 8ee0bc049a183e795fc37608a4b3790d4aef2267) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Conflicts:
t/Context.t
Galen Charlton [Mon, 30 Dec 2013 16:05:51 +0000 (16:05 +0000)]
Bug 7002: fix some invalid superlibrarian permission checks
This patch fixes a problem where if a staff user has superlibrarian
permissions, but also has module-specific permissions, they are
prevent from editing item records that they should be allowed to.
To test:
[1] Turn on IndependentBranches.
[2] Register a superlibrarian staff user at branch A.
[3] Give that new account at least one other module-level
permission. This cannot be done through the user interface,
however, but can be done via SQL:
UPDATE borrowers SET flags = 3 WHERE userid = 'XXX';
[4] Log in as that new superlibrarian.
[5] Bring up the item details (catalogue/moredetail.pl) page for
an item at branch B. Note that there is no 'Edit Item' link.
[6] Similarly, try editing that item (cataloging/additem.pl). Note
that the edit form forbids you from touching the item.
[7] Finally, try editing that item using the Tools | Batch item
modification utility. Note that it doesn't allow you to do so.
[8] Apply the patch.
[9] Repeat steps 5 through 7. This time, the item actions should
be allowed.
Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes QA script and test suite.
Galen Charlton [Mon, 30 Dec 2013 18:50:04 +0000 (18:50 +0000)]
Bug 10277: (follow-up) if no userenv is set, act like a superlibrarian
This patch fixes an error caught by t/db_dependent/Acquisition.t, and
adjusts C4::Context::IsSuperLibrarian() to return true if no
userenv is set. This is done on the basis that if no userenv is set,
calls to C4::Context routines are being made from a command-line script,
and if you have access to the command line of a running Koha instance,
you implicitly already have better than superlibrarian access.
Jonathan Druart [Wed, 18 Dec 2013 15:12:00 +0000 (16:12 +0100)]
Bug 10277: Add UT for C4::Context::IsSuperLibrarian
Note that I modify the return value. Before this patch, it returned an
empty string or 1. Now it returns 0 or 1.
Test plan:
- same as the original patch
- verify that unit tests pass:
prove t/Context.t
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script, including new tests.
Checked the code and tested superlibrarian behaviour in some places:
moremember.pl:
With IndyBranches only superlibrarian can delete borrowers from
other branches. Accessing the borrower with a direct link.
OK
C4/Members.pm
With IndyBranches only superlibrarian can search for borrowres
from other branches.
OK
tools/holidays.pl
With IndyBranches only superlibrarian can edit holidays for other
branches.
Kyle M Hall [Wed, 15 May 2013 15:04:07 +0000 (11:04 -0400)]
Bug 10277 - Add C4::Context->IsSuperLibrarian()
The method of checking the logged in user for superlibrarian privileges
is obtuse ( $userenv && $userenv->{flags} % 2 != 1 ) to say the least.
The codebase is littered with these lines, with no explanation given. It
would be much better if we had one subroutine that returned a boolean
value to tell us if the logged in user is a superlibrarian or not.
Test Plan:
1) Apply this patch
2) Verify superlibrarian behavior remains unchanged
Signed-off-by: Joel Sasse <jsasse@plumcreeklibrary.net> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Comments on second patch.
Jonathan Druart [Wed, 5 Mar 2014 12:07:53 +0000 (13:07 +0100)]
Bug 11699: fixed saving notes entered when receiving orders
Revised test plan:
1/ Create an order with 2 items
2/ Receive 1 item and enter a note for the order
3/ Verify the note is not saved
The note should be visible on the Mod Order Details screen,
but it isn't there.
4/ Apply patch
5/ Receive the second item and enter a note for the order
6/ Verify the note is correctly saved
The note is visible on the Mod Order Details screen.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Works as described. The note now saves correctly and also remains when
you undo a receipt.
Note: it would be nice to show the note on the receive page as well. Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit ab1a74897efb82b99ed3931dff719bb64b930bc4) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Conflicts:
t/db_dependent/Acquisition.t
This relevance sets title as phrase in priority and then any index.
This patch adds title as words list before search on any index, so
that records with all searched terms in title, even not well ordered,
are more relevant.
Test plan :
- Enable QueryWeightFields syspref
- Perform a search, with sort by relevance, with two words ofen
contained in title, but never one near the other.
For example: 'History France'
=> Records with both words in title are first. For example:
"Histoire de France" and "La France : 100 ans d'histoire"
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Relevance ranking and field weighting are hard to test,
as many MARC fields are indexed into the used indexes.
If we had an index that only indexed 245$a/200$a the
effect might be more visible.
I found no regressions by this patch, change reads
logical.
Bug 11508: fix untranslatable pull-down in auth_subfields_structure.pl
This patch replaces occurrences of CGI::scrolling_list with
untranslatable labels. It also fixes capitalization.
To test
1. Go to Administration > Authority types,
click 'MARC structure' of any auth type,
click 'subfields' for any Tag >= 010,
clic 'Edit subfields'
Check pulldowns 'Managed in tab' and 'Select to display or not'
2. Apply the patch
3. Reload and verify functionality of both pulldowns
4. Check that strings are not present on staff PO file
egrep "^msgid \"(Show all|Hide all|ignore)" misc/translator/po/fi-FI-i-staff-t-prog-v-3006000.po
5. Update language file
(cd misc/translator/; perl translate update fi-FI)
6. Check that strings are now present, repeat 4.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
NOTE: drop-downs work identically. Show all, Hide all, and
ignore were added to the po files too.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Works as described and improves the page to manage authority
subfields.
Jonathan Druart [Tue, 29 Oct 2013 14:03:41 +0000 (15:03 +0100)]
Bug 9216: make columns.def file translatable
The SQL column headers is stored into the columns.def file.
This file is not managed by the translation script.
This patch makes possible the headers translation.
Note: The translation xml tags were added to avoid all lines being put
on a single line.
Test plan:
1/ update your po file
cd misc/translate;
perl translate -f columns update LANG # Replace by another language here
2/ translate header columns (search "columns.def" in your po file).
3/ install the translated columns.def
perl translate -f columns install LANG # Replace by another language here
4/ go on the report module > create a new report > next > next
5/ change the language
on the 3rd step, you should see the column header translated.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described, no koha-qa errors
[on es-ES about a third of the strings translated!! :-) ]
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described and fixes a long standing translation
problem.
Passes all tests and QA script.
Fridolyn SOMERS [Fri, 22 Nov 2013 10:00:21 +0000 (11:00 +0100)]
Bug 9578: avoid a search crash when attempting to sort results of invalid query
When searching with a sort (means not by relevance) and there is an error
in Zebra connexion (server is down or query is wrong), you get the message :
Error : Can't call method "sort" on an undefined value at /home/kohaadmin/src/C4/Search.pm line 405.
This patch corrects by not performing sort if there are no no results.
Steps to reproduce the error without patch:
In OPAC go to Advanced Search
Choose "Title" in first "Search for:" end enter "ccl=( and )"
Display "More options"
Set "Sort by" to "Title (A-Z)"
Click "Search" at bootom of page
Result:
Error:
Can't call method "sort" on an undefined value at /usr/share/kohaclone/C4/Search.pm line 430.
After applying the patch, try that search again. This time,
it should report not results found with out the error message.
Alternative Test plan :
- Set OPACdefaultSortField on something else than relevance
- Perform a simple search with a wrong CCL query. For example : ccl=( and )
=> You get the messge : No results found ...
Patch behaves as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Adds another check to prevent a bad Zebra error message.
Works as described, passes all tests and QA script.
This patch adds a regression test for the condition noted
in bug 9578, where attempting a sort of a Zebra search that
fails because of an invalid query crashes.
Jacek Ablewicz [Mon, 10 Feb 2014 09:09:21 +0000 (10:09 +0100)]
Bug 11680: (follow-up) fix unexpected tax rate changes on edit
Follow-up to fix similar issue on vendor edit.
If the tax rates in Acquisitions -> gist system preference
are entered with trailing zeroes, given vendor tax rate value
may not be correctly handled on vendor edit.
Test plan for this follow-up:
1) insert some tax rates with trailing zeroes in gist
system preference (e.g: '0|0.080|0.12|0.20|0.23')
2) add some vendors, choosing 8.0% 12.0% 20.0% 23.0%
as gst rate
3) try to modify them
4) note that vendors with 12.0% and 23.0% tax rates are
preserving previously choosen rates on edit, while
the ones with 8.0% and 20.0% do not (they are defaulting
to the first defined tax rate)
5) apply the patch
6) repeat 2) and 3)
7) all tax rates configured in system prefrence shall now
behave properly while editing vendors
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit f3cb186de5d60395d5d681dc5e83971d0717592a) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Jacek Ablewicz [Wed, 5 Feb 2014 10:16:14 +0000 (11:16 +0100)]
Bug 11680: fix case where tax rate changes unexpectedly on editing an order
If the tax rates in Acquisitions -> gist system preference are entered
with trailing zeroes, given order tax rate value may not be correctly
handled on order edit.
To test:
1) insert some tax rates with trailing zeroes in gist
system preference (e.g: '0|0.080|0.12|0.20|0.23')
2) place some new orders, choosing 8.0% 12.0% 20.0% 23.0%
as gst rate
3) try to modify them
4) note that orders with 12.0% and 23.0% tax rates are
preserving previously choosen rates on edit, while
the ones with 8.0% and 20.0% do not (they are defaulting
to the first defined tax rate)
5) apply the patch
6) repeat 2) and 3)
7) all tax rates configured in system prefrence shall now
behave properly while editing orders
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
All tests pass
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Confirmed the problem and that this patch fixes it.
Problem also exists for editing the default tax rate of a vendor.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 471215dc46e5a65360a3bde53666f62f809f0861) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Jonathan Druart [Thu, 4 Apr 2013 10:09:37 +0000 (12:09 +0200)]
Bug 10090: display item type description instead of code on acq ordered and spent pages
On ordered.pl and spent.pl, the itemtype codes are displayed, instead of
descriptions.
Links for the ordernumber should be changed. In ordered.pl, we are
redirected to the receive page. In spent.pl, the links are deleted.
Signed-off-by: Broust <jean-manuel.broust@gmail.com>
Revisited patch: The link to orderreceive was broken, so I undo the
changes.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works alright, itemtype descriptions are shown.
The removed link was potentially 'dangerous' as you shouldn't
get to the receive page for an order, without providing an invoicenumber
first.
Passes all tests and QA script.
Jacek Ablewicz [Mon, 10 Mar 2014 09:53:52 +0000 (10:53 +0100)]
Bug 11914: fix two issues when creating an order from a suggestion
When order is being created from purchase suggestion:
- Budget/fund stored in suggestion record (if any) is not retained
on order page, system always defaults to 'Select a fund' even if some
fund was already chosen for a suggestion on the earlier stage.
- If there was a price given to, and stored within suggestion record,
initial prices calculations on order page are not working properly
('Replacement cost', 'Budgeted cost' and 'Total' show as 0.00 or blank).
As a workaround - to force correct price recalculation - user needs
to manually alter and then re-alter some price-related fields (e.g.,
quantity or vendor price).
This patch fixes both issues.
Test plan:
1) create a suggestion: choose some buget, enter something in 'Price'
and 'Quantity' fields,
2) try to make an order from this suggestion, to confirm/replicate
aforementioned problems,
3) apply patch,
4) make an order from previously created suggestion again, observe
that both issues are now resolved.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes all tests and QA script.
Jonathan Druart [Mon, 28 Oct 2013 14:10:26 +0000 (15:10 +0100)]
Bug 11148: remove two superflous routines from Koha::DateUtils
There are 2 useless routines in the Koha::DateUtils
module:output_pref_due and format_sqlduedatetime. We can call
output_pref and format_datetime with dateonly = 0.
format_sqlduedatetime is only used in one place: opac-reserve.pl
Test plan:
1/ Verify on the opac-reserve.pl page that the date is correctly
displayed for for onloan items (you should use the "specific copy"
feature).
2/ Launch prove t/DateUtils.t UT file and verify all UT pass.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Due date on opac-reserve shown correctly. Unit tests pass.
Did a grep on both function names.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
No references to subs found. Passes koha-qa.pl, t and xt
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit b9492e73f59439e218e7f657bdfcf67026834311) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Colin Campbell [Thu, 2 Jan 2014 14:42:16 +0000 (14:42 +0000)]
Bug 11468: Remove given/when from Koha::Dateutils
given and when give warnings due to their experimental
status as of perl 5.18. Replace the construct with
an if/elsif to avoid the keywords
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script, especially t/DateUtils.t.
Kyle M Hall [Wed, 18 Dec 2013 13:37:40 +0000 (08:37 -0500)]
Bug 11416: fix case where serials item editor was incorrectly hiding fields
In serials/serials-edit.pl, if an item field is hidden from the OPAC,
it will not display in the editor, even if the field is marked as
visible in the staff intranet and editor. However, the field is still
displayed correctly in the items editor ( additem.pl ).:
Test Plan:
1) Select an item-level field ( e.g. non-public note )
2) Create a serial using the default framework ( or one of your choice )
3) For that framework, mark the chosen field as visible from the
intranet and editor, but not the opac.
4) Receive an item for this serial, note your field does not display
5) Use the biblio item editor to add an item ( additem.pl ), not the
field displayes
6) Apply this patch
7) Repeat step 4, not the field displayes
Signed-off-by: Kim Schwant <kim.schwant@courts.in.gov> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
PrepareItemrecordDisplay is only used for editor (-4 < hidden < 4)
Blou [Wed, 12 Feb 2014 17:03:08 +0000 (12:03 -0500)]
Bug 11752: display the correct frequency for serial subscriptions in OPAC details
This fixes bootstrap and prog by modifying the description displayed
in the OPAC's detail of serials.
RM NOTE: this patch does not cover the case where custom serial
frequencies have been defined.
TESTING to reproduce
- create/find a serial with a 1/week periodicity (4 in the database)
- Find it in the opac-detail.pl, click "more details" at the bottom
- validate the string. Before the patch, it will say:
"The current subscription began on 2013-12-06 and is issued every 3
weeks for 26 issues"
The "every 3 weeks" is clearly wrong.
In fact any periodicity chosen would display a wrong description, not
matching the staff interface.
After the patch, the display is corrected.
As a bonus, the "every 2 years" now has a description, where it had
none before.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit 7f1e949ea0e8d05b641ddbcb4582a3e1bc913ecd) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Julian Maurice [Fri, 28 Mar 2014 13:38:25 +0000 (14:38 +0100)]
Bug 12003: Do not calculate next pubdate for irregular subscriptions
Show 'Unknown' when planneddate and publisheddate cannot be calculated
Also fixes SQL query in misc/cronjobs/serialsUpdate.pl that was still
using "periodicity != 32" to exclude irregular subscriptions from
results
Test plan:
1) Create a subscription in the serials module. Make sure to choose:
Frequency = Irregular
2) Test the prediction pattern, first publication date is set to
"First issue publication date" field, others will show as
'unknown'
3) Save the subscription
4) Check the created issue - it will show a published date and a
planned date (same as "First issue publication date" field)
5) Receive the issue and check the next generated issue, planned
date and published date should show as 'Unknown'
6) Generate a next issue, planned date and published date should
also show as 'Unknown'
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described following test plan.
No koha-qa errors
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Also tested:
- multi receiving generates mulitple issues without dates - 'unknown'
- staff detail page shows the dates empty, which is fine
- OPAC detail page shows the dates empty, which is fine
- serial collection page shows 'unknown' and those issues appear
on the 'manage' tab, as they did in the past
- Editing the issue from the serial collection page leaves the
date fields empty.
- Receving the issue, setting the status to 'Arrived' the Expected on
date is set to 'today' automatically. Date published has to be
entered manually (maybe something we could improve later
- subscription detail > issues tab shows Uknown.
- t/db_dependent/Serials/GetNextDate.t pass.
Jonathan Druart [Wed, 3 Jul 2013 08:52:21 +0000 (10:52 +0200)]
Bug 10533: move JavaScript functions for basket groups to a separate file
This patch moves JavaScript functions used for managing basket groups
to a file. This has the effect of putting the last (active) use of
the YUI JavaScript library by the staff interface in one file:
koha-tmpl/intranet-tmpl/prog/en/js/basketgroup.js
Test plan:
- Try all actions for basketgroup ( drag/drop, add, delete, close, print,
reopen, edit, export as csv).
- Check that there is no regression on others acquisition pages:
* acqui/neworderempty.tt
* acqui/uncertainprice.tt
* acqui/addorderiso2709.tt
* acqui/basketheader.tt
* admin/aqbudgets.tt
* admin/aqcontract.tt
* admin/aqbudgetperiods.tt
* admin/aqplan.tt
* suggestion/suggestion.tt
Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, passes all tests and QA script.
Frédérick [Tue, 18 Mar 2014 20:11:44 +0000 (16:11 -0400)]
Bug 11955: Remove spaces in empty indicators when linking an authority to a biblio record.
This patch removes spaces in indicators which are imported when we link an
authority to a biblio record. The spaces made the indicators harder to edit
after the linking, because we had to delete the superfluous space character
before a new value could be entered.
To test:
1. Open some authority on editor, save with empty indicators.
They are saved as ind1=" " ind2=" " on auth_header tables, with spaces
2. Edit some record, link some tag with previous auth,
indicators now have a space on it (or ind1 at last)
3. Apply the patch
4. repeat 2, space is gone
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described. No koha-qa errors.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
(cherry picked from commit afc9549a6f58ddf36cf6d9a5399239385c377c90) Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
projects / koha.git / log