Vote #78517
完了Allow full_width_layout long-text custom fields to appear in the issue list like 'Description' (as a block column)
0%
説明
I see that issue #21705 will allow for long text custom fields to be edited and viewed more similarly to the Description field. The examples given are "Description, Release Notes, Testing Steps", etc.
I don't believe that patch will add the feature I am looking for.
When performing a query, after "Group results by" there is an option for "Show". The only choice is "Description". Choosing this will show the description full width beneath each row. I found that this is controlled by a variable in the QueryColumn class called @inline. The QueryCustomFieldColumn class extends the QueryColumn class and hard-codes the @inline variable to 'true'. I would like to be able to "Show" long text custom fields similar to the Description.
This would allow, say, a query where "status is 'testing'" and have the search results show 'Testing steps' beneath each item. Or, a query where "version is 3.3" and show "Release Notes" beneath each item.
Currently when you select "description", the description is shown, but without a label. If you can choose custom fields, then the text would need a label. Such as "Release notes: blah"
I haven't been able to test this against trunk. I wasn't able to get a copy of trunk working, so I don't know for sure if this was also resolved in addition to #21705.
I've tried to search thoroughly if this has already been requested or implemented some other way, and I can't find anything. I also did a search for every instance of "call_hook" in the code, and I don't think this can be implemented with a plugin.
journals
jb cbdse wrote:
> [...]
> I don't believe that patch will add the feature I am looking for.
Indeed. That feature does not include the addition of the ability to render custom fields as inline columns.
--------------------------------------------------------------------------------
Here's the patch we did on 3.3.3.
Mashing 'description' onto the css classes of custom fields is not ideal, but it got the job done.
I can't test against trunk. I haven't been able to get a checkout of trunk working.
--------------------------------------------------------------------------------
Thanks for sharing your patch.
jb cbdse wrote:
> Mashing 'description' onto the css classes of custom fields is not ideal, but it got the job done.
It is indeed far from ideal and certainly not (yet) ready for integration. It also misses the correct rendering of the values using a @div.wiki@ element to wrap the @p@ element. This _can_ (and probably will) cause problems rendering formatted values (especially thinking about syntax highlighting here).
jb cbdse wrote:
> I can't test against trunk. [...]
The patch will need some modifications (in line with r16367 for #1474) for trunk compatibility.
I have been pondering about this feature for some time, and I think it could be a nice improvement on top of #21705. I'll explain. With #21705, full_width_layout long-text custom field columns are still rendered as inline columns while the content they'll hold would be presumed to render with a full-width layout. This can make the values hard to read and — as such — the (inline) column not-very usable. If we have #21705 extended in such a way that it'll render full_width_layout long-text custom field columns as block columns, it might improve the usability of it. I'll ping the author of #21705 (and also #1474) to get his opinion on this FR.
For the above, TS's patch should be modified to also check on @custom_field.full_width_layout?@ (like @if custom_field.field_format == "text" && custom_field.full_width_layout? ...@).
PS: I have modified the subject to match the terminology of the Redmine code base (the reciprocal of inline) and to precise the request itself.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Note: TS's patch also changes the custom fields' column on the timelog views, which might not be desired and/or expected.
--------------------------------------------------------------------------------
Thanks for the feedback. Yeah, I figured someone would know a lot more than me, but I was glad to be able to prove the concept. We ended up changing the <h3> in that patch to something smaller and italicized. We ended up hard-coding something to omit it for the stock 'description' field. When it was big and bold, it looked bad in queries with 'group' criteria - the group headings got lost. I still think it needs a label, but it needs to be relatively unemphasized.
Yes, I agree that basing it off of full_width_layout would be better. There's a "multi column custom fields" plugin, and I originally based it off of the multi_column attribute that it added, but I didn't want to depend on the plugin logic. So, I totally agree about the new field from #21705. Ruby's not my thing, but I might revisit this later if I can get trunk working.
--------------------------------------------------------------------------------
jb cbdse wrote:
> Yes, I agree that basing it off of full_width_layout would be better.
I'll modify the issue subject accordingly.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Attached two patches:
1. attachment:0001-Show-full-width-layout-custom-fields-as-block-column.patch which implements this feature.
2. attachment:0002-Styles-for-block-column-name.patch which is optional and adds some styles to the block column names in order to make them more obvious for users:
!{width:80%; border: 1px solid grey; margin-top: 2px;}.block_columns.png!
Tests pass: https://gitlab.com/marius-balteanu/redmine/-/jobs/155542640
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Committed the patch. Thank you for contributing the patches.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
related_issues
relates,Closed,21705,Option for long text custom fields to be displayed using full width
relates,Closed,32768,Internal Error when issue text custom field is shown in Spent time query results
relates,Closed,32859,Issue list: long text custom field missing in PDF export
relates,Closed,33169,Issues CSV export does not include custom fields with "Full width layout" enabled