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

[anthony.vito@…]

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

[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.

[Markus Tacker <m@…>]

See also #925.

[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

[seb at tail-f.com]

Patch against trac 0.9.5 to enable wiki formating of custom fields

[sid]

#3668 was marked as duplicate of this ticket.

[alexandre.franke@…]

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

[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.

[nathan(dot)wells at dtn.com]

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

[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.

[cboos]

Food for PyCon'ers

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

[Joachim Hoessler <hoessler@…>]

Patch against 0.11 trunk r6425 that allows wiki style custom fields

[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.

[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]" />)?

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.

[Joachim Hoessler <hoessler@…>]

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

[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.

[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!

[cboos]

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

[cboos]

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

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

[osimons]

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?

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

[Joachim Hoessler <hoessler@…>]

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?

[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.

[rblank]

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

[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.

[rblank]

Updated patch

[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.

[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, 

[rblank]

Replying to cboos:

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

Excellent idea, thanks!

[rblank]

Patch applied in [7563].

[anonymous]

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?

[anonymous]

Replying to anonymous:

Replying to [comment:30 rblank ]:

Patch applied in [7563].

I have complemented the function,thank you!

[rblank]

Please do not change ticket fields without a reason.