Edgewall Software
Modify

Opened 9 years ago

Closed 6 years ago

Last modified 5 years ago

#1791 closed enhancement (fixed)

[PATCH] Allow WikiFormatting in custom ticket fields of type textarea, and labels of any custom field.

Reported by: anthony.vito@… Owned by: rblank
Priority: normal Milestone: 0.11.3
Component: ticket system Version: devel
Severity: normal Keywords: wiki custom
Cc: khundeen@…, hoessler@…
Release Notes:
API Changes:

Description (last modified by cboos)

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)

patch-customfieldwiki-r1970.diff (2.3 KB) - added by anthony.vito@… 9 years ago.
trac.format.custom.fields.0.9.5.patch (2.2 KB) - added by seb at tail-f.com 8 years ago.
trac.format.custom.fields.0.9.5.2.patch (2.2 KB) - added by seb at tail-f.com 8 years ago.
Patch against trac 0.9.5 to enable wiki formating of custom fields
trac.format.custom.fields.0.10.patch (5.9 KB) - added by nathan(dot)wells at dtn.com 7 years ago.
Patch against trac 0.10 to enable wiki formating of custom fields & collapsable change history
trac.format.custom.fields.0.11.patch (5.4 KB) - added by Joachim Hoessler <hoessler@…> 7 years ago.
Patch against 0.11 trunk r6425 that allows wiki style custom fields
trac.format.custom.fields.0.11.v2.patch (5.4 KB) - added by Joachim Hoessler <hoessler@…> 7 years ago.
Patch against 0.11 trunk r6425 without box around 'pre' fields
1791-wikiformatting-text-textarea-r7495.patch (6.4 KB) - added by rblank 6 years ago.
Patch agianst trunk adding configurable WikiFormatting for text and textarea custom fields
1791-wikiformatting-text-textarea-r7548.patch (7.5 KB) - added by rblank 6 years ago.
Updated patch

Download all attachments as: .zip

Change History (44)

Changed 9 years ago by anthony.vito@…

comment:1 Changed 9 years ago by anthony.vito@…

This patch does not support WikiFormatting in the Changelog when custom fields are changed. It does make the Changelog look kind of ugly when a lot of formatting is used. I'll be back to fix that one soon.

comment:2 Changed 9 years ago by Markus Tacker <m@…>

See also #925.

comment:3 Changed 8 years ago by eblot

  • Cc fsdfds removed

comment:4 Changed 8 years ago by athomas

  • Owner changed from jonas to athomas

Changed 8 years ago by seb at tail-f.com

comment:7 Changed 8 years ago by seb at tail-f.com

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

Changed 8 years ago by seb at tail-f.com

Patch against trac 0.9.5 to enable wiki formating of custom fields

comment:8 Changed 8 years ago by sid

#3668 was marked as duplicate of this ticket.

comment:9 Changed 7 years ago by alexandre.franke@…

Is it safe to apply this patch to a 0.10.x trac installation?

comment:10 Changed 7 years ago by alexandre.franke@…

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.

Changed 7 years ago by nathan(dot)wells at dtn.com

Patch against trac 0.10 to enable wiki formating of custom fields & collapsable change history

comment:11 Changed 7 years ago by nathan(dot)wells at dtn.com

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:12 Changed 7 years ago by cboos

  • Milestone set to 0.11

Food for PyCon'ers

comment:13 Changed 7 years ago by anonymous

  • Cc khundeen@… added

comment:14 Changed 7 years ago by victorhg@…

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 //-->

Changed 7 years ago by Joachim Hoessler <hoessler@…>

Patch against 0.11 trunk r6425 that allows wiki style custom fields

comment:15 Changed 7 years ago by Joachim Hoessler <hoessler@…>

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.

comment:16 follow-up: Changed 7 years ago by cboos

  • Milestone changed from 0.11.1 to 0.12
  • Owner changed from athomas to cboos
  • Status changed from new to 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.

Changed 7 years ago by Joachim Hoessler <hoessler@…>

Patch against 0.11 trunk r6425 without box around 'pre' fields

comment:17 in reply to: ↑ 16 Changed 7 years ago by Joachim Hoessler <hoessler@…>

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 Changed 6 years ago by Jenn Drummond <jenn@…>

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 Changed 6 years ago by cboos

  • Description modified (diff)

Right, the Timestamp macro is really badly named - #1240

comment:20 Changed 6 years ago by cboos

#7195 requested the same possibility, but for standard fields as well (wiki formatting for summary in this example).

comment:21 Changed 6 years ago by tfoote@…

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>

comment:22 follow-up: Changed 6 years ago by osimons

  • Owner changed from cboos to osimons
  • Status changed from assigned to 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?

comment:23 in reply to: ↑ 22 ; follow-up: Changed 6 years ago by osimons

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! :-)

comment:24 in reply to: ↑ 23 ; follow-up: Changed 6 years ago by Joachim Hoessler <hoessler@…>

  • Cc hoessler@… 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 in reply to: ↑ 24 Changed 6 years ago by osimons

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.

Changed 6 years ago by rblank

Patch agianst trunk adding configurable WikiFormatting for text and textarea custom fields

comment:26 Changed 6 years ago by rblank

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 and textarea 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 with wiki_to_oneliner().
  • textarea fields are formatted with wiki_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.

Changed 6 years ago by rblank

Updated patch

comment:27 Changed 6 years ago by rblank

  • Milestone changed from 0.13 to 0.12
  • Owner changed from osimons to rblank

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 uses field['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.

comment:28 follow-up: Changed 6 years ago by cboos

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 in reply to: ↑ 28 Changed 6 years ago by rblank

Replying to cboos:

A little suggestion for trac/ticket/query.py:

Excellent idea, thanks!

comment:30 follow-up: Changed 6 years ago by rblank

  • Resolution set to fixed
  • Status changed from new to closed

Patch applied in [7563].

comment:31 in reply to: ↑ 30 ; follow-up: Changed 6 years ago by anonymous

  • Milestone changed from 0.12 to 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 in reply to: ↑ 31 Changed 6 years ago by anonymous

Replying to anonymous:

Replying to [comment:30 rblank ]:

Patch applied in [7563].

I have complemented the function,thank you!

comment:33 Changed 6 years ago by rblank

  • Milestone changed from 0.11.2 to 0.12

Please do not change ticket fields without a reason.

comment:34 Changed 6 years ago by osimons

#7954 closed as duplicate, but mentions missing docs - should perhaps be a 0.12/TracTicketsCustomFields page showing new settings?

comment:35 Changed 5 years ago by Mike Stoddart <stoddam@…>

Could this be back-ported to 0.11.x? It's incredibly useful.

comment:36 Changed 5 years ago by cboos

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 Changed 5 years ago by Mike Stoddart <stoddam@…>

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 Changed 5 years ago by rblank

  • Milestone changed from 0.12 to 0.11.3

Backported to 0.11-stable in [7859]. Also, added the .format option to the documentation at TracTicketsCustomFields@25.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed The owner will remain rblank.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from rblank to the specified user.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.