Feature #3543
closed
Improve 'long text' custom fields
Added by Dom Torrisi almost 15 years ago. Updated about 7 years ago.
0%
Description
It would be helpful if 'long text' custom fields acted more like the description field in an issue, so that the fields could be longer, wider and have textile support.
It would also be helpful if they were in a 1 column layout instead of the current 2 column layout for custom fields, or at least for 'long text' custom fields.
Files
| 0101-adstec-custom_field_richtext.patch (7.39 KB) 0101-adstec-custom_field_richtext.patch | custom fields with rich text support. | Karl-Heinz Nirschl, 2010-05-05 14:42 | |
| update_form-dafault.png (11.6 KB) update_form-dafault.png | Dipan Mehta, 2013-04-10 09:20 | ||
| update_form-stretched.png (7.76 KB) update_form-stretched.png | Dipan Mehta, 2013-04-10 09:20 |
Related issues
Updated by VM Weseloh almost 15 years ago
+1 for us too, we have custom fields that are quite lengthy
Updated by Lalit Roul over 14 years ago
+1 for me also, I have custom field like 'Steps to Reproduce', wider text-areas and textile support would be great and make it more readable
Updated by Christian Mayr over 14 years ago
+1 for us, this feature would be really helpful
Updated by Holger Winkelmann about 14 years ago
+ 1
just tried to add another textile custom field as we will add a field "how to demostrate" for user stories.
Updated by Karl-Heinz Nirschl almost 14 years ago
Hi,
i created a patch for 0.9.3 (should work with 0.9.4 too) that adds custom fields with richtext (aka wiki) support. for now this is only working for issues.
let me know if you think that this code need some more work. i would be happy if this could be included in 1.0.
Updated by 
Updated by Harry Garrood over 12 years ago
+1 for the 1 column layout thing - it looks horrible when a long text field contains more than about 40 characters.
Updated by Dipan Mehta about 11 years ago
- File update_form-dafault.png update_form-dafault.png added
- File update_form-stretched.png update_form-stretched.png added
+100.
Long text makes it very cluttered in the display part with there are long URLs or lengthy text (which is usually important) specially when two long text fields are next to each other.
Long text field has 1 major issue in the update; the long text field occupies half of the plane and it has a corner with triangle to expand and shrink the field. Now if you drag it and implicitly drag out of the visible part of the div - the field now hidden. And also, there is simply no way to re-shrink the field.
See the images update_form-dafault.png and update_form-stretched.png. In the later case there is no way to stretch back to normal as well. The same effect also appears when browser is resized (shrinked).
Please provide 1 column layout (either by default OR selectable through setting).
If this is agreed upon, I can provide a patch that can provide 1 column layout for issue display as well as update form.
Updated by Dipan Mehta about 11 years ago
Add related #10021 - which shows another use case facing trouble.
Updated by Perico Os Palotes over 10 years ago
+1 to this feature.
I think comment #8 has a good summary about what happens currently with a custom field with long text inside.
Updated by Dipan Mehta over 10 years ago
Updated by Toshi MARUYAMA over 10 years ago
- Related to Feature #1179: Optionally allow Text and Long Text custom fields support wiki formatting added
Updated by Matt Fozard almost 10 years ago
+1 for the option to display long text fields in 1 column (or spanning 2 columns). There isn't enough width to view and edit these fields at present.
Updated by the fury almost 9 years ago
+1. Right now my playground has "Steps to reproduce", "Expected result", and "Actual result" as custom fields, all long text, and their short 2 column layout (and apparently top-down reading order) make it a little hard to follow.
Making this span the full length like the description would help a lot.
Also along the lines of making long text fields equivalent to the description: add checkboxes for custom fields to be shown on separate rows in the issue list, like the description can be shown. That way, description, steps, results etc. for all issues can be shown on a single page for people who like that kind of thing.
Updated by Moisés Bites almost 9 years ago
+1.
We need a textile custom field as we will add a field "how to demostrate" for user stories.
Updated by Marius BĂLTEANU over 8 years ago
A patch that solves in other way this ticket was added to #21705.
Updated by Toshi MARUYAMA about 8 years ago
- Related to Patch #21705: Option for long text custom fields to be displayed using full width added
Updated by Gabriel Lopes over 7 years ago
+1 this would be a great feature. As best practices we have "Acceptance Criteria" to each Feature that will be developed, having this UI tweak would be great for the team working on any project with similar requirements
Updated by Go MAEDA over 7 years ago
- Status changed from New to Closed
- Resolution set to Fixed
"Full width layout" for long text custom fields was implemented by #21705 for upcoming 3.4.0.
I am closing this issue.
Updated by Greg T about 7 years ago
Go MAEDA wrote:
"Full width layout" for long text custom fields was implemented by #21705 for upcoming 3.4.0.
Yeah, thanks for everyone involved. But
1. Textile tables aren't rendered in PDF;
2. wide Textile tables are truncated unlike the ones in comments with their own scrollbars (i.e. "overflow: auto" is missing).
Updated by john aylward about 7 years ago
Greg T wrote:
Go MAEDA wrote:
"Full width layout" for long text custom fields was implemented by #21705 for upcoming 3.4.0.
Yeah, thanks for everyone involved. But
1. Textile tables aren't rendered in PDF;
2. wide Textile tables are truncated unlike the ones in comments with their own scrollbars (i.e. "overflow: auto" is missing).
Personally I'm fine with that as I don't use tables very often. As long as separate issue is opened to address it, I think it's better to get this in even with tables not working.
Updated by Greg T about 7 years ago
john aylward wrote:
Personally I'm fine with that as I don't use tables very often. As long as separate issue is opened to address it, I think it's better to get this in even with tables not working.
I don't understand your problem.
Just because you don't use something, it's not a not a nice thing to vote against improvements. The changes you're interested in are already in the SVN trunk.
The description of this issue includes "and have textile support" which is only partially implemented. Patch #21705 doesn't mention Textile at all, that's why I chose this issue.
The "Submissions" guidelines include "have a look at the bug list and the FAQ to see if it has not already been reported". They don't mention closed issues, though, so I'm not sure what to do when I feel the original issue is not fully solved and I can't reopen the issue.