#1791 closed enhancement (fixed)
[PATCH] Allow WikiFormatting in custom ticket fields of type textarea, and labels of any custom field.
Reported by: | Owned by: | Remy Blank | |
---|---|---|---|
Priority: | normal | Milestone: | 0.11.3 |
Component: | ticket system | Version: | devel |
Severity: | normal | Keywords: | wiki custom |
Cc: | khundeen@…, hoessler@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description (last modified by )
This patch builds on the patch provided in #925 and resolves the issue addressed in #1392 against the trunk. WikiFormatting of all custom field labels is allowed, and textarea fields can use as much WikiFormatting as they would like. Quite a bit of functionality for 7 lines of code ;) Of course I haven't tested this throughly. Since the preview for tickets is now done at the top with the full ticket display, you even get a preview of everything! This patch is against [1970] the trunk as of 07/14/2005 08:22:30 PM.
Index: trac/ticket/api.py =================================================================== --- trac/ticket/api.py (revision 1970) +++ trac/ticket/api.py (working copy) @@ -25,6 +25,8 @@ from trac.core import * from trac.perm import IPermissionRequestor from trac.wiki import IWikiSyntaxProvider +from trac.wiki import wiki_to_html +from trac.wiki import wiki_to_oneliner class MyLinkResolver(Component): """ @@ -121,7 +123,8 @@ 'name': name, 'type': self.config.get('ticket-custom', name), 'order': int(self.config.get('ticket-custom', name + '.order', '0')), - 'label': self.config.get('ticket-custom', name + '.label', ''), + 'label': wiki_to_oneliner(self.config.get('ticket-custom', name + '.label', ''), + self.env, self.env.get_db_cnx()), 'value': self.config.get('ticket-custom', name + '.value', '') } if field['type'] == 'select' or field['type'] == 'radio': Index: trac/ticket/web_ui.py =================================================================== --- trac/ticket/web_ui.py (revision 1970) +++ trac/ticket/web_ui.py (working copy) @@ -348,6 +348,8 @@ if name in ('summary', 'reporter', 'description', 'type', 'status', 'resolution', 'owner'): field['skip'] = True + else: + field['formatted'] = wiki_to_html(ticket.values.get(name), self.env, req, db) req.hdf['ticket.fields.' + name] = field req.hdf['ticket.reporter_id'] = util.escape(reporter_id) Index: templates/ticket.cs =================================================================== --- templates/ticket.cs (revision 1970) +++ templates/ticket.cs (working copy) @@ -64,7 +64,7 @@ if:fullrow && idx % 2 ?><th></th><td></td></tr><tr><?cs /if ?> <th id="h_<?cs var:name(field) ?>"><?cs var:field.label ?>:</th> <td<?cs if:fullrow ?> colspan="3"<?cs /if ?> headers="h_<?cs - var:name(field) ?>"><?cs var:ticket[name(field)] ?></td><?cs + var:name(field) ?>"><?cs var:field.formatted ?></td><?cs if:idx % 2 ?></tr><tr><?cs elif:idx == num_fields - 1 ?><th></th><td></td><?cs /if ?><?cs set:idx = idx + #fullrow + 1 ?><?cs
Attachments (8)
Change History (44)
by , 19 years ago
Attachment: | patch-customfieldwiki-r1970.diff added |
---|
comment:3 by , 18 years ago
Cc: | removed |
---|
comment:4 by , 18 years ago
Owner: | changed from | to
---|
by , 18 years ago
Attachment: | trac.format.custom.fields.0.9.5.patch added |
---|
comment:7 by , 18 years ago
Here is an alternative. I didn't like formating of labels - and I wanted to make formating of the custom-field selectable. So now, in your ini file you can have:
[ticket-custom] foobar = text foobar.label = The foo dazzle foobar.value = "" foobar.format = wiki
Format can (for now?) be one of plain, wiki, or wiki_oneliner.
Inserting the patch here, since the attachment seems to be missing one file?
--- ticket/api.py.ORIG Wed Feb 15 19:47:44 2006 +++ ticket/api.py Fri Dec 1 12:17:30 2006 @@ -121,7 +121,8 @@ 'order': int(self.config.get('ticket-custom', name + '.order', '0')), 'label': self.config.get('ticket-custom', name + '.label') \ or name.capitalize(), - 'value': self.config.get('ticket-custom', name + '.value', '') + 'value': self.config.get('ticket-custom', name + '.value', ''), + 'format': self.config.get('ticket-custom', name + '.format', 'plain') } if field['type'] == 'select' or field['type'] == 'radio': options = self.config.get('ticket-custom', name + '.options') --- ticket/web_ui.py.ORIG Wed Feb 15 19:47:44 2006 +++ ticket/web_ui.py Fri Dec 1 15:29:16 2006 @@ -376,6 +376,18 @@ if name in ('summary', 'reporter', 'description', 'type', 'status', 'resolution', 'owner'): field['skip'] = True + else: + if 'format' in field: + if field['format'] == 'wiki': + field['formatted'] = wiki_to_html(ticket.values.get(name), self.env, req, db) + elif field['format'] == 'wiki_oneliner': + field['formatted'] = wiki_to_oneliner(ticket.values.get(name), self.env, db, shorten=True) + elif field['format'] == 'pre': + field['formatted'] = wiki_to_html('{{{\n' + ticket.values.get(name) + '\n}}}', self.env, req, db) + else: + field['formatted'] = ticket.values.get(name) + else: + field['formatted'] = ticket.values.get(name) req.hdf['ticket.fields.' + name] = field req.hdf['ticket.reporter_id'] = reporter_id --- templates/ticket.cs.ORIG Sat Nov 5 17:51:06 2005 +++ templates/ticket.cs Fri Dec 1 11:08:15 2006 @@ -64,7 +64,7 @@ if:fullrow && idx % 2 ?><th></th><td></td></tr><tr><?cs /if ?> <th id="h_<?cs var:name(field) ?>"><?cs var:field.label ?>:</th> <td<?cs if:fullrow ?> colspan="3"<?cs /if ?> headers="h_<?cs - var:name(field) ?>"><?cs var:ticket[name(field)] ?></td><?cs + var:name(field) ?>"><?cs var:field.formatted ?></td><?cs if:idx % 2 || fullrow ?></tr><tr><?cs elif:idx == num_fields - 1 ?><th></th><td></td><?cs /if ?><?cs set:idx = idx + #fullrow + 1 ?><?cs
by , 18 years ago
Attachment: | trac.format.custom.fields.0.9.5.2.patch added |
---|
Patch against trac 0.9.5 to enable wiki formating of custom fields
comment:10 by , 18 years ago
I had a look at my current 0.10.3 trac and I couldn't find things such as the line that goes
'value': self.config.get('ticket-custom', name + '.value', ''),
so someone would need to "backport" the patch to have it work.
Also I was wondering why this hadn't been included in the 0.10 series.
by , 18 years ago
Attachment: | trac.format.custom.fields.0.10.patch added |
---|
Patch against trac 0.10 to enable wiki formating of custom fields & collapsable change history
comment:11 by , 18 years ago
The most recently attached patch is basically the same as the previous patches, but it adds a change to the change history of a ticket. This change will collapse changes to custom fields that are wiki, wiki-one-liner, or pre. The changes can by expanded by clicking on a button.
This can be quite helpful if you make frequent changes to these types of fields, because it will keep the length of the change history of a ticket more reasonable.
comment:13 by , 17 years ago
Cc: | added |
---|
comment:14 by , 17 years ago
Hello[[br]] I would like to propose an enhancement for the collapsable history. The code could be cleaner, and the comment div could also be collapsable. I tried to clean the code, making easier to understand and maintain:
<script> // Enhancement function that is trying to make code cleaner function $(field){ return document.getElementById(field); } function showHide(divField, spanHolder){ if($(divField).style.display=='') { $(divField).style.display='none'; spanHolder.innerHTML="+"; } else { $(divField).style.display=''; spanHolder.innerHTML="-"; } } </script> <ul class="changes"><?cs each:field = change.fields ?> <!-- BEGINING OF CHANGE HISTORY //--> <li><strong><?cs var:name(field) ?></strong> <?cs if:name(field) == 'attachment' ?><em><?cs var:field.new ?></em> added<?cs elif:field.format != 'plain' ?>changed<?cs elif:field.old && field.new ?>changed from <em><?cs var:field.old ?></em> to <em><?cs var:field.new ?></em><?cs elif:!field.old && field.new ?>set to <em><?cs var:field.new ?></em><?cs elif:field.old && !field.new ?>deleted<?cs else ?>changed<?cs /if ?>. <?cs if field.format != 'plain' ?> <div style="font-size:0.8em;font-weight:bold;"> Detail <span style="cursor:pointer" onclick="showHide('chang_detail_<?cs var:change.cnum ?>_<?cs var:name(field) ?>',this)">+</span> </div> <div id="chang_detail_<?cs var:change.cnum ?>_<?cs var:name(field) ?>" style="display:none;"> <div style="border: 1px outset #996; padding: 1em;"> <?cs var:field.old ?> </div> <div style="margin:1em;2em;">to</div> <div style="border: 1px outset #996; padding: 1em;"><?cs var:field.new ?></div> </div><?cs /if ?></li> <?cs /each ?> </ul><?cs /if ?> <div style="font-size:0.8em;font-weight:bold;"> Comment <span style="cursor:pointer" onclick="showHide('chang_comment_<?cs var:change.cnum ?>_<?cs var:name(field) ?>',this)">+</span> </div> <div class="comment" id="chang_comment_<?cs var:change.cnum ?>_<?cs var:name(field) ?>"> <?cs var:change.comment ?> </div> <!-- END OF CHANGE HISTORY //-->
by , 17 years ago
Attachment: | trac.format.custom.fields.0.11.patch added |
---|
Patch against 0.11 trunk r6425 that allows wiki style custom fields
comment:15 by , 17 years ago
This patch is for 0.11 (trunk rev 9425), and is basically a port of the 0.10 patch above. It does not include the the collapsable history, since 0.11 doesn't display changes to custom fields inline, but via an extra "diff" link.
follow-up: 17 comment:16 by , 17 years ago
Milestone: | 0.11.1 → 0.12 |
---|---|
Owner: | changed from | to
Status: | new → assigned |
Thanks, I think it's a good starting point. However, for the 'pre'
style, why not simply wrap the contesnt directly in a <pre> elmenet (e.g. <pre py:content="field[name]" />
)?
Also, as it's a non-trivial enhancement (i.e. it will need to be documented as a new feature in TracTickets), I moved the milestone to the next major version.
by , 17 years ago
Attachment: | trac.format.custom.fields.0.11.v2.patch added |
---|
Patch against 0.11 trunk r6425 without box around 'pre' fields
comment:17 by , 17 years ago
Replying to cboos:
Thanks, I think it's a good starting point. However, for the
'pre'
style, why not simply wrap the contesnt directly in a <pre> elmenet (e.g.<pre py:content="field[name]" />
)?
Since I'm not the author of the original patch, I cannot tell for sure, but I guess the purpose of putting the content through an extra wiki_to_html() was to have a box around the text. Nonetheless, I think the result looked a bit strange, since the resulting box is also intended, so I've changed the patch the way you suggested.
Also, as it's a non-trivial enhancement (i.e. it will need to be documented as a new feature in TracTickets), I moved the milestone to the next major version.
Makes sense to me.
comment:18 by , 17 years ago
Somebody ought to fix the timestamp in the ticket description; I think maybe the original poster used the macro thinking it was for inserting the time-at-save, when it's really for displaying the time-at-view. The correct timestamp would be, I think, 07/14/2005 08:22:30 PM.
Looking forward to trying the current patch, though!
comment:19 by , 17 years ago
Description: | modified (diff) |
---|
Right, the Timestamp macro is really badly named - #1240
comment:20 by , 17 years ago
#7195 requested the same possibility, but for standard fields as well (wiki formatting for summary in this example).
comment:21 by , 16 years ago
So I found this very useful. However I also wanted to be able to have wiki formatting in the report and query views.
After applying the above patch I was able to achieve this by changing only two lines. I'm working against 0.11rc2.
Index: trac/ticket/templates/report_view.html =================================================================== —- trac/ticket/templates/report_view.html (revision 7204) +++ trac/ticket/templates/report_view.html (working copy) @@ -136,7 +136,8 @@
</py:when>
<py:otherwise>
- <td class="$col" py:attrs="td_attrs">$cell.value
+ <td class="$col" py:attrs="td_attrs"> + ${wiki_to_html(context(row.resource), cell.value)}
<hr py:if="fullrow"/>
</td>
</py:otherwise>
Index: trac/ticket/templates/query_results.html =================================================================== —- trac/ticket/templates/query_results.html (revision 7204) +++ trac/ticket/templates/query_results.html (working copy) @@ -61,7 +61,7 @@
<py:when test="name == 'reporter'">${authorinfo(value)}</py:when> <py:when test="name == 'cc'">${format_emails(ticket_context, value)}</py:when> <py:when test="name == 'owner' and value">${authorinfo(value)}</py:when>
- <py:otherwise>$value</py:otherwise>
+ <py:otherwise>${wiki_to_html(ticket_context, value)}</py:otherwise>
</td>
</py:with>
</py:for>
follow-up: 23 comment:22 by , 16 years ago
Owner: | changed from | to
---|---|
Status: | assigned → new |
I've tested all the recent patches, including report/query display, and it looks good. Good going contributors and helpers :-)
I do wonder about the pre/plain
vs. wiki
format setting though, and if it is actually needed? Every other textarea in Trac supports WikiFormatting - so why not just make every textarea custom field support it as well?
Could anyone please make a strong argument for why the pre-formatted text variation is needed - ie. something that cannot as easily be done with a wiki-based field like everywhere else?
follow-up: 24 comment:23 by , 16 years ago
Replying to osimons:
I do wonder about the
pre/plain
vs.wiki
format setting though, and if it is actually needed? Every other textarea in Trac supports WikiFormatting - so why not just make every textarea custom field support it as well?
And keep in mind that the current (0.11) plain version simply puts it into the HTML - which just makes all text appear as one large regular text paragraph without any formatting.
Having looked at it some more, I am quite certain that just doing wiki formatting by default in all custom field textareas should make everyone happy. Raise your hand and speak up if you disagree! :-)
follow-up: 25 comment:24 by , 16 years ago
Cc: | added |
---|
Replying to osimons:
Having looked at it some more, I am quite certain that just doing wiki formatting by default in all custom field textareas should make everyone happy. Raise your hand and speak up if you disagree! :-)
+1 from me. Would it help if I update the patch accordingly, or is it too trivial?
comment:25 by , 16 years ago
Replying to Joachim Hoessler <hoessler@…>:
+1 from me. Would it help if I update the patch accordingly, or is it too trivial?
Help is always welcome, and an up-to-date patch would make it easier for others to try out. Likely the patch should be made against trunk as it is a new feature and unlikely to make it into 0.11-stable (stable branches are primarily bug/security fixes).
No rush on this yet with current target for 0.13, so perhaps some other devs could first voice their opinion before we put too much work into patch and review.
by , 16 years ago
Attachment: | 1791-wikiformatting-text-textarea-r7495.patch added |
---|
Patch agianst trunk adding configurable WikiFormatting for text and textarea custom fields
comment:26 by , 16 years ago
Replying to osimons:
Having looked at it some more, I am quite certain that just doing wiki formatting by default in all custom field textareas should make everyone happy. Raise your hand and speak up if you disagree! :-)
/me raises hand :-)
One reason why I think enabling wiki syntax for custom fields should be configurable is backwards compatibility. Current users of custom fields have databases containing text that was entered as "plain". They should not be forced to review and edit all fields at upgrade time, but should be allowed to flip the switch when ready.
The patch above is updated to current trunk, but has a few differences compared to the previous ones:
- WikiFormatting can only be enabled for
text
andtextarea
fields. Other field types do not make sense, as their contents may appear in locations that do not support links, e.g. in drop-down fields. The default is currently 'plain', but maybe it should be set to 'wiki' instead. text
fields are formatted withwiki_to_oneliner()
.textarea
fields are formatted withwiki_to_html()
.- The stylesheet is fixed to remove the margins at the top and at the bottom of the wiki-formatted field content, so that the first line of the content is aligned with the field label.
- The query results table is fixed to wikify
text
fields.textarea
fields are already wikified in trunk. - I didn't add wikification in reports, as it is not possible to determine the custom field name from the SQL result set..
It would be great if this patch could receive some testing.
comment:27 by , 16 years ago
Milestone: | 0.13 → 0.12 |
---|---|
Owner: | changed from | to
The patch above is an updated version with a small variation:
- Instead of adding special cases to the field rendering section in
ticket.html
, it usesfield['rendered']
to hold the wiki-rendered value of a field.
I'm happy with the patch at this point, so if there are no objections, I'd like to apply it pretty soon, probably right after #7562 is closed.
follow-up: 29 comment:28 by , 16 years ago
Patch looks good.
A little suggestion for trac/ticket/query.py
: instead of
wikify = dict((f['name'], f['type'] == 'text' and f.get('format') == 'wiki') for f in self.fields) ... 'wikify': wikify.get(col, False),
maybe something like:
wikify = set(f['name'] for f in self.fields if f['type'] == 'text' and f.get('format') == 'wiki') ... 'wikify': col in wikify,
comment:29 by , 16 years ago
follow-up: 31 comment:30 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Patch applied in [7563].
follow-up: 32 comment:31 by , 16 years ago
Milestone: | 0.12 → 0.11.2 |
---|
Replying to [comment:30 rblank ]:
Patch applied in [7563].
I have installed trac 0.11.1, Now I want to know how I use this patch?
comment:32 by , 16 years ago
Replying to anonymous:
Replying to [comment:30 rblank ]:
Patch applied in [7563].
I have complemented the function,thank you!
comment:33 by , 16 years ago
Milestone: | 0.11.2 → 0.12 |
---|
Please do not change ticket fields without a reason.
comment:34 by , 16 years ago
#7954 closed as duplicate, but mentions missing docs - should perhaps be a 0.12/TracTicketsCustomFields page showing new settings?
comment:36 by , 16 years ago
Seems doable - however it would be better to "sponsor" such backports by first testing (and then eventually adapting) the patch (in this case, r7563). This will greatly increase the chances for this to happen.
comment:37 by , 16 years ago
I tried applying the patch to my stable 0.11.x install, but it failed. I manually applied the changes and it works. Not exactly proof. :)
comment:38 by , 16 years ago
Milestone: | 0.12 → 0.11.3 |
---|
Backported to 0.11-stable in [7859]. Also, added the .format
option to the documentation at TracTicketsCustomFields@25.