[Bug 39292] New: Editing subfield tags in bib editor allows contradiction of framework setup
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39292 Bug ID: 39292 Summary: Editing subfield tags in bib editor allows contradiction of framework setup Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs@lists.koha-community.org Reporter: andrew@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org CC: m.de.rooy@rijksmuseum.nl When editing a biblio via the basic editor, one can accomplish edits that should be prevented by framework configuration. To recreate: - have a record in the Default framework that already has a 100$a value - Confirm your framework defines the 100$a as non-repeatable - edit the record --- don't change the existing 100$a --- edit the subfield tag on a different 100 subfield, set it to $a, enter a value for the field - save your record - you get no error, your record now contains 2 100$a tags Further: - enable RequireChoosingExistingAuthority - confirm you cannot edit an existing 100$a without using the authority picker - take some other 100 subfield, edit its tag to be $a, put whatever you want in that field and save - Koha saves your non-authority author without issue It's worth noting I tried to save a 100$s, which is not defined in my framework. That data was not saved and I received no error message about it. I've confirmed this behavior in Main, 24.11, and 23.05. 24.11 and later versions have made it more obvious that one can edit these subfield tags, but the issue I've described here existed in 23.05. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39292 Michelle Spinney <mspinney@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mspinney@clamsnet.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39292 Jason Robb <jrobb@sekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jrobb@sekls.org --- Comment #1 from Jason Robb <jrobb@sekls.org> --- My knee-jerk reaction was to make those readonly to avoid bad data entry. I also styled away the border and the background so they just look like inconspicuous labels again. Sharing the jQuery in case its helpful while a better solution is found: //Make subfields readonly and unstylish in basic editor $('#cat_addbiblio .subfieldcode input.flat').css('border', '0').css('background', 'none').attr('readonly', true); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39292 Rebecca Coert <rcoert@arlingtonva.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rcoert@arlingtonva.us -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39292 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |phil@chetcolibrary.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39292 --- Comment #2 from Phil Ringnalda <phil@chetcolibrary.org> --- Well, being able to save a record with duplicate fields/subfields that the framework says should not be repeatable has existed a lot longer than that, since it has existed for imported records for as long as frameworks have existed. Until the advanced editor had to implement checking at save-time (since duplicating a subfield there is just a matter of typing), the only real meaning of the Repeatable checkbox was "should it have an icon to duplicate it?" I wouldn't object if someone wanted to write the same sort of save-time checking for the basic editor, though my experience with bogus imported records in the advanced editor makes me think there would be a fair amount of shock and pain for people who import records without carefully examining them as a result. Silently deleting things that aren't in your framework is a "feature" (though one you ordinarily wouldn't notice, since they'll be deleted from imported records before you ever look at them, and you won't create them yourself). But getting around RequireChoosingExistingAuthority by changing an uncontrolled subfield to a controlled one, that's cunning! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39292 mteal@greenvillelibrary.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mteal@greenvillelibrary.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39292 Miranda Nero <mnero@oslri.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mnero@oslri.net -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39292 Mathieu Saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mathsabypro@gmail.com -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org