This patch moves the JavaScript files in prog/en/js to prog/js.
JavaScript files do not need to be in the directory which is processed
by the translator.
To test, apply the patch and visit various pages in the staff client to
confirm that JavaScript files are still loading correctly.
Revised: I intended for this to be built on top of Bug 15883 as well as
Bug 16242. Now it is.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
On top of 15883 and 16241
All seems to work, js files pulled from new dir.
No errors
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If you click the plugin next to an authority field that is already
populated it takes the values from the field and puts them in the search
in the reverse order.
Test plan:
1/ Edit a biblio
2/ Fill the subfield for an authority field (for instance 650$v, 650$x,
650$y, etc.)
3/ Click on the authority plugin
Before this patch, the values were concatenated in the reverse order.
With this patch, it should not.
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described, no koha-qa errors
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
A code change for report 10480 in cataloging.js does not work well in case
you clone a field with a plugin on a subfield.
The events (click, focus, etc.) do not work on the subfield of the clone.
This patch corrects the situation by finding the right html element for
adding event binding.
NOTE: The test plan uses EXAMPLE.pl since many old plugins do not operate
on the correct field value when cloning. This is corrected in bug 13437.
Test plan:
[1] Attach EXAMPLE.pl to field 007, 246h and 260c.
In sql for 007: update marc_subfield_structure set
value_builder='EXAMPLE.pl' where tagfield='007' and tagsubfield='@';
[2] Clone field 007. Verify that focus and click operate on both fields.
Check also that the plugin works on the value corresponding with
the button you clicked.
[3] Clone field 246. Do the same checks on both subfields $h.
[4] Clone subfield 260c. Do the same checks again.
Test Remarks:
============
1/ Setup a new framework (B213) based off 'Default' and fired off
an SQL statement to update value_builder values for 007, 246$h
and 269$c (UPDATE `marc_subfield_structure` SET value_builder
= 'EXAMPLE.pl' WHERE frameworkcode = 'B213' AND ( (tagfield =
'007' AND tagsubfield = '@') OR ( tagfield LIKE '246' AND
tagsubfield = 'h') OR (tagfield = '260' AND tagsubfield = 'c'))
2/ Tested step 2, 3 and 4 of the given test plan above. The missing
plugin support in the cloned fields were noted.
3/ Applied patch
4/ Re-tested steps 2, 3 and 4 as before. The defined plugins were
correctly cloned and found to be functional.
Signed-off-by: Indranil Das Gupta (L2C2 Technologies) <indradg@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
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>
The application of the "noEnterSubmit" class to textareas in the
cataloging editor prevents the user from being able to use the Enter key
to create line breaks. This is not intentional and should be corrected.
This patch adds more specific scoping to the relevant JavaScript.
To test, apply the patch and clear your browser cache if necessary. Open
up the MARC editor and locate a tag which uses a textarea for entry. Try
typing lines of text separated by line breaks. The enter key should work
correctly.
Signed-off-by: bondiurbano costalc@gmail.com
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes tests and fixes the problem.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When cataloging a bib record if you scan an ISBN barcode in the barcode
scanner clicks the 'save' button before the cataloging is done. This did
not happen in 3.10, but is happening again in 3.12.
Test Plan:
1) Open the marc editor
2) Focus on a field, hit the enter key
3) Note the record tries to save
4) Focus on an indicator, hit the enter key
5) Note the record tries to save
6) Apply this patch
7) Repeat steps 2 and 4, note the record no longer
tries to save upon carriage return
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Patch tested with a sandbox.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Under certain circumstances, when editing an item, you get a popup
warning
"1 mandatory fields empty (highlighted)".
Even though all mandatory fields are filled in.
This occurs when there is a field with a huge content (more than 100
characters) that gets displayed in a textarea instead of input.
This patch corrects the Javascript form check by using siblings().
Also adds a more precise filter to find mandatory inputs because
looking in full page may bring unwanted results.
Test plan :
- In a framework, make sure you have in item field :
An optional subfield (without authorised value),
then a mandatory subfield, then an optional subfield
next to mandatory subfield
For example : $i (optional), $r (mandatory) and $s (optional)
- Open a biblio record and create a new item
- Enter more than 100 characters in $i, fill $r and $s
- Click "Add item"
- Edit this item
=> You get a textarea for $i
- Empty $s and Save
=> Without patch, you get a warning and form is not saved and you see that $s is yellow while it should be $r
=> With patch, form is saved
- Re-edit this item
- Empty $r and save
=> You get a warning and form is not saved
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Notes on last patch.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
In authorities and biblios editors, a repeatable subfield can be deleted (small icon next to input).
Clone subfields are really deleted but last existing subfield is just set empty instead of deleted.
But when same field is repeated, the last subfield can be deleted.
This patch corrects this, last subfield of a field, even repeated, can not be deleted.
Test plan :
- Edit a biblio
- Choose a repeatable field with a repeatable subfield : ie 600 and $x
- Edit 600, enter a text in $x : ie "subA"
- Clone $x
- Delete second $x
=> second $x is deleted
- Delete first $x
=> $x is not deleted but set empty
- Edit 600, enter a text in $x : ie "subA"
- Clone 600
- Edit second 600, enter a text in $x : ie "subB"
- Clone $x of second 600
- Delete second $x of second 600
=> second $x of second 600 is deleted
- Delete first $x of second 600
=> with this patch : first $x of second 600 is set empty
=> without this patch : first $x of second 600 is deleted, second 600 has no $x anymore
Perform same test plan on an authority.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Passed-QA-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Passed-QA-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Passed-QA-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Passed-QA-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
