Bug 39292 - Editing subfield tags in bib editor allows contradiction of framework setup
Summary: Editing subfield tags in bib editor allows contradiction of framework setup
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-03-10 16:37 UTC by Andrew Fuerste-Henry
Modified: 2025-03-20 20:27 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2025-03-10 16:37:38 UTC
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.
Comment 1 Jason Robb 2025-03-10 16:49:09 UTC
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);
Comment 2 Phil Ringnalda 2025-03-12 02:24:27 UTC
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!