To reproduce:
- Stop your MySQL server:
$ sudo service mysql stop
- Run
$ prove t/XSLT.t
=> FAIL: some tests fail because of mysql stopped
To test (MySQL still stopped)
- Apply the patch
- Run
$ prove t/XSLT.t
=> SUCCESS: tests pass because the ycan be loaded regardless of
the absence of the DB server
- Sign off :-D
Regards
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tests pass without db connection for me now.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To reproduce:
- Stop your MySQL server:
$ sudo service mysql stop
- Run
$ prove t/00-load.t
=> FAIL: some tests fail because of mysql stopped
To test (MySQL still stopped)
- Apply the patch
- Run
$ prove t/00-load.t
=> SUCCESS: tests pass because the ycan be loaded regardless of
the absence of the DB server
- Sign off :-D
NOTE: Even seems to grab more than expected, which is good.
349 tests in master vs 364 in this branch = 16,
but removed block is only 13 (lines 20-32).
Also ran koha-qa test tool. :)
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Works as described, tests passing now without database available.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Kyle M Hall [Tue, 18 Nov 2014 12:40:24 +0000 (07:40 -0500)]
Bug 12971: [QA Followup]
* Makes the status column display "Overdue!" if overdue
* Fixes the due date formatting
* Sorts the checkouts by date due ( oldest to newest )
Note: I found no evidence that this data was previously sorted,
so I kept it simple. Sorting based on system preferences could
be a future enhancement.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
This fixes the issues described for patrons with existing checkouts.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Kyle M Hall [Mon, 17 Nov 2014 17:31:05 +0000 (12:31 -0500)]
Bug 12971 - Regression: Patron print summary doesn't show checkouts
A patron's print summary should contain a list of checked out items
as it did in 3.16.2 and earlier.
Please note, as of 3.16.2 reserves were no longer part of the print
summary and thus are not part of this bug fixing patch.
Test Plan:
1) Find a patron with checked out items
2) Choose Print -> Print summary
3) Note the lack of a list of checkouts
4) Apply this patch
5) Reload the page
5) Print the summary again
6) Note the list of checkouts
Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Works as described, apart from the missing status information
that Owen already noted on the bug.
Passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Mon, 17 Nov 2014 15:55:26 +0000 (16:55 +0100)]
Bug 9043: The comma (,) should be kept to separate multi-valuated prefs
The prefs language and opaclanguages used the comma to separate the
different values.
The new prefs OpacAdvSearchMoreOptions and OpacAdvSearchOptions should
do the same.
To reproduce the issue: update the language pref (or opaclanguages) and
refresh the page.
=> The pref values are not checked anymore and the language selection
(bottom of the page) does not appear.
Test plan:
1/ Verify that the behavior described above is fixed.
2/ Verify that the original test plan of bug 9043 still passes.
Note: The 2 OpacAdvSearchMoreOptions and OpacAdvSearchOptions pref
values are overwritten but the feature have just been pushed recently.
It should not affect a production environment.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I was able to reproduce the issue and verify that this patch corrected
the problem. Langage selection and OpacAdvSearchOptions worked
correctly.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Thu, 25 Sep 2014 07:38:25 +0000 (09:38 +0200)]
Bug 12992: Fund planning should display actual values
The 'show_actual' variable is not correctly manage in the template.
This has certainly been introduced by the migration to TT.
Test plan:
1/ Go on a bugdet planning view (admin/aqplan.pl)
2/ Check the "Show actual/estimated values" checkbox on the left
(Filters box)
3/ Go
4/ Verify the actual values are now displayed (i.e. the columns contain
2 values).
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Kyle M Hall [Thu, 13 Nov 2014 16:04:17 +0000 (11:04 -0500)]
Bug 13195 - Regression: Circulation checkouts table no longer shows item type description
Another regression caused by Bug 11703: The list of checkouts on the
circulation and patron detail page shows item type codes instead of the
full description.
Test Plan:
1) View a patron's checkouts, note the Item type column displays the
code rather than the description.
2) Apply this patch
3) Refresh the page, note the description is now displayed
Signed-off-by: Frederic Demians <f.demians@tamil.fr>
Works as described.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, no problems found.
Passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Owen Leonard [Wed, 12 Nov 2014 01:01:59 +0000 (20:01 -0500)]
Bug 13236 - Regression: Table of checkouts no longer preselects overdue items for rewewal
Before Bug 11703, overdue items in the list of a patrons checkouts had
the renewal checkbox preselected so that librarians could quickly renew
only those items which required it. This is not longer the case.
This patch corrects it. To test, apply the patch and clear your browser
cache. Check out to a patron who has overdues and confirm that the
overdue items have the "renew" checkbox preselected. Check that items
which are not overdue are not preselected.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, no problems found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Owen Leonard [Tue, 4 Nov 2014 17:03:13 +0000 (12:03 -0500)]
Bug 13196 - "Always show checkouts immediately" cookie should persist across sessions
This patch modifies the way the checkouts script sets the "Always show
checkouts" cookie so that it is set with an explicit expiration date
(+365 days). This will allow the cookie to persist across browser
sesssions.
To test, apply the patch and clear your browser cookies to start with a
clean slate.
- Check out to a patron who has existing checkouts. Their checkouts
should not load by default.
- Check the "Always show checkouts immediately" checkbox.
- Close your browser.
- Reopen your browser and check out to that patron again. Checkouts
should now be displayed by default.
Signed-off-by: Frederic Demians <f.demians@tamil.fr>
Works as described. I confirm that without this patch, the un-persistance of
"show checkouts" choice is very perturbing for librarians coming from previous
version of Koha.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and QA script, no problems found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Prepare a bunch of Items (6+) for checking out, or have a set of barcodes ready for copy-pasting.
Check-out those items quickly within one minute and observe that the sorting order is not always from the first checkout to the last.
This is because the issuedate doesn't have seconds defined.
AFTER THIS
The bunch of Items is sorted properly.
Tiny patch, works as expected. Passed QA script. Signed-off-by: Marc Veron <veron@veron.ch> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Rafal Kopaczka [Fri, 14 Nov 2014 13:06:22 +0000 (14:06 +0100)]
Bug 13254 - Delete record don't wait for confirmation
In some cases (eg. when Staf Client Search is active), when user choose
Edit->Delete record on record tool bar, browser don't wait for
confirmation and goes immediately to delete record.
To reproduce:
1. Search for some biblio records and choose one without items attached.
2. Note that there, must be "Return to search results" box on left side,
bug works in that case, when in normal view everything work fine.
3. Click Edit->Delete record, watch that confirmation box shows, but
don't wait for OK and runs immediately. If you are fast enough to
click OK, then you get error as below, because record was deleted
earlier.
To test:
1. Apply patch.
2. Follow reproduce steps.
3. Check if waits for confirmation in all cases.
4. Check if deletes record after confirm.
Followed test plan. Patch behaves as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Confirmed the problem and that the patch fixes it.
Good catch!
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Removes note about Display856uAsImage not working on
the OPAC result page.
To test:
- catalog a record with 856$u = URL to an image, $q = img
- turn on the system preference Display856uAsImage
- check that the pref description makes sense and is correct
- the warning about the pref not working on result pages
has been removed
- make sure your record has been reindexed by Zebra
- verifiy the image indeed displays on the result page
in the bootstrap catalog.
Note: The height=100 doesn't work in the Boostrap catalog,
so the images display in their original size. Will file
a separate bug for this.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Owen Leonard [Fri, 14 Nov 2014 15:49:18 +0000 (10:49 -0500)]
Bug 13258 - Clicking the "show checkouts" button should return focus to the barcode field
This patch udpates the checkouts JavaScript so that clicking the "show
checkouts" button or the "always show checkouts" checkbox returns focus
to the barcode field. This improves the checkout workflow by eliminating
a mouse click.
To test, apply the patch and clear your browser cache. Check out to a
patron and confirm that focus is returned to the barcode field after
clicking the "show checkouts" button and the "always show checkouts"
checkbox.
Patch behaves as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, no problems found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Kyle M Hall [Thu, 13 Nov 2014 17:03:42 +0000 (12:03 -0500)]
Bug 12778 - Regression: Item lost status doesn't show in list of checkouts
When using the longoverdue script it's possible that items marked lost
remain on the patron account. I think it's important for staff to see
that some items are marked lost - currently the list of checkouts
doesn't show any sign of the lost status.
Test Plan:
1) Find a patron with a checked out lost item
2) Note the lost status is not displayed in the checkouts table
3) Apply this patch
4) Refresh the page, note the lost status now displays
5) Repeat this test plan for a damaged item
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Tested successfully with damaged and multiple lost values.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, no problems found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Kyle M Hall [Tue, 21 Oct 2014 08:44:24 +0000 (04:44 -0400)]
Bug 13122 - Patron holds table no longer display date item went in transit
In Koha 3.14 and earlier, an item on hold and in transit would display
the date the item was transferred. This is missing from the new ajax
holds table.
Test Plan:
1) Place an item on hold for delivery at a different library
2) Check the item in, confirm the hold and transfer
3) View the patron's holds tab on circulation.pl and/or moremember.pl
4) Note the item is show as in transit, but does not give the "since"
date
5) Apply this patch
6) Note the in transit status now has a "since <date>"
Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Small change, works as described.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 13256 - Typographical error on item search template
Typo error found in the new template itemsearch.tt line 363 "_ matches
only a single charcter"
Test plan:
1) Go to url 'intranet-tmpl/prog/en/modules/catalogue/itemsearch.tt'
line 363 and check the typo "_ matches only a single charcter" and
change for _ matches only a single character
2) Apply the patch
3) Repeat step 1 and check if the typo is fixed
Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Owen Leonard [Tue, 11 Nov 2014 19:55:00 +0000 (14:55 -0500)]
Bug 13233 - Patron search by birth date tooltip broken
When the user selects a patron search by birth date a tooltip is
supposed to appear showing the date format requirement. Bug 9811 (Patron
search improvement) changed the ID on which the tooltip depended to
function. This patch corrects it.
To test, apply the patch and go to the Patrons home page in the staff
client. In the header search form select "Date of birth" from the
"search fields" dropdown. This should trigger a tooltip showing the
required date format.
Signed-off-by: Frederic Demians <f.demians@tamil.fr>
I confirm the tooltip comeback with this patch.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, no problems found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Katrin Fischer [Sun, 9 Nov 2014 21:35:14 +0000 (22:35 +0100)]
Bug 13227: Display856uAsImage displays images in OPAC in original size
To test:
- catalog a record with 856$u = URL to an image, $q = img
- turn on the system preference Display856uAsImage
- make sure your record has been reindexed by Zebra
- verifiy the image indeed displays on the result and detail page
in the bootstrap catalog.
The image shows in the original size, from the code it's meant
to display with a height of 100 px, but this won't work in bootstrap
as the height is set to auto with CSS.
Patch changes the XSLT to restore the former behaviour.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11401: (followup) make tests run on absent deps
The current code breaks if a dependency is missing. The evals are
rearranged so there's no error on missing dependency.
To reproduce:
- Have a dependency for t/NorwegianPatronDB.t removed
- Run
$ prove t/NorwegianPatronDB.t
=> FAIL: You see an error similar to this (may vary depending on the lib you removed):
t/NorwegianPatronDB.t .. You tried to plan twice at t/NorwegianPatronDB.t line 37.
- Apply the patch
- Run
$ prove t/NorwegianPatronDB.t
=> SUCCESS: Tests are skipped on missing lib
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Mark Tompsett [Thu, 18 Sep 2014 16:02:17 +0000 (12:02 -0400)]
Bug 10473 - Max length should be 2 digit for adding multiple copies in add items page
As per the discussion, a prompt on a hard coded soft-limit is
far more acceptable as a solution.
TEST PLAN
---------
0) Back up your DB. -- because a backup is always good!
1) Log in to staff client
2) Navigate to any biblio details
(e.g. cgi-bin/koha/catalogue/detail.pl?biblionumber=#####)
3) Click the 'Edit' dropdown button.
4) Click 'Edit items'.
5) Click 'Add multiple items'
6) Enter a crazy high number (e.g. 999)
7) Click 'Add'
-- Koha just adds it! YIKES!
8) Apply patch
9) Repeat steps 5-7
10) Click 'Cancel'
-- Koha does not add the items.
11) Repeat steps 5-7
12) Click 'Ok'
-- Koha does add the items.
13) run koha QA test tools
14) Restore your DB.
Signed-off-by: Nick Clemens <nick@quecheelibrary.org> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Thu, 19 Jun 2014 16:15:36 +0000 (18:15 +0200)]
Bug 11413: Fix field_numbers
This fix is a global fix for the MarcModificationTemplate feature.
Some unit tests were missing and some behaviors were wrong.
For instance, if you tried to update a non existent field, the script
crashed.
The following line was completely stupid:
if $from_field ne $to_subfield
The field_number equals 1 if the user wants to update the first field
and 0 for all fields.
The field_numbers (note the s) variable contains the field numbers to
update. This array is filled if a condition exists (field exists or
field equals).
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Wed, 18 Dec 2013 09:08:50 +0000 (10:08 +0100)]
Bug 11413: Reflect the changes to the interface
Test plan:
- add/edit an action on the marc modification templates tools
- choose an action and define a condition
- define the source field as same as the condition field
- verify the All/1st dropdown list is changed to Every/1st
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Wed, 18 Dec 2013 08:44:25 +0000 (09:44 +0100)]
Bug 11413: UT to show up the issue
These UT reflect this change:
- deletion of the field 245 if 245$a='Bad title'
- move of the 650 field to 651 if 650$9=499
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Wed, 18 Dec 2013 08:37:19 +0000 (09:37 +0100)]
Bug 11413: Change the field number logic
This patch series is a bugfix for the Marc modification templates tool.
Bug description:
If you want to do an action (delete/update/move/...) on a multivalued
field and if a condition is defined on the same field, it is highly
probable the resulted record will not be what you expect.
For example:
Deleting All (or the first) fields 650 if 245$a="Bad title" works with
the current code.
BUT if you want to delete All (or the first) fields 650 with a condition
on 650$9=42, and if at least one field matches the condition :
- if you have selected all, all fields 650 will be deleted, even the
ones who do not match the condition.
- if you have selected first, the first 650 field will be deleted, even
if it does not match the condition.
The expected behavior is to delete the fields matching the
condition (and not all the 650 fields).
What this patch does:
This patch introduces 2 changes in the logic of Koha::SimpleMARC.
The first change is a change of the prototypes for the 2 routines
field_exists and field_equals. Now they return the "field number" of the
matching fields.
The second change is the type of the "n" parameter for all routines
using it in Koha::SimpleMARC. Before this patch, the "n" parameter was a
boolean in most cases. If 0, the action was done on all fields, if 1
on the first one only. Now it is possible to specify the "field numbers"
(so the array of field numbers which is returned by field_exists or
field_equals) for all routines which had the n parameter.
Test plan for the patch series:
Note: This test plan describes a specific example, feel free to create
your own one.
0/ Define a marc modification template with the following action:
Delete field 245 if 245$9 = 42
1/ choose and export a record with several 245 fields.
For ex:
245
$a The art of computer programming
$c Donald E. Knuth.
$9 41
245
$a Bad title
$c Bad author
$9 42
2/ import it using the Stage MARC for import tool.
3/ verify the imported record does not contain any 245 field.
4/ apply all the patches from this bug report
5/ do again steps 2 and 3
6/ verify the imported record contains only one 245 field, the one with
245$9=41
7/ verify the unit tests passed:
prove t/SimpleMARC.t
prove t/db_dependent/MarcModificationTemplates.t
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Fridolin Somers [Fri, 10 Oct 2014 13:06:45 +0000 (15:06 +0200)]
Bug 13064 - Indexing problem with ICU on control characters
The ICU configuration files contains a rule to remove control characters :
<transform rule="[:Control:] Any-Remove"/>
This rule is before tokenization.
The problem is that "[:Control:]" regex contains line feed, carriage return and tab. See http://www.regular-expressions.info/posixbrackets.html.
So when several lines are indexed, last word of line is joined with first line of next line. Thoses words are then not searchable.
For example :
First line
Second line
This will become "First lineSecond line", tokenized as "First", "lineSecond" and "line".
Test plan :
- Use ICU in Zebra configuration
- Choose an indexed field, like 300$a
- Create a new record
- Enter several lines in choosen field, like :
First line
Second line
- Index this record
=> Without patch the search on "Second" does not return the record
=> With patch the search on "Second" returns the record
- Same tests with tab and carriage return instead of line feed
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Stéphane Delaune [Tue, 21 Oct 2014 16:05:18 +0000 (18:05 +0200)]
Bug 13082: fix to prevent adding of invalid records in marc file
Test:
1. Edit record, add 100.000 chars text to 500a
2. xml export produce the record,
3. mrc export do not produce the record, warning on log export.pl:
Record length of 111000 is larger than the MARC spec allows (99999
bytes). at /usr/share/perl5/MARC/File/USMARC.pm line 314. record
(number 139489) is invalid and therefore not exported because its
reopening generates warnings above at...
Signed-off-by: Frederic Demians <f.demians@tamil.fr>
I confirm that exporting biblio records larger than 10000 characters in
ISO2709 produces invalid files. After applying this patch, the culprit
record (too large, but also other inconsistencies preventing record
parsing with MARC::File::USMARC) is not exported anymore. A warning is
produced in Koha Apache log file. Warnings to the user on WUI would be
better, but it isn't the case yet, so it isn't a regression.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
I agree that a visible warning/result message in the staff interface
would be nice, but this works as described.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Katrin Fischer [Mon, 10 Nov 2014 10:33:11 +0000 (11:33 +0100)]
Bug 7988: Make note on authorized values page less confusing
Nicole suggested a change of the note, that this patch is implementing:
NOTE: If you change an authorized value code, existing records
using it won't be updated. Changes to value descriptions will show
immediately.
To test:
- Go to administration > authorised values
- Check the note showing on the page
- Select a category from the pull down and edit an existing entry
- Check the note on this page is also correct
Patch behaves as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Katrin Fischer [Sun, 9 Nov 2014 23:08:10 +0000 (00:08 +0100)]
Bug 13207: "Branch" on basket summary page should be "Library"
To test:
- Create or find an open basket/order in the acquisition module
- Check that "Branch" now reads "library"
- Set to "no library"
- No branches should be seen there.
Signed-off-by: jeremie.benarros <jeremie.benarros@inlibro.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Katrin Fischer [Mon, 10 Nov 2014 19:36:44 +0000 (20:36 +0100)]
Bug 10136: Remove outdated translation tool docs
Patch removes outdated translation tool documentation
from the misc/translator directory.
Signed-off-by: Magnus Enger <digitalutvikling@gmail.com>
Removing these lines sounds like a good idea. I tested by
applying the patch and checking that the files in question
are gone.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jacek Ablewicz [Fri, 7 Nov 2014 12:04:22 +0000 (13:04 +0100)]
Bug 13220 - Shipment date not saved when creating an invoice which has a duplicated number
When creating an invoice which has a duplicated number, if the user chooses to 'Create new invoice anyway', previously entered shipment date (todays date by default) is not being saved, because the date value is passed to the script in the wrong format (acqui/parcels.pl expects shipmentdate parameter to be in the system-configured date format, but what it's getting in such cases is ISO-formatted date instead). As a consequence (when receiving orders from invoice whith empty shipment date) 'datereceived' field in order records are also not being populated. Here and there, Koha is using datereceived field to establish if the order was received or not received, so such not-quite-complete orders:
- can be cancelled from the basket (even when they are de facto already received),
- it's not possible to cancel receipt of those orders from the invoice (because Koha is considering them as not yet received).
To reproduce:
1) Make sure you have some system date format configured in your test environment which is different from ISO format (e.g., DD/MM/YYYY) and the AcqWarnOnDuplicateInvoice syspref is enabled
2) Create some invoice with e.g. '11111' number,
3) Create another invoice with the same number (using 'Create new invoice anyway' button)
4) Try to create yet another invoice with the same number; observe that already existing invoice created in step 3) does have empty shipment date.
5) Optional: create some orders and receive them from the invoice with empty shipment date; observe that such orders are not being treated as received in all places (e.g. it's not possible to cancel receipts of such orders, and the message displayed is not in any way helpfull to determine why not).
To test:
1) Apply patch
2) Retest
3) Ensure that the issue is no longer reproductible, and that there are no apparent regressions of any kind.
Signed-off-by: simith <simith@inlibro.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Tiny change fixing a bad bug. No problems found, passes tests and QA script.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Wed, 12 Nov 2014 16:14:32 +0000 (17:14 +0100)]
Bug 13226: 9999-12-31 should not considered as a valid date
DateTime::Format::DateParse (called in Koha::DateUtils::dt_from_string)
does not manage to parse 9999-12-31 if a time zone is given.
my $date = DateTime->new(year => 9999, month => 12, day => 31);
=> OK
DateTime::Format::DateParse->parse_datetime( '9999-12-31' );
=> OK
DateTime::Format::DateParse->parse_datetime( '9999-12-31',
'America/Los_Angeles' );
=> KO (~20sec on my laptop)
It should not be considered as a valid date when the letter is parsed.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Note that to reproduce the problem you much be checking in items from an
account which has been restricted indefinitely (either manually or by
the overdues process). With this patch such checkins go from taking
around 50 seconds (in my test system) to around 7 to 10 seconds.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Good catch! Works as described, no problems found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Magnus Enger [Thu, 13 Nov 2014 18:43:29 +0000 (18:43 +0000)]
Bug 11401: QA followup - Make the tests pass
The configs in koha-conf.xml needed to be mocked. There was also
a problem with how the NorwegianPatronDBEndpoint syspref was
getting checked in the .pm.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Magnus Enger [Wed, 29 Oct 2014 09:31:26 +0000 (10:31 +0100)]
Bug 11401: QA followup - fix pod
The QA script was complaining about some dodgy POD in C4/Members.pm,
that was not introduced by bug 11401. This patch fixes the POD, to
keep the QA script happy.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Magnus Enger [Wed, 17 Sep 2014 08:16:45 +0000 (10:16 +0200)]
Bug 11401: Add support for Norwegian national library card
This patch makes it possible to sync patron data between Koha and the
Norwegian national patron database, in both directions.
In order to use this, the following information is necessary:
- a username/password from the Norwegian national database of libraries
("Base Bibliotek"), available to all Norwegian libraries
- a special key in order to decrypt and encrypt PIN-codes/passwords,
which is only available to Norwegian library system vendors
- a norwegian library vendor username/password
See http://www.lanekortet.no/ for more information (in Norwegian).
While this is of course an implementation of a specific synchronization scheme
for borrower data, attempts have been made to prepare the ground for other sync
schemes that might be implemented later. Especially the structure of the new
borrower_sync table might be reviewed with an eye to how it might fit other
schemes.
To test:
Since the password and cryptographic key needed to use this functionality
is only available to Norwegian library system vendors, only regression testing
can be done on the submitted code. Suggested things to check:
- Apply the patch and make sure the database update is done. This should add
the new "borrower_sync" table and five new systmpreferences under the
"Patrons" > "Norwegian patron database" category:
- NorwegianPatronDBEnable
- NorwegianPatronDBEndpoint
- NorwegianPatronDBUsername
- NorwegianPatronDBPassword
- NorwegianPatronDBSearchNLAfterLocalHit
- Check that patrons can be created, edited and deleted as usual, when
NorwegianPatronDBEnable is set to "Disable"
- Check that the new tests in t/NorwegianPatronDB.pm run ok, e.g. on a
gitified setup:
$ sudo koha-shell -c "PERL5LIB=/path/to/kohaclone prove -v t/NorwegianPatronDB.t" instancename
- Check that all the other tests still run ok
- Check that the POD in the new files itroduced by this patch looks ok:
- Koha/NorwegianPatronDB.pm
- members/nl-search.pl
- misc/cronjobs/nl-sync-from-koha.pl
- misc/cronjobs/nl-sync-to-koha.pl
- t/NorwegianPatronDB.t
Sponsored-by: Oslo Public Library
Update 2014-09-18:
- Rebase on master
- Split out changes to Koha::Schema
- Incorporate new way of authenticating with NL
Update 2014-10-21:
- Rebase on master
- Use Module::Load to load Koha::NorwegianPatronDB in non-NL-specific
scripts and modules
- Fix the version number of Digest::SHA
- Fix a missing semicolon in kohastructure.sql
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
There's no point creating a MARC record with undef subfields
for testing holds. This patch avoids that so no warnings are shown.
To test:
- Run
$ prove t/db_dependent/Holds.t
=> FAIL: verify several warnings show
- Apply the patch
- Re-run
=> SUCCESS: no warnings showed.
- Sign off :-D
Regards
NOTE: Not noticable under Ubuntu 12.04 LTS, but verifiable under
Debian Wheezy.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Mark Tompsett [Sun, 12 Oct 2014 00:02:35 +0000 (20:02 -0400)]
Bug 13075: Silence warnings and improve Charset testing.
Calls to C4/Charset.pm's NormalizeString function with an
undefined string were triggering warnings when running:
prove -v t/db_dependent/Holds.t
Sadly, t/Charset.t was also lacking calls to NormalizeString.
TEST PLAN
---------
1) prove -v t/db_dependent/Holds.t
-- This should generate the uninitialized string warnings.
Make sure CPL and MPL are in your branches to save
yourself from headaches due to expected data.
2) cat t/Charset.t
-- note there are no function calls to NormalizeString.
You can see other shortfalls in the tests beyond
NormalizeString with: grep ^sub C4/Charset.pm
3) prove -v t/Charset.t
4) Apply patch
5) prove -v t/Charset.t
-- Run as before with more tests.
6) cat t/Charset.t
-- note there are now function calls to NormalizeString.
7) prove -v t/db_dependent/Holds.t
-- Nice and clean run! :)
8) koha-qa.pl -v 2 -c 1
-- all should be Ok.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Katrin Fischer [Sun, 9 Nov 2014 22:27:47 +0000 (23:27 +0100)]
Bug 12779: Capitalization on add/edit subscription form
To test:
- Add or edit a new or existing subscription in the serials
module
Patch changes "biblio" to "record" and fixes capitalization:
Search for record | Create record
Patch behaves as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 6681: (qa followup) document the existence of the sample files
As requestedby people testing the patch, I add references to the new
xslt files on the Z39.50/SRU servers help.
Example usages are also provided.
Test:
- Apply the patch
- Go to the help page on the 'Z39.50/SRU Servers' page
=> SUCCESS: Notice there's a section documenting XSLT file(s) usage
and provides some examples that cover the introduced files.
- Sign off
Thanks
Tomas
Sponsored-by: Universidad Nacional de Cordoba Signed-off-by: Frederic Demians <f.demians@tamil.fr>
Help page does shed some light to the XSLT usage. Enough to my taste.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Thay can be used on the new SRU/Z39.50 XSLT processing feature. At the same
time they can be used to solve this bug.
To test:
- Have an SRU/Z39.50 target configured
- Have a search that returns at least a record with the following
properties:
* It contains $9 links
* It contains items (952 or 995 fields in MARC21/NORMARC and UNIMARC respectively).
MARC21/NORMARC test:
- Do a Z39.50/SRU cataloguing search that retrieves the desired record
- Verify it includes $9 and 952 field(s) by clicking on the MARC link
- Edit your Z39.50 target and add Del952.xsl to the "XSLT File(s) for transforming results:" field
- Re-run the search
=> SUCCESS: the MARC view of the imported record doesn't contain the 952 field
- Edit your Z39.50 target and add Del9LinksExcept952.xsl to the "XSLT File(s) for transforming results:" field
- Re-run the search
=> SUCCESS: the MARC view contains the 952 field (including the $9 subfield), and
all other $9 subfields have been removed
- Edit your Z39.50 target and add
Del952.xsl, Del9LinksExcept952.xsl
to the "XSLT File(s) for transforming results:" field (both, comma separated)
- Re-run the search
=> SUCCESS: the MARC view doesn't contain $9 subfields nor items.
- Repeat for UNIMARC, replacing 952 for 995.
- Sign off :-D
Regards
Tomas
Sponsored-by: Universidad Nacional de Cordoba Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested under MARC21. Works fine. (Additionally verified 995 with xsltproc.)
As noted on Bugzilla, we could still improve documentation but imo no need
to block these example transformations.
Signed-off-by: Frederic Demians <f.demians@tamil.fr>
I can't resist to put my own signature on this patch, confirming it works as
described with z39.50 Unimarc targets.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Owen Leonard [Fri, 14 Nov 2014 01:15:22 +0000 (20:15 -0500)]
Bug 13253 - Unnecessary white space above checkouts table in circulation
On the new checkouts page there is some padding above the checkouts,
relatives' checkouts, and holds tables caused by extra markup in the
table's sDom configuration (http://legacy.datatables.net/ref#sDom):
<'row-fluid'<'span6'><'span6'>r>t<'row-fluid'>t
This creates several empty <div>s which don't serve any purpose. This
patch simplifies it to:
rt
To test, apply the patch, clear your browser cache, and check out to a
patron who has items checked out, holds on their account, and child
records attached which also have checkouts.
The padding above the table of checkouts, the table of relatives'
checkouts, and the table of holds should match that on the sides.
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Checked per plan on both Check Out and Details pages, spacing appears correct.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, no problems found.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Marcel de Rooy [Fri, 31 Oct 2014 09:14:16 +0000 (10:14 +0100)]
Bug 11319: [QA follow-up] Remove a warning from GetModificationTemplates
Removes this warning: Use of uninitialized value $template_id in string eq
at C4/MarcModificationTemplates.pm line 84.
GetModificationTemplates has no template_id if called from
marc_modification_templates.pl without operation (first click from
interface) and from tools/stage-marc-import.pl.
Slightly adjusted the POD lines accordingly.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Wed, 11 Dec 2013 16:11:01 +0000 (17:11 +0100)]
Bug 11319: Template modifications
This patch add template modifications for the restrictions:
- the source field is always mandatory
- on move and copy, the source and destination subfield should be both
filled or blank.
- on move and copy, the destination subfield should be filled.
- on update, the subfield value should be filled.
Test plan:
Verify you are not able to create/modify template actions according to
these restrictions.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Wed, 11 Dec 2013 14:53:37 +0000 (15:53 +0100)]
Bug 11319: Add specific UT for nonexistent field/subfield
This patch only adds unit tests for the copy and move actions.
They test if the action does not create a field/subfield if the source
did not exist.
Also it adds a unit tests for the existing behavior (in order not to
lost it): we can use the '^' and the '$' character in regex for
substituing. For example: Copy 245$a to 245$a with the regex s/^/BEGIN /
This will add the string "BEGIN " at the beginning of the 245$a fields.
To test: prove t/SimpleMARC.t
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Wed, 11 Dec 2013 14:39:49 +0000 (15:39 +0100)]
Bug 11319: Add the field management for Koha::SimpleMARC
Currently the Koha::SimpleMARC module call a "field" a "subfield".
And the way to manage field is not implemented for all routines.
This patch does not modify the API. The routine's names are kept. It
just creates 2 privates routines for each action (e.g. delete_field
will call _delete_field if the action affects field and _delete_subfield
if the action affects subfields).
Before this patch the move action was authorised by the interface but
caused an error if executed.
Note: I don't see the meaning for the add/update action if no subfield
is given. So the call without subfield raises an error.
Test plan:
- apply all patches
- create or modify an existent template
- try at least the correct behavior for the following actions:
* delete subfield and field
* add new subfield to an existing field
* add new subfield to an nonexisting field
* move a subfield
* move an entire field
* copy a subfield
* copy an entire field
- import a biblio and use this template
- verify the imported biblio matches actions defined.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Wed, 11 Dec 2013 14:39:26 +0000 (15:39 +0100)]
Bug 11319: Add UT for the fields management
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Wed, 11 Dec 2013 13:22:03 +0000 (14:22 +0100)]
Bug 11319: Koha::SimpleMARC should take a hashref for parameters
In order to avoid a long list of parameters, it should be better to
pass all of them into a hashref.
This patch does not add or modify a behavior.
Test plan:
Verify the unit tests still pass
- prove t/SimpleMARC.t
- prove t/db_dependent/MarcModificationTemplates.t
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Kyle M Hall [Wed, 29 Jan 2014 15:52:08 +0000 (10:52 -0500)]
Bug 11634 - Allow renewal of item with unfilled holds if other available items can fill those holds
The current holds behavior in Koha allows a situation like this:
- Patron A has an item currently checked out.
- Patron B places a hold on the next available copy of that title.
- Then Patron A will not be able to renew his item, even if there are
other available copies of that title that could potentially fill Patron
B's hold.
Since this seems unfair to Patron A, we should allow renewal of items
even if there are unfilled holds, but those holds could all be filled
with currently available items.
Test Plan:
1) Apply this patch
2) Create a record with two items
3) Check out the item to a patron
4) Place a hold on the record
5) Note you cannot renew the item for the patron
6) Enable the new system preference AllowRenewalIfOtherItemsAvailable
7) Note you can now renew the item, as all the holds can be satisfied
by available items.
8) Place a second hold on the record
9) Note you can no longer renew the item, as all the holds *cannot*
be filled by currently available items
Signed-off-by: Holger Meissner <h.meissner.82@web.de> Signed-off-by: Chris Rohde <crohde@roseville.ca.us> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 13116 - Make it possible to propagate errors from C4::Reserves::CanItemBeReserved() to the web-templates.
This patch changes the way CanBookBeReserved() and CanItemBeReserved() return error
messages and how they are dealt with in the templates. This change makes it possible
to distinguish between different types of reservation failure.
Currently only two types of errors are handled, all the way to the user, from the CanItemBeReserved():
-ageRestricted
-tooManyReserves which translates to maxreserves
#############
- TEST PLAN -
#############
((-- AGE RESTRICTION --))
STAFF CLIENT
1. Find a Record with Items, update the MARC Subfield 521a to "PEGI 16".
2. Get a Borrower who is younger than 16 years.
3. Place a hold for the underage Borrower for the ageRestricted Record.
4. You get a notification, that placing a hold on ageRestricted material is
forbidden. (previously you just got a notification about maximum amount of reserves reached)
((-- MAXIMUM RESERVES REACHED --))
0. Set the maxreserves -syspref to 3 (or any low value)
STAFF CLIENT AND OPAC
1. Make a ton of reserves for one borrower.
2. Observe the notification about maximum reserves reached blocking your reservations.
((-- MULTIPLE HOLDS STAFF CLIENT --))
3. Observe the error notification "Cannot place hold on some items"
((-- MULTIPLE HOLDS OPAC --))
1. Make a search with many results, of which atleast one is age restricted to the current borrower.
2. Select few results and "Place hold" from to result summary header element.
(Not individual results "Place hold")
3. Observe individual Biblios getting the "age restricted"-notification, where others can be
reserved just fine.
Updated the unit tests to match the new method return values.
t/db_dependent/Holds.t & Reserves.t
Followed test plan. Works as expected and displays meaningful messages for the reason why placing a hold is not possible.
Signed-off-by: Marc Veron <veron@veron.ch> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Owen Leonard [Fri, 10 Oct 2014 11:56:11 +0000 (07:56 -0400)]
Bug 10632 [Follow-up] Enable datatables for courses and course details in the OPAC
This follow-up adds some style improvements and corrects some errors in
the previous patch:
- The path to datatables.css has been corrected
- Unused CSS has been removed from datatables.css (particularly related
to pagination controls, which are currently unused in the OPAC).
- Style has been added to datatables.css to make the table search form
look better.
- The configuration of the course details table has been enhanced to
include a title sort which ignores articles and date sorting according
to the "title-string" method for date format agnostic sorting.
- Unrelated: A message <div> has been modified to have the correct style
for the Bootstrap theme.
To test you should have multiple courses and at least one course with
multiple reserves. Clear your browser cache if necessary and view the
list of courses in the OPAC. All table sorting should work correctly, as
should the table search form.
View the details of a course which has multiple reserves. All sorting
should work correctly, including title sort excluding articles. Sorting
by date due should work correctly for any dateformat system preference
setting.
View the details of a course which has no reserves. You should see a "No
reserves" message box with a style consistent with similar messages in
the Bootstrap OPAC.
View other sorted tables in the OPAC to confirm that the CSS changes
have not negatively affected their appearance: opac-user.pl for
instance, or opac-detail.pl.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Kyle M Hall [Thu, 9 Oct 2014 14:01:16 +0000 (10:01 -0400)]
Bug 10632 - Enable datatables for courses and course details in the OPAC
We should use datatables for the courses and course items tables. This
will make the tables sortable and searchable from the client side.
Test Plan:
1) Apply this patch
2) View the courses in the OPAC, try sorting and searching
3) View the course details for a course, try sorting and searching the items.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signing off, but have a follow-up to address some missing stuff.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Wed, 5 Nov 2014 15:09:04 +0000 (16:09 +0100)]
Bug 8218: qa followup
This patch
- rename _entity_clean as _clean_ampersand
- rename the script to sanitize_records.pl
- add a --fix-ampersand switch (the only one FOR NOW, enabled by
default) so it is obvious what the script does.
- make POD and usage reflect this changes.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Fri, 28 Sep 2012 13:23:37 +0000 (15:23 +0200)]
Bug 8218 : Add a maintenance script to sanitize biblio records
This patch adds:
- a new maintenance script batch_sanitize_records
- a new subroutine C4::Charset::SanitizeRecord
- new unit tests for the new subroutine
Test plan:
1/ prove t/db_dependent/Charset.t
2/ Create a record containing "&amp;" (could be follow with as many
'amp;' as you want) in one of its fields and the same for the field
linked to biblioitems.url.
The url should not be sanitized, it may contain "&".
3/ Launch the maintenance script with the -h parameter to see how to use
it.
4/ Launch the script using the different parameters:
--filename=FILENAME
--biblionumbers='XXX'
--auto-search
The auto-search permits to sanitize all records containing "&amp;" in
the marcxml field.
Use the verbose flag for testing.
Without the --confirm flag, nothing is done.
5/ Use the --confirm flag and verify in the biblioitems.marcxml field
that the record has been sanitized.
6/ Try the --reindex flag to reindex records which have been modified.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Owen Leonard [Thu, 30 Oct 2014 13:57:49 +0000 (09:57 -0400)]
Bug 12258 [Template follow-up] Datatable in Patrons Account Fines
This follow-up corrects some of the QA issues affecting the other patch,
as well as changing the way the "filter" option is displayed:
- Added the use of the DataTables include file
- Removed redundant document.ready
- Fixed single quotes
- Fixed default sort (should be date descending to match the current
functionality)
- Adding missing <tr>
- Converted filter button to a link
The last change is a judgement call, but the button in the DataTables
toolbar looked awkward and caused ugly wrapping at narrower viewport
sizes. I think a link is more keeping with the pattern established by
"select all / clear all" links.
To test, apply both patches and view the account page
(members/boraccount.pl) for a patron who has paid and unpaid fines (the
more the better).
- Confirm that the default sort is by date descending.
- Confirm that DataTables controls (paging, search, result count) work
correctly.
- Confirm that clicking the "Filter paid transactions" link works
correctly to toggle display of paid transactions.
Works as expected. Passed koha-qa.pl. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Works as described, no problems found.
Passes QA script and tests.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 12258 Adds Datatables to the Fines->Account page of patrons (members/boraccount.pl). Also adds a button "Filter paid transactions" to hide fines with no outstanding value (0.00).
Test steps :
* Create a few manual invoices with fines.
* Pay a fine.
* Go back to the account tab.
* Try the "Filter paid transactions" button. It should filter everything with 0.00 in the Outstanding column.
* Try the "Show all transactions" button.
* Play around with the buttons
Followed test steps. Works as expected. Signed-off-by: Marc Véron <veron@veron.ch> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Owen Leonard [Tue, 7 Oct 2014 18:14:03 +0000 (14:14 -0400)]
Bug 9214 [Compiled CSS] Show damaged status in the OPAC for items which are not for loan
This patch contains the compiled opac.css file generated from the
revised LESS file in this bug's other patch.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Owen Leonard [Tue, 7 Oct 2014 18:08:02 +0000 (14:08 -0400)]
Bug 9214 - Show damaged status in the OPAC for items which are not for loan
Item statuses in the OPAC displayed according to a cascading hierarchy:
If something is lost it will appear as lost, "else if" it is checked out
it will appear as checked out, etc. I don't think there is a logical
reason why statuses should appear this way.
This patch modifies the logic in the template so that multiple statuses
can be displayed at the same time. The patch also wraps each status in
its own class so that libraries can apply custom CSS if they wish.
Some tweaks have been made to the LESS file adding some style to the
common "item-status" class for display of item statuses.
To test, apply the patch and view one or more titles in the OPAC which
have items with the following statuses: lost, checked out, damaged, not
for loan, waiting, on order, in transit, withdrawn, and available.
Modify items to have more that one status simultaneously, in particular
not for loan and damaged.
Also test the display of item statuses in the OPAC cart and the OPAC's
course details page (Course reserves -> [Course name]) since these pages
use the same include file.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Thu, 2 Oct 2014 13:52:52 +0000 (15:52 +0200)]
Bug 12989: Fix JS error
inactive and active are not defined anymore. They should be removed. The
filter is done with DataTables.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Wed, 24 Sep 2014 15:23:42 +0000 (17:23 +0200)]
Bug 12989: Update table footer with the visible rows - acqui-home
Note that bug 12984 changes the view of this table.
On the acqui-home page, the total was not updated.
With this patch, the footer (totals) will be updated on filtering rows.
Test plan:
1/ Go on the acqui home page.
2/ Verify the totals are correct.
3/ Filter the table using the filter input and verify the totals are
updated with the rows shown.
4/ Hide/Show inactive budgets and verify the totals are still corrects.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Wed, 24 Sep 2014 09:19:52 +0000 (11:19 +0200)]
Bug 12984: Improvement of the funds list view - acqui home
Bug 11578 improved the funds list view in the administration module.
It would be great to have the same improvement on the acquisition
home page.
This improvement groups funds by budget and displays them with a
hierarchy.
Test plan:
0/ Create a budget and fund hierarchy, with active and inactive budgets.
1/ Go on the acquisition home page and verify the values are the same as
before
2/ Verify the funds are correctly listed
3/ Verify the links on top of table work (expand/collapse all, show/hide
inactive budgets).
Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Wed, 24 Sep 2014 15:16:48 +0000 (17:16 +0200)]
Bug 12988: Update table footer with the visible rows - budgets
On the budget list view, the total was not updated.
With this patch, the footer (totals) will be updated on filtering rows.
Test plan:
To test with both CurrencyFormat pref values.
1/ Go on the budget list view
2/ Verify the totals are correct.
3/ Filter the table using the filter input and verify the totals are
updated with the rows shown
4/ Hide/Show inactive budgets and verify the totals are still corrects.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Marcel de Rooy [Mon, 20 Oct 2014 10:36:36 +0000 (12:36 +0200)]
Bug 13203: Plugin housekeeping: UNIMARC field 123i, 123j, 210c
In working on bug 10480, I noticed that these plugins needed some attention:
[2] unimarc_field_123i.pl: added missing template
[3] unimarc_field_123j.pl: resolved missing template with same file
[4] unimarc_field_210c_bis.pl: removed a warn, corrected some POD lines
Note about UNIMARC field 123i and 123j: Subfields $i and $j are each 8
characters long and contain the same components as subfields $f and $g
except that character position 0 contains a plus sign (for the northern
celestial hemisphere) or a minus sign (for the southern celestial hemisphere).
Test plan:
Connect unimarc_field_123i and 123j to some field.
Look especially at changing + or - for the hemisphere in the popup.
Check left-padding with zeroes for the other positions.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and QA script.
Checked plugin in a UNIMARC installation.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Owen Leonard [Wed, 29 Oct 2014 15:58:39 +0000 (11:58 -0400)]
Bug 7673 [Terminology follow-up] New patron permissions to manage items
This bug adds a new preference, "SubfieldsToAllowForRestrictedEdition,"
but the use of the term "Edition" in this context is incorrect. I think
it would be more clear to change the preference name to
"SubfieldsToAllowForRestrictedEditing." This patch makes this change.
I realize this isn't a big issue since the preference has a good
description, but I thought that if we were going to make this as clear
as possible now would be the time to do it.
To test, start with a database which hasn't previously been used to test
Bug 7673. Apply all patches and run the database update. Follow the test
plan as described in the bug.
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, change appears complete.
All tests and QA script still pass.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Fri, 10 Oct 2014 19:50:05 +0000 (21:50 +0200)]
Bug 7673: add syspref in sysprefs.pl
Also fix a typo in the permission description
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Patches pass QA script and tests.
Copying the test plan from the bug report:
Test plan:
1/ add the following permissions to the logged in patron:
edit_item, edit_items_restricted, delete_all_items,
items_batchmod, items_batchmod_restricted
2/ Fill the prefs SubfieldsToAllowForRestrictedEdition
and SubfieldsToAllowForRestrictedBatchmod with some
subfield (for instance "995$f 995$o" and "995$o")
3/ Verify you are allowed to edit the item fields defined
in the pref SubfieldsToAllowForRestrictedEdition.
4/ Try to edit item in a batch and verify you are allowed
to edit the item fields defined in the pref
SubfieldsToAllowForRestrictedBatchmod.
5/ Try to delete all items of a record
Play with the pref/permissions and verify they are
correctly taken into account.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
2 system preferences:
- SubfieldsToAllowForRestrictedEdition
- SubfieldsToAllowForRestrictedBatchmod.
Signed-off-by: Koha Team AMU <koha.aixmarseille@gmail.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Fri, 25 Apr 2014 14:57:58 +0000 (16:57 +0200)]
Bug 7673: Change the superlibrarian check
To know if the user is a superlibrarian, we have to call
C4::Context->IsSuperLibrarian
Signed-off-by: Koha Team AMU <koha.aixmarseille@gmail.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Fri, 25 Apr 2014 14:51:35 +0000 (16:51 +0200)]
Bug 7673: Update permission names in script
Two permission names have been changed since the first patch.
Signed-off-by: Koha Team AMU <koha.aixmarseille@gmail.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Fri, 25 Apr 2014 14:37:17 +0000 (16:37 +0200)]
Bug 7673: Update syspref names in script
The both syspref names have been changed since the first patch.
Signed-off-by: Koha Team AMU <koha.aixmarseille@gmail.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Tue, 1 Apr 2014 08:30:16 +0000 (10:30 +0200)]
Bug 7673: the limitation on editing an item does not affect FA framework
The pref SubfieldsToAllowForLimitedEdition should not affect Fast
cataloguing framework (FA).
Signed-off-by: Koha Team AMU <koha.aixmarseille@gmail.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Jonathan Druart [Mon, 31 Mar 2014 11:50:08 +0000 (13:50 +0200)]
Bug 7673: The delete all items link should only be displayed if delete_all_items is set
This test had been lost in a rebase.
Signed-off-by: Koha Team AMU <koha.aixmarseille@gmail.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Koha Team AMU <koha.aixmarseille@gmail.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
- editcatalogue.limited_item_edition: Limit item modification to barcode, status and note
- editcatalogue.delete_all_items: Delete all items at once
- tools.items_limited_batchmod: Limit batch item modification to item status
The SubfieldsToAllowForLimitedEdition syspref is used to define which subfields can be edited
when the editcatalogue.limited_item_edition permission is enabled.
In the same way, the SubfieldsToAllowForLimitedBatchmod is used to define which subfields
can be edited when the tools.items_limited_batchmod permission is enabled.
Signed-off-by: Koha Team AMU <koha.aixmarseille@gmail.com> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
projects / koha.git / log