Commit graph

11 commits

Author SHA1 Message Date
7698f6453c Bug 18119: Fix comment in cataloguing.js
Test plan:
Go to cataloging, and try something which depends on javascript -
collapse/uncollapse fields, open authority search window, ...
    -> without patch it is not working
    -> with patch it is working correctly

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2017-02-15 11:18:22 +00:00
e9cd82e4ca Bug 17988: Add a comment to explain the line
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2017-02-14 13:57:01 +00:00
Oleg Vasylenko
317abac238 Bug 17988 - Select2 prevents correct tag expand/minimize functionality
Overview:
Select2 (Bug 13501) introduced divs and inputs that broke some assumptions about the expected HTML structure.
Because of that, expanding fields to show all hidden subfields does not work properly.

Steps to Reproduce:
1. Open some book in the editor or create new (cataloguing/addbiblio.pl)
2. Try to minimize or expand fields, that have among subfields the following:
	— Thesaurus driven subfield → subfield with Select2
	— Hidden subfield.

Actual Results:
 — some fields become hidden, some not, and vice versa
 — in the console, you'll see «Uncaught TypeError: Cannot read property 'match' of null»

Expected Results:
 — all subfields should minimize/maximize completely

Additional Information:
This happens because Select2 adds some divs, that do not have ID property.
The following patch adds check for the needed attribute existance.

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>
2017-02-14 13:57:00 +00:00
87bbe7e18b Bug 17725: Same for textarea when cloning a field
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2017-01-13 11:26:34 +00:00
e12b080a4c Bug 17725: Do not copy subfield's content when cloning
To replicate:
- Open an existing record in your catalog
- Create another field or subfield of a field/subfield already used using the icon to repeat it
- Verify that the content is copied over
- Verify this happens for input (one line) and textare (multiple lines)

I can't make this happen for when creating a new record, but more consistently on editing existing records.

This is rather annoying when cataloguing in Koha, as the cataloguer has to empty the field first and that adds an extra step for each repeated field.

Test plan:
Confirm than the content is not copied when you clone a field or a subfield.

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2017-01-13 11:26:34 +00:00
Patricio Marrone
c7a0272580 Bug 17817: (Follow up) Fix reordering subfields issues
Authority controlled subfields have invisible divs which produced
a strange behavior when reordering (multiple clicks were needed
to push a subfield up over an authority controlled subfield)

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2017-01-13 11:23:00 +00:00
Patricio Marrone
cc26863d35 Bug 17817: Fix cloning subfields using select2
Based on Jonathan's patch (the DO NOT PUSH one), I put together this fix.
What was changed is that select2 is reinitialized only after the cloned element
has been appended to the DOM (so that select2 can correctly calculate the field's
width). Also, I changed the selectors that searched for the line divs (for reordering)
and for the subfield's input element (for erasing the field's value) to be more specific,
since select2 introduced divs that broke some assumptions about the expected HTML structure

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
I confirm that these 2 patches fix the add item and mod biblio views as
well as the batch item modification tools.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2017-01-13 11:23:00 +00:00
Hector Castro
fbe75e66cc Bug 17477: Duplicating a subfield yields an empty subfield tag
The problem only when clone a textareas in 5XX

Steps to reproduce error:
- On the cataloging screen (basic screen), create a new record
- Go to the 5xx fields
- Put something on the 521$a subfield or other textareas (e.g. 520$u or
 583$x)
- Clone the subfield
=> FAIL: The subfield correctly doesn't include the original data,
BUT it doesn't have the subtield tag either.

- Apply patch
- Clean cache browser and reload page
- Repeat steps above
- Verify that works as expected

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2016-10-21 14:12:22 +00:00
Hector Castro
451fd67dd1 Bug 17152: Do not copy value when duplicating a subfield
When cataloguing, if you want to duplicate a subfield that is not
empty, the new subfield is created with a copy of data in it.
This is not the case when you duplicate an whole field. The new one is
created with subfields but without data in it.

Test plan:
Add or edit a bibliographic record
Fill a subfield
Duplicate the subfield
=> Without this patch the value of the input will be copied
=> With this patch the new input will be emptied

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2016-09-08 12:03:13 +00:00
Julian Maurice
8a7a953e5b Bug 13501: Fix behavior of 'Delete subfield' button on select2 controls
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
2016-09-02 16:25:04 +00:00
5e1bcc4aa7 Bug 16242 - Move staff client JavaScript out of language directory
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>
2016-04-29 14:32:42 +00:00
Renamed from koha-tmpl/intranet-tmpl/prog/en/js/cataloging.js (Browse further)