Those calls to C4::Items::GetBarcodeFromItemnumber can be replaced with
my $barcode = Koha::Items->find($itemnumber)->barcode;
But if we are not sure that the item exists, we should test the return
of ->find before ->barcode
Test plan:
- Edit an item
- Check an item in
- Test SIP - I do not really know how to trigger that code, apparently
misc/sip_cli_emulator.pl does not deal with holds. Any ideas?
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The code assumed that if a subfield is marked as mandatory, there should be no
empty entry in the pull downs.
This assumption is not correct, as it leads to the first entry of the
pull down being preselected if there is no default set. Which means you
will never be alerted of any cataloguing errors and errors will be very
hard to find later on.
Correct behaviour would be to preselect the empty value when there is
no default. This means on saving the item an error message is triggered
and the cataloger is forced to set the value.
To test:
- Adapt your frameworks:
- Make 942$c non-mandatory
- In 952 make itemtype, classification source and some other pull downs
like location or collection mandatory
- Add a new item
- Verify that the first value of each pull down is preselected,
there is no way to trigger the 'required' error
- Apply patch
- Add a new item
- Verify that classification source is preselected according to the
DefaultClassificationSource system preference
- Verify that the itemtype is preselected according to 942$c in
the bibliographic record
- Verify all mandatory fields can be set to empty
- Verify that you can't save before correctly setting them
- Change the 942$c in the record to empty
- Add another item
- Verify the itemtype is now empty
- Change your frameworks and set a default for itemtype (Ex: BK)
- Repeat default check with another pull down like collection or location
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We do not want empty values for branches (holdingbranch and homebranch
must be mandatory, see bug 21011)
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
There is a "max length" value you can define at framework level to
limit the size of the input. But it is not taken into account on the
add/edit item form.
It is a regression that has been introduced by
commit 47d2de9c02
Bug 12176: Remove HTML from additem.pl
max_length vs maxlength
Test plan:
- Define a maximum length for an item subfield
- Add or edit an item
=> Without this patch the maxlength attribute of the inputs are not
defined (maxlength="")
=> With this fix you will see the maxlength attributes correctly set
with the value you defined in the framework
Note:
We could/should set this value to the size of the DB column when mapped
For instance 952$u is mapped with items.uri, which is a varchar(255).
This length restriction should done at framework level
Signed-off-by: Pierre-Luc Lapointe <pierreluc.lapointe@inLibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
If you do not use the EasyAnalyticalRecords feature (introduced with
bug 5528), you will have a lot of warnings in zebra-output.log like:
zebrasrv(1096) [request] Search biblios ERROR 114 1 1+0 RPN @attrset Bib-1 @attr 1=8911 259186
They come from C4::Items::GetAnalyticsCount called by catalogue/detail.pl.
This sub starts a Zebra search on index 'hi' (Host-Item-Number).
If you do not use this field at all (related to 773$9 in MARC21), Zebra
returns an Unsupported Use attribute error (114).
In making this change, I added one minor change:
[1] Remove the commented GetAnalyticsCount in additem.pl and correcting
indentation in that loop (removing tabs). So no change at all there.
NOTE: I will propose to bind the GetHostItemsInfo call in detail.pl and two
other scripts to this preference too on report 20702.
Test plan:
[1] If you use EasyAnalytics, verify that there is no change.
[2] If you do not, check the zebra-output.log. You should no longer see
searches for Host-Item-Number with 1=8911. (As well as ERROR 114 on
this index.)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Charles Farmer <charles.farmer@inLibro.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
'my' creates a new '$value' variable, and prevented the '$value' in
outer scope to be modified
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Given the confusion regarding this behaviour it sounds better to make it
configurable.
This pref will take 4 different values, 1 per place an item can be
marked as lost.
Test plan:
Mark items as lost and confirm the item is returned or not, depending on
the value of the system preference.
- from the longoverdue cronjob (--mark-returned takes precedence if set)
- from the batch item modification tool
- when cataloguing an item
- from the items tab of the catalog module
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If an error is raised for the barcode, we should not try to perform the
lost logic succeeding it.
Futhermore there is no need to go to GetMarcFromKohaField etc. if we just
use the output of ModItemFromMarc.
Note: It seems unnecessary to clear $itemnumber, but I can understand
the anxiety about passing it to the template with op=additem. So just
leaving it here.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
TEST PLAN:
1) Log in with your superlibrarian account
2) Borrow any book
3) Visit your Checkouts page, and click 'Show Checkouts'
4) Click on the item's barcode to visit the item's page
5) On the item's page, click the 'Edit' button, and choose 'Edit items'
6) In the items table, click the 'Actions->Edit' button of the item you borrowed
7) Mark that item as lost (it should be the first row of the form) and click the button 'Save changes'
8) Visit your Checkouts page. The item should still be there, despite BZ12363 claiming it should've been automagically returned
8.1) Your koha-log should also output a warning message: 'DBIx::Class::Storage::DBI::select_single(): Query returned more than one row...'
8.2) If you visit the item's page, the modification had no effect. It should not be marked as lost.
9) APPLY PATCH
10) Start back from step 2), but this time, after marking the item as lost, the item's page should
reflect the change, and the item you borrowed should've been automatically returned to the library
Signed-off-by: Jean-Manuel Broust <jean-manuel.broust@univ-lyon2.fr>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Amended: Using $item->{itemnumber} instead of new variable.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There are several ways to mark an item an lost:
- item list view (catalogue/moredetail.pl, "Items" tab)
- cataloguing (cataloguing/additem.pl)
- Batch item modification tools (tools/batchMod.pl)
- The long overdue cronjob (misc/cronjobs/longoverdue.pl)
So far only the cronjob is configurable, the others mark the item as
returned (does the checkin).
This behaviour should be controlable using a syspref, to let libraries
choose what fit best for them.
Test plan:
Use the 2 options of the pref, mark checked out items as lost using the
different possibilities, and confirm that the behaviours make sense to
you
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Bug 7673 introduced SubfieldsToAllowForRestrictedEditing but bug 12176
broke it assuming that only selects were impacted by this feature.
Test plan:
Go back on bug 7673 and confirm that
SubfieldsToAllowForRestrictedEditing is working as expected with this
patch applied.
Signed-off-by: Lee Jamison <ldjamison@marywood.edu>
For clarification, the item fields that are entered in
SubfieldsToAllowForRestrictedEditing should EXCLUDE the desired
fields you want to disable.
Test plan (updated to test the scenario in the bug Description):
1. Create a patron with only the following permissions:
- catalogue (Required for staff login)
- editcatalogue -> edit_catalogue
- editcatalogue -> edit_items
- editcatalogue -> edit_items_restricted
2. Navigate to Administration -> Global system preferences -> Cataloging
-> Record Structure -> SubfieldsToAllowForRestrictedEditing
3. In the input field for SubfieldsToAllowForRestrictedEditing enter in
all the 952 fields EXCEPT the ones desired to be disabled. In this
case, we want to disallow editing of 952$2, 952$a, 952$b, 952$e, 952$h,
and 952$o so we enter the following into the
SubfieldsToAllowForRestrictedEditing (without quotes) "952$0 952$1
952$3 952$4 952$5 952$7 952$8 952$c 952$d 952$f 952$g 952$i 952$j
952$p 952$t 952$u 952$v 952$w 952$x 952$y 952$z"
4. Click Save all Cataloging preferences
5. Login to the staff client as the created restricted editing patron
6. Edit an item
7. Note that all fields except for the ones excluded from the syspref
are editable
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Change parameters to a hashref.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Looks good to me.
Two calls in migration_tools/22_to_30 still in old style.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
GetMember returned a patron given a borrowernumber, cardnumber or
userid.
All of these 3 attributes are defined as a unique key at the DB level
and so we can use Koha::Patrons->find to replace this subroutine.
Additionaly GetMember set category_type and description.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To retrieve a biblionumber from an itemnumber, we can use:
Koha::Item->biblio->biblionumber
This is only what this patchset does.
Doing that we will be able to get rid of the
C4::Biblio::GetBiblionumberFromItemnumber subroutine.
Test plan:
- Acquisition module: cancel a receipt
- Export a record to CSV
- Modify items in a batch
Item's info should be correct
Other changes with be checked by QA team, by reading the code.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The code from additem to delete all the items of a bibliographic record
is very ackward.
This patch simplifies the algorithm and make the code more readable.
Test plan:
Remove all the items of a bibliographic records
If at least 1 item is checked out you should get an error.
No change with the current behavior is expected.
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Updating to use they/them and skipping the ones changed to it
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comments throughout the Koha codebase assume that
all librarians or borrowers are male by using the
pronoun 'he' universally. This patch changes to
'he or she' / 'him or hers'.
Testing plan:
- ensuring modifying tests still pass:
+ C4/SIP/t/06patron_enable.t
+ t/db_dependent/Circulation.t
+ t/db_dependent/Koha/Patrons.t
+ t/db_dependent/Reserves.t
Sponsored-By: California College of the Arts
No code changes detected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Lari Taskula <lari.taskula@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch also fixes a typo ("<<MM><" should be "<<MM>>")
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
When adding a biblio, the default value of a MARC subfield defined in
the frameworks can be used as placeholders to set the current date or
the surname of the logged in user (use cases?).
The different placeholders are 'YYYY', 'MM', 'DD', 'user'.
When adding an item, same behavior except that 'user' is not replaced.
This patch makes behaviors consistent between the 2 editors and
surrounds placeholders with << >>
We will now have: <<YYYY>>, <<MM>>, <<DD>> and <<USER>>
Test plan:
Define default values for biblio and item subfields.
Create a bibliographic record and attach it an item.
The default values should be used and replaced if you used placeholders.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Remove $dbh as argument to C4::Items::DelItemCheck
and C4::Items::ItemSafeToDelete, also change all
calls to these functions throughout the codebase.
Also remove remaining reference to 'do_not_commit' in
t/db_dependent/Items_DelItemCheck.t
Fixed doubled "$$" in C4/ImportBatch.pm
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
No idea how to replicate this issue but we have been getting several reports
about the following error:
Software error:
Corrupted storable string (binary v2.9) at /usr/lib/perl/5.18/Storable.pm line
417, at /home/koha/kohaclone/cataloguing/additem.pl line 375.
TEST PLAN:
1. Add or modify an Item.
2. No observed changes.
?. We don't know what causes this but we know that add/modify Item occasionally
crashes due to failure of a cookie thawing.
This patch prevents the whole program from dying, because this error is not
critical enough to warrant dying.
Also there is no centralized mechanism in Koha for showing messages to the
user, so there is no easy and convenient way to warn the user that the:
'LastCreatedItem'-cookie or the systempreference 'PrefillItem' is
malfunctioning.
So we instead just warn to the server logs with the malfunctioning cookie in
hopes of nailing down what causes the issues.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch replaces the occurrences of
my @foo = $cgi->param('foo');
with
my @foo = $cgi->multi_param('foo');
perl -p -i -e
's/^(\s*my\s*@\w+\s*=\s*)\$(cgi|input|query)\->param\(/$1\$$2\->multi_param\(/xms'
**/*.pl
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
subroutines should not take $dbh in parameter.
C4::Biblio::TransformMarcToKoha has it and does not use it.
Test plan:
Look at the patch and confirm that all occurrences of
TransformMarcToKoha have been modified.
Signed-off-by: Jacek Ablewicz <abl@biblos.pk.edu.pl>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
The commit b5ecefd485
Date: Mon Feb 3 18:46:00 2003 +0000
had a funny description:
Added function to check if a MARC subfield name is "koha-internal"
(instead of checking it for 'lib' and 'tag' everywhere); temporarily
added to Koha.pm
"Temporarily", since 2003, everything is relative, isn't it? :)
The thing is that GetMarcStructure returns hash like
field_200 => {
subfield_a => {
%attributes_of_subfield_a
},
%attributes_of_field_200
}
The attributes for field_200 can be 'repeatable', 'mandatory', 'tag', 'lib'.
We don't want to loop on these values when looping on subfields.
Since there are just { k => v } with v is a scalar (string), it's easier
to test if we are processing a subfield testing the reference.
At some places, we don't need to test that, we are looping on values
from MARC::Field->subfields which are always valid subfields.
Test plan:
1/ Edit items using the batch item mod tool
2/ display and edit items via the cataloguing module.
You should not see any changes between before and after the patch
applied.
Tech notes:
We need to check what we are processing when we loop on 'subfields' from
GetMarcStructure, not from MARC::Field->subfields.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
This patch adds a link to duplicate existing items on the edit items screen
To test:
1 - Apply patch
2 - navigate to the edit items screen for a record with existing items
3 - click the duplicate link and ensure item info but not barcode are carried over
4 - save the item and ensure it is added correctly
5 - check that all previous functionality on page works as before
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test plan:
1/ update the Schema (misc/devel/update_dbix_class_files.pl)
2/ Translate templates for some languages (es-DE, de-DE for instance)
3/ Enable them in the pref (search for 'lang') for the staff interface
4/ Go on the item type admin page (admin/itemtypes.pl)
5/ Edit one
6/ Click on the 'translate for other languages' link
7/ You are now on the interface to translate the item type's description
in the languages you want. So translate some :)
8/ Go back on the item type list view (admin/itemtypes.pl)
9/ You should see the original description (non translated)
10/ Switch the language
11/ You should see the translated description in the correct language.
If the description is non translated, the original description is
displayed.
12/ On the different page where the item type is displayed, confirm that
the translated description appears.
Think further / Todo:
1/ Update all occurrences of the item type's description (DONE)
2/ Implement for authorised values
3/ Implement for syspref value (at least textarea)
4/ Implement for branch names
5/ Centralize all the translation on a single page in the admin area
...
N/ Implement a webservice to centralize all the translations and give
the ability to sync the item types/authorised values description with
the rest of the world (push and pull).
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch makes YYYY MM and DD display correctly.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch removes C4::Dates from cataloguing/additem.pl
To test:
- In MARC bibliographic framework, define a default value
for one of the in Tag 952 Subfield struture, e.g. for
subfield x Non-public note. You can define it under
'Advancde constraints'. Define the value similar to the following:
Year:YYYY Month:MM Day:DD
- Create a new item for a biblio and verify that YYYY, MM and DD are
replaced with today's values.
- Apply patch and repeat that previous step behaves as before.
- Verify that the overall functionality of the form is the same
as before applying the patch.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as advertised. With the last script not accept more than YYYYMMDD
If you enter something else, the script sends to the end of line.
This patch follow up the pattern in constraint default value
Patch amended following comment #6 / mv
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds the table of items on additem.pl to the columns
customizer.
Test plan:
1. Open item editor on a record, and verify that all columns are visible.
2. Apply patch.
3. Reload editor, and verify that column visibility hasn't changed.
4. Open "Hide/show columns," and verify that you can add and remove
columns.
5. Change the visibility and togglability of some columns in
columns_settings.pl, and verify that these correctly apply to
additem.pl.
NOTE: The columns that are configurable are selected from the non-hidden
columns that have mappings to MARC subfields in the default MARC21
framework (and can thus be displayed in the item editor).
Signed-off-by: Jenny Schmidt <jschmidt@switchinc.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
As Jonathan Druart discovered, we were still missing an important attribute
in the selects. Var mv.name was not filled, so the name was empty with nice
side-effects :)
While fixing this, it was also possible to delete some unused vars that Bernardo
already mentioned before: $attributes and $attributes_no_value.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
For me the simptom was different, when saving an edited item
fields were mangled beyond repear :(
No alert for empty mandatory fields.
But this last patch fix the problem.
Tested add/edit items
Cleaner pl file :)
No errors
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Adjusting a few small things and making qa tools happy:
[1] Remove .hidden after [% avalue %] in additem.tt. (Typo)
[2] A closer look revealed that mv.avalue is useless too. An input element
does not contain any content. Putting it after the hidden element
in a non-visible context has no meaning.
[3] Change handling of select attributes readonly and disabled.
[4] Remove unused variable $attributes_no_value_textarea
[5] Removed a comment with TODO referring to this report.
[6] Moving a duplicated TT variable (mv.javascript) outside IF statement.
[7] And finally could not resist this one: Moving strings Tag editor and
No popup from script to template. Plugins++
NOTE: Most item plugins redirect click to focus. In that case there is
no popup, but unfortunately the text Tag editor comes up.
When you remove or rename function Click, No popup comes up. So it works.
Sorry that this small list kept growing :)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch removes HTML code from additem.pl.
To test:
1. Check no regressions on Add/Edit/Save items
2. Update translation files for a language,
check new strings "Tag editor" & "No popup" on staff PO file
3. Check it passes xt/tt_valid.t
Patch partially rebased, part rewritten.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
http://bugs.koha-community.org/show_bug.cgi?id=9987
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch implements the use of Koha::FrameworkPlugin in Cataloguing,
Authorities, Acquisition, Serials and Tools.
The main change is architectural: see the commit message of the previous
patch. No changes in behavior are expected, but the support of new events
may provide additional functionality in the future. Some small bugs are
resolved along the way.
The change primarily focuses on the MARC and items editor in Cataloguing.
But the MARC editor for Authorities and the item editor in Acquisition,
Serials and Tools are touched too. This commit message gives some comments
per module.
NOTE FOR CATALOGUING:
A new plugin without popup (or other click event code) now shows the title
No popup when hovering over the tag editor image. The image alerts the
user on a plugin, the title tells about its status. The noclick property
allows for further style modifications in the template. Note that a
follow-up patch will clean up the old style plugins too with the same
effect.
Some additional code in cataloging.js makes it possible to clone subfields
with plugins (although only theoretically useful). The clones use the
same javascript functions but event.data contains an updated id.
This effectively resolves bug 13306. Note that if old plugins do not use
the javascript parameter for the id but the perl variable, cloning does
still operate on the wrong field (with and without this patch set).
In the absence of report 12176 in master, it is not yet necessary to modify
additem.tt. When it gets pushed, it should be an easy rebase.
New style item plugins will no longer need an extra parameter. (The code in
the FrameworkPlugin object actually takes care of that.)
NOTE FOR AUTHORITIES:
This patch also adds class name tag_editor to the buttonDot anchors. This
effectively makes the same tag editor image appear as in Cataloguing.
Futhermore it removes the button from the tab sequence if there is no click
event (really effective after conversion to the new style, since the old
style plugins contain empty onclicks and launchers).
Both small adjustments increase consistency between auth and bib edits.
NOTE FOR ACQUISITION:
In Acquisition two scripts use an item editor, but in a different way.
The scripts addorderiso2709 and neworderempty both rely on the routine
PrepareItemrecordDisplay in C4::Items, but neworderempty creates item
blocks dynamically via an ajax call to services/itemrecorddisplay.pl.
In order to make the dynamic item blocks work with plugins, some code
changes were needed in additem.js. (Normally the event binding is done
at document ready time; now it must be done later.)
At this moment the routine in Items.pm contains the html tags, and this
makes changes to the following templates not necessary for now:
* acqui/addorderiso2709.tt
* services/itemrecorddisplay.tt
Report 13397 has been opened to address moving the html to the templates.
NOTE FOR SERIALS:
Script serial-edit relies also on C4::Items (just as in Acquisition).
This makes changes to serials/serials-edit.tt not necessary for now.
NOTE FOR TOOLS:
The current code in tools/batchMod.pl allows the use of plugins for batch
modification of items. This patch just converts that code to use the new
object. Most item plugins however may not be very useful for operating on
multiple items at once.
PERFORMANCE:
I have benchmarked build_tabs in addbiblio to see how especially the
additional processing of the javascript in the FrameworkPlugin object
would impact performance. Testing default MARC21 framework with 8 plugins
gave the following figures:
- Old situation: 851 ms
- New situation: 942 ms (+10,7%)
- New situation after plugin cleanup: 881 ms (+3,4%)
Note also that adding lines for event binding is compensated by removing
lines for unused events. Page load should essentially be the same.
TEST PLAN:
Suggestion: If you also apply the next patch with the EXAMPLE plugin, you
can test with a rather harmless plugin (with popup) on various places :)
But your test should also include old style plugins, with[out] popups.
If you want to test a new plugin without popup, rename/remove Click$id
in the javascript code of the $builder definition (temporarily).
[1] Test Cataloguing:
- Add/Edit biblio. Try plugins with and without popup.
- Add/Edit items. (EXAMPLE can be used as an item plugin with popup.)
- Clone a subfield with plugin (use EXAMPLE): Verify that the plugin
works on both original and clone with the respective field values.
Is the value put back in the right field too?
[2] Test Authorities:
Edit an authority record. Try plugins with an without popup.
[3] Test Acquisition:
Set system preference AcqCreateItem to "placing an order".
Check the item editor in the following two places:
a- addorderiso2709: Open a basket, add an order from a staged file.
Select a file, click Add orders, and go to tab Item information.
b- neworderempty: Open a basket, add an order from a new empty record.
[4] Test Serials:
Check the item editor on serials-edit. Go to subscription detail.
Click Receive. Choose "Click to add item". (Note that this subscription
should create an item record when receiving this serial.)
[5] Test Tools:
Check the item editor for batch item modification. Enter a few valid
barcodes and press Continue to reach the item editor.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
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>
If you uncheck the checkbox OPAC in the bibliographic framework
definition for an item subfield that is linked to an authorized
value list, the pull down will disappear from the item edit
form on staff. The label still shows.
1) Go to administration > bibliographic frameworks
2) Select a framework and go to the item field (MARC21: 952)
3) Edit a subfield with an authorized values list like damaged,
lost or withdrawn
4) Uncheck the checkbox for OPAC visibility
5) Edit or add an item within your chosen framework
6) Verify the subfield code and description are shown, but the
pull down has disappeared
7) Apply patch, verify the pull down shows now
8) Also test following hidden combination works correctly:
OPAC: checked
All other options: unchecked
Documentation of hidden values:
http://wiki.koha-community.org/wiki/Hidden_values
With special thanks to Jonathan Druart for helping me figure this out!
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The title method of MARC::Record does not deal with UNIMARC, it should
not be called if the marc flavour is UNIMARC.
Test plan:
On an unimarc installation, edit a notice, with this patch you should
see
"Editing TITLE (Record number BIBLIONUMBER)"
Without, the title was not displayed.
Same in the breadcrumbs.
Bug 13635: Remove another useless call
There is another call to the title method in additem.pl without any
check on the marc flavour.
But here the title variable sent to the template is redefined 3 lines
later.
So it can be simply removed.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Tested on UNIMARC install, editing a 'record' (not notice) does not show
title on breadcrumbs, status bar or page title.
With patch it does!
No koha-qa errors.
Signed-off-by: joel aloi <aloi54@live.fr>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To reproduce, edit, index notice with utf-8 char and search for it
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Dobrica Pavlinusic <dpavlin@rot13.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
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>
If the sysprefs are empty, we assume that the librarian can edit all
subfields, even if s/he has the restricted permission.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
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>
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>
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>
