[koha-commits] main Koha release repository branch 3.12.x updated. v3.12.02-9-gdf765f8
Git repo owner
gitmaster at git.koha-community.org
Thu Jul 25 17:00:01 CEST 2013
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 df765f82b3b96e9bf4e883450d1e3260cce01dfd (commit)
via fdf6c3790a8e942be8a3615252b6c214064dd21e (commit)
via dfbb9890d970f3f70cb6eb02275679d65101489a (commit)
via f05642589d94c25ef1b1f01b4a2606fe455400b8 (commit)
via 926e455f19852c1c7b69aa00bd587caff8bccd14 (commit)
via a777f2e6b7748a1cb417a38aa078e9f1bf7246b3 (commit)
via 98e397d9a5c5cbd3d2aa88cd0044c24a7d75ff72 (commit)
via 9886445eb8e82788167ec2440dfeddf0a6b3b58d (commit)
via 606a25bc41047291e4b11390b97caf5d9f01ae65 (commit)
from 97df2e8dad354d6b6c54a16eacdb72c5ad96edd8 (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 df765f82b3b96e9bf4e883450d1e3260cce01dfd
Author: Mathieu Saby <mathieu.saby at univ-rennes2.fr>
Date: Fri May 3 23:07:37 2013 +0200
Bug 10189: Translate values in UNIMARC 128b/c cataloguing plugins to English
Cataloguing plugins for UNIMARC 128b and 128c fields are only in Ffrench.
This patch translates them.
Source : http://blue.lins.fju.edu.tw/mao/marc/unicon.htm
Note : 128b and 128c are deprecated in last version of UNIMARC Manual (field 145 used instread).
But they are still used in French Sudoc network.
To test : in a UNIMARC english Koha, edit a record and use 128b and 128c
cataloguing plugins. Check everything is in english.
Signed-off-by: Chris Cormack <chris at bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83 at web.de>
Thx for translating those!
Verified new strings get parsed into the po files.
Templates still contain lots of tabs, those can be fixed separately.
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
(cherry picked from commit 80ea8bf821ba83fd4506f5298f5a582051b44e06)
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
commit fdf6c3790a8e942be8a3615252b6c214064dd21e
Author: Galen Charlton <gmc at esilibrary.com>
Date: Sun Jun 16 18:05:31 2013 -0700
Bug 10258: offer to create basket group only when staff user has correct permission
If the staff user does not have the group_manage acquisition permission,
do not offer to create a new basket group when closing an order basket.
This avoids a situation where if a staff member without that permission tries
to close a basket and chose the option to create a bakset group, they would
be redirected to the login page.
To test:
[1] Log in as a staff user that does not have
the acquisition/group_manage permission.
[2] Create a new order basket, attach at least one
order line to it, then close it.
[3] Verify that the confirmation page does not
offer to create a basket group with the
same name as the order basket.
[4] Log in as a staff user that has the
acquisition/group_manage permission.
[5] Create and close an order basket.
[6] Verify that this time, the confirmation page
*does* offer to create a basket group.
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
Signed-off-by: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
(cherry picked from commit 14a1bd0e420fd895f989ba88e0cad927697b6173)
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
commit dfbb9890d970f3f70cb6eb02275679d65101489a
Author: Galen Charlton <gmc at esilibrary.com>
Date: Thu Jun 13 08:53:49 2013 -0700
Bug 10258: fix permissions check for setting basket group for order basket
Improve the code that displays and allows staff to
set the basket group from the basket details page
for a closed basket.
Prior to this patch, a staff member who did not
have the group_manage acquisition permission would
still see a control to change the group that the
basket belongs to; attempting to change the group
would present with with a login page.
This patch also does some tidying of how basket group
details are passed to the template.
To test:
[1] Create an order basket and close it. Do
not assign it to a basket group.
[2] View the basket details while logged in as
a staff user who has the order_manage acquisitions
permission but not the group_manage. The
displayed basket group should be "No group".
[3] Switch to a staff user who also has the
group_manage permission, then view the basket
details again. The basket group field should
now be a select input that allows you to change
the basket group.
[4] Change the basket group. Verify that the basket group
you selected is now displayed as the current group
for that order basket. The basket group delivery and
billing place fields should also now be displayed.
[5] Close the basket group set in the previous step, then
view the basket details again. This time, the basket
group name should be displayed with a suffix of " (closed)",
and no input to change the group should be displayed.
[6] Swith to a staff user who does not have the group_manage
permission, view the basket details, and verify that
the basket name is displayed with a suffix of " (closed)".
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
Signed-off-by: Marcel de Rooy <m.de.rooy at rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
(cherry picked from commit 44364db8d53bf5e3135ae2de6270a920e5c053c1)
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
commit f05642589d94c25ef1b1f01b4a2606fe455400b8
Author: Jason Etheridge <jason at esilibrary.com>
Date: Fri Mar 8 10:41:06 2013 -0500
Bug 9770: fix sorting of Dewey call numbers that contain prefixes
C4::ClassSortRoutine::Dewey can pad the wrong part of a call number internally.
The subroutine get_class_sort_key tokenizes a call number string (splitting on
periods and whitespace) and counts the number of tokens that solely contain
digits. If there is only one such digit group, a comment in the code states
that it will pad said digit group. However, the bug is that the code assumes
said digit group is the first token, when this may not be the case.
In practice, this can cause poor sorting when used a call number is in the form
of PREFIX _space_ 3DIGITS.
To test:
[1] Create two item records whose class scheme is set to
'ddc' (Dewey) and whose call numbers contain prefixes, e.g.,
J DVD 700.1 ABC and J DVD 850 DEF.
[2] Use the inventory tool to produce a list of item items that include
the two created in step 1. Obsere that that items are sorted
in the incorrect order, with "J DVD 850 DEF" coming before
"J DVD 700.1 ABC". Alternatively, run the following SQL
to see the incorrect sort order:
SELECT cn_sort, itemcallnumber
FROM items
WHERE itemcallnumber LIKE 'J DVD%'
ORDER BY cn_sort;
[4] Apply this patch.
[5] Run misc/maintenance/touch_all_items.pl to force cn_sort to be
recalculated.
[6] Repeat step 2 and verify that the call numbers are now sorted
corrected.
Signed-off-by: Jason Etheridge <jason at esilibrary.com>
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
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 dba36a7a1216238a260ea5fbe2218627487e9f19)
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
commit 926e455f19852c1c7b69aa00bd587caff8bccd14
Author: Jason Etheridge <jason at esilibrary.com>
Date: Fri Jun 21 15:31:32 2013 -0400
Bug 9770: test case for sorting of Dewey call numbers that contain prefixes
This adds a test for C4::ClassSortRoutine::Dewey to check that the
call number "JR DVD 800.1" sorts before "JR DVD 900"
To test:
[1] Apply just this patch.
[1] Run prove -v t/ClassSortRoutine_Dewey.t
[2] Test #7 should fail.
Signed-off-by: Jason Etheridge <jason at esilibrary.com>
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
Signed-off-by: Chris Cormack <chrisc at catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83 at web.de>
Passes test plan and QA script.
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
(cherry picked from commit bce45b4bf55e82345efed2850d9cb5fd77f3c483)
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
commit a777f2e6b7748a1cb417a38aa078e9f1bf7246b3
Author: Chris Hall <chrish at catalyst.net.nz>
Date: Fri Mar 22 15:33:50 2013 +1300
bug 10356: improve display of serial issue dates in staff bib details page
This patch adds the date published to the subscriptions tab in the staff
interface bib display and renames the former "Date" column to
"Date arrived".
Signed-off-by: Kyle M Hall <kyle at bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart at biblibre.com>
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
(cherry picked from commit 97bbf04757227f2a26a6f5b1b216d2bab8efbdc9)
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
Good and simple usability improvement. Works as expected.
commit 98e397d9a5c5cbd3d2aa88cd0044c24a7d75ff72
Author: David Cook <dcook at prosentient.com.au>
Date: Wed Jun 12 11:24:09 2013 +1000
Bug 10448: can now change framework after duplicating bib record
Changing the framework in the MARC editor immediately after duplicating
a bib record no longer clears the fields.
This patch changes the Changefwk Javascript function so that it passes
the "op" value and the "biblionumberdata" (as the biblionumber) from
addbiblio.pl back to itself, when submitting the form in order to
change the framework.
The reason we need to do this is because the form in addbiblio.tt
is hard-coded to always submit an "op" value of "addbiblio". Currently,
we need to have it hard-coded to "addbiblio", because all the magic
happens in addbiblio.pl when there is an "op" of "addbiblio". If we
always passed the "actual" "op" value, such as "duplicate", nothing
would ever happen when we clicked "save". It seems to me that this
is a flaw in the design of addbiblio.pl.
If we pass the "op" and "biblionumber" when changing frameworks, we're
able to tell addbiblio.pl that we're still wanting to "duplicate" this
"X" biblionumber. However, by having the form still hard-coded to
"addbiblio", when we hit save, the form will do the magic, check if
it's a duplicate, and save the record (or prompt for action if it
is a duplicate).
--
I also noticed that if you make changes to a record, then change
the framework before saving, your changes get cleared (since the
original record from the database is loaded when the page reloads).
It seems to me that this is a bug. Changing the framework should
change the layout while preserving the content. I think most users
would assume that when changing the framework.
This patch also introduces another hidden input into addbiblio.tt and
the Changefwk Javascript called "changed_framework". Basically, if
the Changefwk Javascript is run, it tells addbiblio.pl that the
framework is changed, and it uses the posted data from the form
(which we have been modifying) instead of reloading the record from
the database.
--
Test Plan:
A) Before Applying Patch:
To Show That Changing the Framework Erases All Fields When
Duplicating a Record:
1) Go to any bib record
2) Go to Edit > Edit as new (duplicate). You should see filled
in fields.
3) Change the framework to any other framework than the one
that is currently specified.
4) Note that every single field is now blank
To Show That Changing the Record then Changing the Framework
Ignores Changes, When Editing a Record
5) Go to any bib record
6) Go to Edit.
7) Change the title of the record to "I've changed the title".
8) Change the framework to any other framework than the one that is currently specified.
9) Look at the title. You'll notice it is the original title, and NOT "I've changed the title".
B) Apply the Patch
Also, clear your memcache and shift+refresh your screen. You don't want to use cached templates/javascript.
C) After Applying the Patch
Repeat Steps 1-3 and 5-8.
You should now notice that changing the framework when duplicating the item does not clear all the fields.
You should also notice that any changes you make prior to changing the framework will still exist after changing it.
Signed-off-by: Kyle M Hall <kyle at bywatersolutions.com>
Signed-off-by: Chris Cormack <chris at bigballofwax.co.nz>
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
(cherry picked from commit ca33b7fc635d93b3029831da7496372fb34c798f)
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
Works as expected.
commit 9886445eb8e82788167ec2440dfeddf0a6b3b58d
Author: Chris Cormack <chris at bigballofwax.co.nz>
Date: Sun Jul 7 20:38:55 2013 +1200
Bug 7143: Updating history and about page
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
(cherry picked from commit d647090a4ab9b53577c1959dcdb0642a29fcbe6d)
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
commit 606a25bc41047291e4b11390b97caf5d9f01ae65
Author: Owen Leonard <oleonard at myacpl.org>
Date: Thu Jul 11 10:28:55 2013 -0400
Bug 10514: improve visibility of Add item link on new order form
This patch converts the "Add" and "Clear" links
to the standard "submit/cancel" format inside a fieldset. This gives
them a little more visual weight.
Based on the changes made by Liz Rea and Jonathan Druart.
To test:
- create a basket
- add a record to it
- scroll down - the link to add item and cancel should both be more
prominent now.
- Click "Add item" - it should add an item.
Signed-off-by: Liz Rea <liz at catalyst.net.nz>
I still feel weird about the button, but as two people have said they'd rather have the button, I'm alright with it I guess.
Really what I want is people to notice it's there and click it at the appropriate time. I hope this will help that issue.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83 at web.de>
Passes all tests and QA script.
Leaves the translation problems, but that needs more work and is
out of the scope of this bug.
Tested Add and Update functionality works correctly.
Signed-off-by: Galen Charlton <gmc at esilibrary.com>
(cherry picked from commit 275f405c8b3920634907e5e1f2ef8ccecf497868)
Signed-off-by: Tomas Cohen Arazi <tomascohen at gmail.com>
-----------------------------------------------------------------------
Summary of changes:
C4/ClassSortRoutine/Dewey.pm | 6 +-
C4/Serials.pm | 3 +-
acqui/basket.pl | 14 +-
cataloguing/addbiblio.pl | 6 +-
docs/history.txt | 12 +
koha-tmpl/intranet-tmpl/prog/en/js/additem.js | 15 +-
koha-tmpl/intranet-tmpl/prog/en/modules/about.tt | 2 +
.../intranet-tmpl/prog/en/modules/acqui/basket.tt | 18 +-
.../prog/en/modules/catalogue/detail.tt | 4 +-
.../prog/en/modules/cataloguing/addbiblio.tt | 5 +-
.../value_builder/unimarc_field_128b.tt | 290 ++++++++++----------
.../value_builder/unimarc_field_128c.tt | 287 ++++++++++----------
t/ClassSortRoutine_Dewey.t | 6 +-
13 files changed, 354 insertions(+), 314 deletions(-)
hooks/post-receive
--
main Koha release repository
More information about the koha-commits
mailing list