Bug 30365 - Use the frameworks to determine if a field in cataloguing shows as textarea independent of content length
Summary: Use the frameworks to determine if a field in cataloguing shows as textarea i...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-25 20:05 UTC by Courtenay Johnson
Modified: 2022-07-17 10:38 UTC (History)
1 user (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
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Courtenay Johnson 2022-03-25 20:05:45 UTC 
Cataloging individual records using Frameworks.
Using version 21.05.03 running on Ubuntu.
Looking at the adddbiblio.pl code, (near line 445) I see that editing existing records that are greater than 100 characters long brings up the textarea method of input, and newlines are accepted. However if the existing shorter input, or any new input is forced to a single line text box and \n are ignored. My point is it is ridiculous  that accepting of \n from the keyboard is acceptable during some conditions, but not others.

As I have submitted in a bug report 30364 I also wish that the behaviour of the HTML input field should not vary if a plugin is present.

I propose that a new flag in the framework should determine if a subfield will use the HTML input text or the textarea for input, and thus whether or not \n is accepted, and this should allow \n in input of any length up to the maximum length usually 9999 which currently does not seem to be used.