Edgewall Software

Opened 19 years ago

Last modified 15 years ago

#1791 closed enhancement

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

Reported by: anthony.vito@… Owned by: Christian Boos
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 Christian Boos)

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

Change History (23)

by anthony.vito@…, 19 years ago

comment:1 by anthony.vito@…, 19 years ago

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 by Markus Tacker <m@…>, 18 years ago

See also #925.

comment:3 by Emmanuel Blot, 18 years ago

Cc: fsdfds removed

comment:4 by Alec Thomas, 18 years ago

Owner: changed from Jonas Borgström to Alec Thomas

by seb at tail-f.com, 17 years ago

comment:7 by seb at tail-f.com, 17 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 seb at tail-f.com, 17 years ago

Patch against trac 0.9.5 to enable wiki formating of custom fields

comment:8 by sid, 17 years ago

#3668 was marked as duplicate of this ticket.

comment:9 by alexandre.franke@…, 17 years ago

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

comment:10 by alexandre.franke@…, 17 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 nathan(dot)wells at dtn.com, 17 years ago

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

comment:11 by nathan(dot)wells at dtn.com, 17 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:12 by Christian Boos, 17 years ago

Milestone: 0.11

Food for PyCon'ers

comment:13 by anonymous, 17 years ago

Cc: khundeen@… added

comment:14 by victorhg@…, 16 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 Joachim Hoessler <hoessler@…>, 16 years ago

Patch against 0.11 trunk r6425 that allows wiki style custom fields

comment:15 by Joachim Hoessler <hoessler@…>, 16 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.

comment:16 by Christian Boos, 16 years ago

Milestone: 0.11.10.12
Owner: changed from Alec Thomas to Christian Boos
Status: newassigned

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 Joachim Hoessler <hoessler@…>, 16 years ago

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

in reply to:  16 comment:17 by Joachim Hoessler <hoessler@…>, 16 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 Jenn Drummond <jenn@…>, 16 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 Christian Boos, 16 years ago

Description: modified (diff)

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

Note: See TracTickets for help on using tickets.