[koha-commits] main Koha release repository branch 3.12.x updated. v3.12.10-8-gcc4a2a6
Git repo owner
gitmaster at git.koha-community.org
Fri Feb 7 15:31:38 CET 2014
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "main Koha release repository".
The branch, 3.12.x has been updated
via cc4a2a641ed9d662afbf188b418cc62f41b4cdc3 (commit)
via 149274689deca86d0d102fe2f681c0c470cd5c86 (commit)
via a60cd8a6b7dc42759ef9b6ea7deb54790fab2605 (commit)
via 5739cd798d5a76cb1f69b772ac5a0efde0ec532e (commit)
via 66ae2ee57d0daa168fe3ff4d33585241b890c873 (commit)
via 66b185db7a16e3883a45361aa1075b95a7404de9 (commit)
via a120f4cf09d7226febcae3320aa3de8bf8e44552 (commit)
via 9cd6cc2b94e24daeb2c140f5da43fcc28c01b99a (commit)
from a0a276723c8686d4606855943b07dc36dc0e2790 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit cc4a2a641ed9d662afbf188b418cc62f41b4cdc3
Author: Tomas Cohen Arazi <tomascohen at gmail.com>
Date: Fri Feb 7 11:50:48 2014 -0300
DBRev 3.12.10.001
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
commit 149274689deca86d0d102fe2f681c0c470cd5c86
Author: Katrin Fischer <Katrin.Fischer.83 at web.de>
Date: Mon Dec 23 19:49:14 2013 +0100
Bug 8018: (follow-up) fixing some wrong capitalization
Fixes capitalization in 2 places:
- Delete a subfield - Yes/No options
- Edit a subfield - Edit subfield
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
(cherry picked from commit 3b9d8074b85b7d06c555491a75a48ac751560ec2)
Signed-off-by: Fridolin SOMERS <fridolin.somers at biblibre.com>
(cherry picked from commit bbc101bb1cb6705ea518b5f4fbd786393c643c22)
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
commit a60cd8a6b7dc42759ef9b6ea7deb54790fab2605
Author: Tomas Cohen Arazi <tomascohen at gmail.com>
Date: Thu Dec 12 12:24:11 2013 -0300
Bug 8018: (followup) make the default more explicit
This patch:
- Makes the new subfield tab show maxlength=9999 as default (instead of
empty-then-zero).
- Updates the help to make exlpicit that 0 or empty defaults to 9999.
- Assumes all the subfields created with maxlength=0 inadvertedly are
meant to mean "no limit" and hence update the database to reflect
that.
To test (this patch and Pablo's):
- Edit a MARC framework, edit some field's subfields.
- Use the 'New' tab to create a new subfield (choose an unused letter).
- See in "More constrains" that the "Max length" field is empty. Leave
it as-is.
- Save the changes (the new subfield).
- Edit the field again, verify that "Max length" is 0.
- Try tu use the framework and the the field/subfield just created
> FAIL
- Apply the patches, upgrade
- Try to use the framework/field/subfield > SUCCESS (0 was converted to
9999)
- Repeat from the begining, "Max length" should show 9999 on the new
subfield tab.
- Leave it empty, it is saved as 9999.
Edit: small typo
Sponsored-by: Universidad Nacionald de Cordoba
Signed-off-by: Chris Cormack <chrisc at catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83 at web.de>
Passes QA script and tests in t and xt.
Tested:
- deleting an existing subfield
- adding a new subfield with new default 9999
- editing the new subfield, changing value to 8888
- deleting new subfield
- adding new subfield, using 8888 as length
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
(cherry picked from commit b5eab7c20bb8c2d07966bf1f68eaf0a7f953222e)
Signed-off-by: Fridolin SOMERS <fridolin.somers at biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
Conflicts:
installer/data/mysql/updatedatabase.pl
(cherry picked from commit 828d9b9f20fa4f01b6fb6bd4d9ff20d674f3ceac)
commit 5739cd798d5a76cb1f69b772ac5a0efde0ec532e
Author: Pablo Bianchi <pablo.bianchi at gmail.com>
Date: Wed Dec 11 15:54:54 2013 -0300
Bug 8018: MARC framework max subfield length should default to 9999
The default value for the marc_subfield_structure.maxlenght is 9999
in the DB. Currently the template passes an empty value which is casted to
0 by the CGI.
This simple patch validates the input and converts to the default (9999)
if not defined or 0.
Another approach could be changing the 9999 default and/or treating 0 as
'no-limit'.
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
Works by defaulting 0 or "" to 9999.
Signed-off-by: Chris Cormack <chrisc at catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83 at web.de>
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
(cherry picked from commit 1ebbf40ecc07b9474e81e20ec1598659ab027d7a)
Signed-off-by: Fridolin SOMERS <fridolin.somers at biblibre.com>
(cherry picked from commit a3f0eb97697213a267de0f8191e2acbc4197f6ab)
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
commit 66ae2ee57d0daa168fe3ff4d33585241b890c873
Author: Kyle M Hall <kyle at bywatersolutions.com>
Date: Wed Dec 18 14:44:53 2013 -0500
Bug 11419: display Z39.50 search errors more completely
When a z39.50 server isn't able to be searched successfully, the yellow
error box came up empty. This patch fixes the problem.
Test Plan:
1) Go to Administration/z39.50 servers
2) Create a fake z39.50 server with a made up address
3) Go to cataloging, search only that server
4) Note the empty yellow alert box
5) Apply this patch
6) Re-run the search, not the alert box has a message in it now
Signed-off-by: Nora Blake <nblake at masslibsystem.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83 at web.de>
Passes all tests and QA script.
Works according to test plan.
When one of the selected servers gives result no dialog
box is shown before and after applying the patch.
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
(cherry picked from commit 0fc114eee3f649abea88a62502211c595c2867b8)
Signed-off-by: Fridolin SOMERS <fridolin.somers at biblibre.com>
(cherry picked from commit 0c4e9a01544d898db10e704aea15633d689311be)
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
commit 66b185db7a16e3883a45361aa1075b95a7404de9
Author: Matthias Meusburger <matthias.meusburger at biblibre.com>
Date: Wed Dec 18 11:20:05 2013 +0100
Bug 11412: fix potential bulkmarcimport crash when searching for duplicates in authorities
bulkmarcimport.pl can crash when searching for duplicates if the 005
field from the incoming or local record is not defined. This patch
fixes it.
Signed-off-by: Chris Cormack <chrisc at catalyst.net.nz>
Test plan
1/ Create a record with no 005 field
2/ Try to import it checking for duplicates, notice it crashes
3/ Try with a record with a 005 field, but the one in Koha missing
one, still crashes
4/ Apply patch
5/ No more crash
Signed-off-by: Katrin Fischer <Katrin.Fischer.83 at web.de>
Passes all tests and QA script.
Patch fixes the problem described for importing authorities
with the bulkmarcimport.pl when trying to match with existing
records.
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
(cherry picked from commit 28d97e322805a42680527232b151754b4778aed8)
Signed-off-by: Fridolin SOMERS <fridolin.somers at biblibre.com>
(cherry picked from commit 16df6d75044a6b1d64bb0ab4f0bded4b4699d5d6)
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
commit a120f4cf09d7226febcae3320aa3de8bf8e44552
Author: Jonathan Druart <jonathan.druart at biblibre.com>
Date: Tue Dec 24 14:35:36 2013 +0100
Bug 10453: fix unintended password reset when updating child to adult
ModMember supposes the password given in parameter is the
password string, so if it receives the encrypted password,
it will encrypt it again! By simply deleting the password key
from the hash, ModMember leaves the password unchanged.
Test plan:
1/ Create or choose a child patron
2/ Update it to an adult category using the
"Update child to adult patron" link
3/ Try to log in at the OPAC with this patron: It is not
possible, the password has changed
4/ Apply the patch and try again previous steps
Signed-off-by: Mark Tompsett <mtompset at hotmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83 at web.de>
Confirmed the problem and tested the patch fixes it.
Passes all tests and QA script.
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
(cherry picked from commit 3c5b4712717d082b66376915c47b6b5880695d31)
Signed-off-by: Fridolin SOMERS <fridolin.somers at biblibre.com>
(cherry picked from commit 810168643d02ebb69c2d56a5fa17b811b06d68a8)
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
commit 9cd6cc2b94e24daeb2c140f5da43fcc28c01b99a
Author: Jacek Ablewicz <abl at biblos.pk.edu.pl>
Date: Sat Dec 14 12:07:11 2013 +0100
Bug 9948: fix creation/updating of items when partially receiving an order
Problem summary: when doing partial receives for the given order -
1) if AcqCreateItem is set to 'ordering', various item data (price,
dateaccessioned, replacementprice, replacementpricedate) are getting
erroneously updated on the wrong (yet to be received == not the ones
being currently received) item records
2) if AcqCreateItem is set to 'receiving', newly received
item records are being created without the aforementioned fields
set to the proper values
This (trivial) patch should deal with both cases, hopefully without
breaking enything else.
To test:
- apply the patch,
- create some orders with 2+ quantity
- test partial & non-partial receives for those orders
- ensure the received item records are getting modified
(for AcqCreateItem set to 'ordering') and/or created (for AcqCreateItem
set to 'receiving') correctly for both partial and non-partial receives
- receiving orders with quantity = 1 / receiving orders in non-partial
mode should be still working fine for 1) & 2) scenarios (i.e.,
AcqCreateItem set to 'ordering' / AcqCreateItem set to 'receiving')
Signed-off-by: Nicole C. Engard <nengard at bywatersolutions.com>
Works as I'd expect now! Awesome patch.
Signed-off-by: Kyle M Hall <kyle at bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83 at web.de>
Passes all tests and QA script.
Also: t/db_dependent/Acquisition/
t/db_dependent/Acquisition.t
Created 2 orders with 3 items each for both settings
of AcqCreateItem (on receive, on order) with the patches
applied. No regressions found.
Closed baskets and received shipments for each, with
AcqCreateItem set according to how the order was created.
First recreated the problem without the patches, reloaded
database and confirmed that the patch fixes it.
No problems found.
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
(cherry picked from commit 95e2754af6a2dbd5f042a1c3504488f5de8c8d23)
Signed-off-by: Fridolin SOMERS <fridolin.somers at biblibre.com>
(cherry picked from commit 7f57015aa99c9a99cf5d0715f9c55222941c1c27)
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
-----------------------------------------------------------------------
Summary of changes:
C4/Breeding.pm | 2 +-
acqui/finishreceive.pl | 4 ++--
admin/marc_subfields_structure.pl | 3 ++-
installer/data/mysql/updatedatabase.pl | 7 +++++++
.../prog/en/modules/admin/marc_subfields_structure.tt | 6 +++---
.../prog/en/modules/help/admin/marc_subfields_structure.tt | 2 +-
kohaversion.pl | 2 +-
members/update-child.pl | 1 +
misc/migration_tools/bulkmarcimport.pl | 4 +++-
9 files changed, 21 insertions(+), 10 deletions(-)
hooks/post-receive
--
main Koha release repository
More information about the koha-commits
mailing list