Closed
Bug 411437
Opened 17 years ago
Closed 17 years ago
Clipping of "Free Text" fields when user enters more then 255 characters.
Categories
(Bugzilla :: User Interface, defect)
Tracking
()
RESOLVED
FIXED
Bugzilla 3.0
People
(Reporter: Alex.Eiser, Assigned: LpSolit)
Details
Attachments
(2 files, 3 obsolete files)
5.70 KB,
patch
|
mkanat
:
review+
|
Details | Diff | Splinter Review |
6.57 KB,
patch
|
mkanat
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_1; en-us) AppleWebKit/525.1+ (KHTML, like Gecko) Version/3.0.4 Safari/523.10.6 Build Identifier: Bugzilla 3.1.2 The user should be prevented, or warned when entering more then 255 characters into a free text field. If the user does enter more then that amount of data, the data will be clipped with out telling/warning the user. Reproducible: Always Steps to Reproduce: 1. Create an instance of Bugzilla 2. Add a Free Text custom field. 3. Create a new record 4. Enter 300 characters into the new custom field. 5. Save 6. Compare what you saved, and the value stored in the DB, and that displayed to the user when bug is loaded Actual Results: Content of custom field is clipped to 255 characters. Expected Results: The user is prevented/warned that he has entered to much data. Simple fix.. add a maxlength to the template code.
Reporter | ||
Updated•17 years ago
|
Version: unspecified → 3.0
Updated•17 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Clipping of "Free Text" when user enters more then 255 characters. → Clipping of "Free Text" fields when user enters more then 255 characters.
Target Milestone: --- → Bugzilla 3.0
Assignee | ||
Comment 1•17 years ago
|
||
Requesting blocking as it may be seen as dataloss, especially if you paste some important data in it and don't check whether the string has been deleted or not.
Flags: blocking3.2?
Flags: blocking3.0.4?
Updated•17 years ago
|
Flags: blocking3.2?
Flags: blocking3.2+
Flags: blocking3.0.4?
Flags: blocking3.0.4+
Assignee | ||
Comment 2•17 years ago
|
||
Assignee | ||
Comment 3•17 years ago
|
||
Woah, I forgot to edit a line.
Attachment #296151 -
Attachment is obsolete: true
Attachment #296153 -
Flags: review?(mkanat)
Attachment #296151 -
Flags: review?(mkanat)
Comment 4•17 years ago
|
||
Comment on attachment 296153 [details] [diff] [review] patch, v1.1 This looks great. >Index: Bugzilla/Constants.pm > [snip] >+ MAX_FREETEXT_LENGTH >+ Nit: Aren't there other MAX_?_LEN constants this could be grouped with? The reason for the r- is that the error needs to be added to Bugzilla::WebService::Constants, and possibly documented in the WebService POD, if it gets its own number. (I don't think it will need its own number, there's already some similar "invalid_field" error that it can share the number of.)
Attachment #296153 -
Flags: review?(mkanat) → review-
Assignee | ||
Comment 5•17 years ago
|
||
Attachment #296153 -
Attachment is obsolete: true
Attachment #296705 -
Flags: review?(mkanat)
Comment 6•17 years ago
|
||
Comment on attachment 296705 [details] [diff] [review] patch, v2 Looks fine. We should actually re-use MAX_FREETEXT_LENGTH in the SQL_DEFINITION constant in Bugzilla::Field. Also, the POD you changed needs a comma after "invalid value".
Attachment #296705 -
Flags: review?(mkanat) → review+
Updated•17 years ago
|
Flags: approval+
Assignee | ||
Comment 7•17 years ago
|
||
I moved _check_* methods in the "custom fields" section of Bug.pm as requested by Max on IRC. Leaving this bug open as I still have to backport it for Bugzilla 3.0.4. tip: Checking in Bugzilla/Bug.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Bug.pm,v <-- Bug.pm new revision: 1.225; previous revision: 1.224 done Checking in Bugzilla/Constants.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Constants.pm,v <-- Constants.pm new revision: 1.87; previous revision: 1.86 done Checking in Bugzilla/WebService/Bug.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/WebService/Bug.pm,v <-- Bug.pm new revision: 1.9; previous revision: 1.8 done Checking in Bugzilla/WebService/Constants.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/WebService/Constants.pm,v <-- Constants.pm new revision: 1.13; previous revision: 1.12 done Checking in template/en/default/bug/field.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/field.html.tmpl,v <-- field.html.tmpl new revision: 1.14; previous revision: 1.13 done Checking in template/en/default/global/user-error.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user-error.html.tmpl,v <-- user-error.html.tmpl new revision: 1.239; previous revision: 1.238 done
Assignee | ||
Comment 8•17 years ago
|
||
Here is the backport for 3.0.x.
Attachment #296742 -
Flags: review?(mkanat)
Assignee | ||
Comment 9•17 years ago
|
||
Without _check_default_field() as Max doesn't like it.
Attachment #296742 -
Attachment is obsolete: true
Attachment #296743 -
Flags: review?(mkanat)
Attachment #296742 -
Flags: review?(mkanat)
Comment 10•17 years ago
|
||
Comment on attachment 296743 [details] [diff] [review] patch for 3.0.x, v2 Yeah, looks fine.
Attachment #296743 -
Flags: review?(mkanat) → review+
Updated•17 years ago
|
Flags: approval3.0+
Assignee | ||
Comment 11•17 years ago
|
||
3.0.3: Checking in process_bug.cgi; /cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v <-- process_bug.cgi new revision: 1.351.2.7; previous revision: 1.351.2.6 done Checking in Bugzilla/Bug.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Bug.pm,v <-- Bug.pm new revision: 1.171.2.3; previous revision: 1.171.2.2 done Checking in Bugzilla/Constants.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Constants.pm,v <-- Constants.pm new revision: 1.68.2.13; previous revision: 1.68.2.12 done Checking in Bugzilla/WebService/Bug.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/WebService/Bug.pm,v <-- Bug.pm new revision: 1.4.2.3; previous revision: 1.4.2.2 done Checking in Bugzilla/WebService/Constants.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/WebService/Constants.pm,v <-- Constants.pm new revision: 1.6.2.3; previous revision: 1.6.2.2 done Checking in template/en/default/bug/field.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/field.html.tmpl,v <-- field.html.tmpl new revision: 1.8.2.1; previous revision: 1.8 done Checking in template/en/default/global/user-error.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user-error.html.tmpl,v <-- user-error.html.tmpl new revision: 1.204.2.9; previous revision: 1.204.2.8 done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Comment 12•16 years ago
|
||
Does bug 411437 only pertain to particular browsers and only on Apple systems? If so, then why limit all users to 255 character limit for freetext fields? I have tested larger field data on Windows and Unix, using IE 7.0, FireFox 2.0.0.14 and 3.0 with no clipping issues.
Reporter | ||
Comment 13•16 years ago
|
||
I would need to do some testing, but the actual issue is the Database field def is varchar(255) the DB should not be able to save more then 255 characters.
Comment 14•16 years ago
|
||
Ah, I see now that you are correct. My CF field is a Mediumtext and I remember that this is because I needed to import existing data (and 255 is anyway too small for my purposes). The problem came to a head when a Windows user was trying to save even though he had not changed the CF data. Anyway, I guess now I will have to watch out for these Apple browsers. Thanks.
Reporter | ||
Comment 15•16 years ago
|
||
I really don't think it has anything to do with the apple browser... we can talk about it on IM/IRC if you want.
You need to log in
before you can comment on or make changes to this bug.
Description
•