View Issue Details

IDProjectCategoryView StatusLast Update
0024056mantisbtcustom fieldspublic2023-04-12 13:25
ReporterTiKu Assigned Toatrol  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version2.11.0 
Target Version2.13.0Fixed in Version2.13.0 
Summary0024056: Custom Fields of type "Textarea" cannot contain more than 255 chars due to bug_history table
Description

I have a custom field of type 10 (textarea) that is meant to contain more than 255 characters. If I report an issue and enter more than 255 characters, I run into an SQL error because Mantis tries to write the field's whole content to the bug_history table's new_value field, which is defined as varchar(255).

It would be okay to cut the value for the history at 255 characters.

TagsNo tags attached.

Relationships

related to 0010923 closedvboctor function history_log_event_direct should check (and eventually truncate) the length of the new and the old value 
related to 0025002 closedatrol Error when updating content in a custom field of type "Text Area" ("Textbereich"): History cannot be stored 
related to 0032385 closeddregad Incorrect use of mb_strimwidth() to truncate old/new values in history API 

Activities

atrol

atrol

2018-03-01 03:18

developer   ~0059061

Last edited: 2018-03-01 03:20

  1. cut the value to 255 characters

    easy to implement, but loss of data (of course, better than now)

  2. change data type of old_value and new_value columns

    easy to implement, but database schema changes needed

  3. implement solution similar to standard text fields (e.g. description)

    additional nice functionality like versioning, but not that easy to implement (e.g. have to migrate old history data)

TiKu

TiKu

2018-03-01 06:37

reporter   ~0059062

For my scenario solution 1 would be sufficient. Solution 3 could break plugins that access those fields in SQL queries. I don't consider this very common though.

atrol

atrol

2018-03-01 08:06

developer   ~0059063

PR https://github.com/mantisbt/mantisbt/pull/1309

cproensa

cproensa

2018-03-02 04:42

developer   ~0059066

I think (1) is good enough for now.

Regarding (3), instead of going for a specific functionality for custom fields, i'd rather propose an extension of history table itself, having change header and detail in separated tables (for long texts as a start)

Having long texts can be a performance hit when reading multiple rows cointaining that field when it may not actually be needed. As found in Oracle, where they are CLOB fields that need a separate query for retrieving each individual clob value (which is done under the hood by adodb)

Related Changesets

MantisBT: master 339cf883

2018-03-01 02:53

atrol


Details Diff
Truncate values before writing to database history table

TEXTAREA custom fields can contain more than 255 characters.
Changing such fields fails, as the new value can't be stored
in history table.

This change fixes the issue by truncating the string.
See 0024056 for other options to fix it.

Fixes 0024056
Affected Issues
0024056
mod - core/constant_inc.php Diff File
mod - core/history_api.php Diff File