Edgewall Software
Modify

Opened 9 years ago

Closed 7 years ago

Last modified 7 years ago

#10352 closed defect (fixed)

Docs do not reflect difference in wiki processing between custom text and textarea fields

Reported by: jj33@… Owned by: Ryan J Ollos
Priority: lowest Milestone: 1.0.2
Component: ticket system Version: 0.12.2
Severity: minor Keywords: TicketQuery
Cc: Branch:
Release Notes:

Wiki-formatted fields of type textarea are rendered as wiki markup when displayed as a column in a table output from the TicketQuery macro.

API Changes:

Added 'format': 'wiki' to the TicketSystem's property dictionary for the Description field.

Internal Changes:

Description

In http://trac.edgewall.org/wiki/TracTicketsCustomFields it is stated that both type=text and type=textarea fields can be set to format=wiki. This is true, but the contents of the two fields are processed differently. Specifically, macros aren't expanded in type=text fields even if they only generate one line of text.

The choice to have these two fields behave differently seems to be a conscious choice, following the comments and commits from ticket:1791.

This is not consistent with the behavior of built-in fields. Typing a macro into the keywords field will cause the macro to be expanded.

I don't really have a problem with the current behavior, but for consistency's sake, either custom type=text fields should behave the same as built-in fields when format=wiki or the custom field docs should be modified to explain that type=text custom fields don't get full wiki processing that built-in fields and custom type=textarea fields get.

Attachments (1)

t10352.patch (2.3 KB ) - added by Ryan J Ollos 7 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 by Remy Blank, 9 years ago

Milestone: next-minor-0.12.x

in reply to:  description comment:2 by Christian Boos, 9 years ago

Replying to jj33@…:

… Specifically, macros aren't expanded in type=text fields even if they only generate one line of text.

Ok, this is a known limitation and we hope to improve this in future iterations of the WikiEngine.

Typing a macro into the keywords field will cause the macro to be expanded.

??

or the custom field docs should be modified to explain that type=text custom fields don't get full wiki processing that built-in fields and custom type=textarea fields get.

Yes, we should add this information, except that I don't know of any builtin field that gets full wiki processing besides the description (which is a textarea)… certainly not keywords ;-)

comment:3 by John Jetmore <jj33@…>, 9 years ago

certainly not keywords

Wow, you're absolutely right of course. My mistake is that the macro I was testing with returns the original macro text (like [[CRM(1234)]]), but wrapped in a hyperlink. When testing that macro in a custom test field, it returned "[[CRM(...)]]". When I tested it in keywords, it returned a hyperlinked "[[CRM(1234)]]". Unfortunately I didn't mouse over it to see that it's a link to a keyword query, not the link the macro would actually produce. Oops.

Anyway, thanks for looking at this. I guess I just fall back to my original "the docs should state that format=wiki doesn't work the same for type=text and type=textarea".

comment:4 by Ryan J Ollos, 7 years ago

Cc: Ryan J Ollos added

It was recently discussed on mailing list that it would be nice if wikified data for textarea fields (description and custom fields) was formatted to wiki when displayed in a column. Wikified data is currently only formatted to wiki when displayed in a row.

How about the following patch? It doesn't preserve whitespace in the wiki markup, but at least the wiki content is formatted to wiki.

  • trac/ticket/query.py

    diff --git a/trac/ticket/query.py b/trac/ticket/query.py
    index 33b1b27..8a32f13 100644
    a b class Query(object):  
    722722        cols = self.get_columns()
    723723        labels = TicketSystem(self.env).get_ticket_field_labels()
    724724        wikify = set(f['name'] for f in self.fields
    725                      if f['type'] == 'text' and f.get('format') == 'wiki')
     725                     if f['type'] == 'textarea' or
     726                        f['type'] == 'text' and f.get('format') == 'wiki')
    726727
    727728        headers = [{
    728729            'name': col, 'label': labels.get(col, _('Ticket')),

Additional changes that preserve whitespace in the formatted text can be found in log:rjollos.git:t10352.

comment:5 by Jun Omae, 7 years ago

The changes lead API changes for a custom field which is text as wiki in tags/trac-1.0.1/trac/ticket/templates/query_results.html@:84#L77 (header.wikifyheader.wikiline). I think that we should keep it because somebody might customize query_results.html or some plugins might access it using post_process_request.

comment:6 by Ryan J Ollos, 7 years ago

I've made some changes in log:rjollos.git:t10352 to keep wikify variable in the dictionary unchanged. Does that look okay?

I wish I could come up with a better variable name than wikifyblock!

in reply to:  6 comment:7 by Jun Omae, 7 years ago

I've made some changes in log:rjollos.git:t10352 to keep wikify variable in the dictionary unchanged. Does that look okay?

Looks good. Thanks!

comment:8 by Ryan J Ollos, 7 years ago

Milestone: next-minor-0.12.x1.0.2
Owner: set to Ryan J Ollos
Status: newassigned

Thanks for the review. I'll push the change, and try to address the documentation suggestions in this ticket.

in reply to:  3 comment:9 by Ryan J Ollos, 7 years ago

Replying to John Jetmore <jj33@…>:

Anyway, thanks for looking at this. I guess I just fall back to my original "the docs should state that format=wiki doesn't work the same for type=text and type=textarea".

I added a one-liner here. Feel free to improve on it as you see fit.

comment:10 by Ryan J Ollos, 7 years ago

Release Notes: modified (diff)

in reply to:  6 comment:11 by Ryan J Ollos, 7 years ago

Cc: Ryan J Ollos removed
Keywords: TicketQuery added
Release Notes: modified (diff)
Resolution: fixed
Status: assignedclosed

Committed to 1.0-stable in [12235].

Replying to rjollos:

I wish I could come up with a better variable name than wikifyblock!

On merging to the trunk (which I should have checked before committing to 1.0-stable), I found that some significant changes are needed on merge. Some nice cleanup was done in [11330] which makes my patch on the trunk quite a bit cleaner (removing the need for the wikifyblock variable), but the changeset on the trunk is significantly different now. I committed the changes on the trunk in [12236]; please let me know if you spot any issues.

comment:12 by Peter Suter, 7 years ago

Would it make sense to add 'format': 'wiki' to the description field (and perhaps some others as well) so that you don't have to special case it here?

in reply to:  12 comment:13 by Ryan J Ollos, 7 years ago

Replying to psuter:

Would it make sense to add 'format': 'wiki' to the description field (and perhaps some others as well) so that you don't have to special case it here?

Looks like a good idea to me at least. I'll prepare and test the change if there are no arguments against it. It seems most suitable for the trunk rather than 1.0-stable since it results in a change to the API that could effect plugins, so perhaps I should tentatively plan to target the change there?

comment:14 by Peter Suter, 7 years ago

Sounds good.

by Ryan J Ollos, 7 years ago

Attachment: t10352.patch added

comment:15 by Ryan J Ollos, 7 years ago

Proposed refactorings can be found in attachment:t10352.patch, including Peter's suggestion from comment:12 and a minor refactoring to introduce a wikitext variable, which I think makes the code more readable and consistent.

comment:16 by Ryan J Ollos, 7 years ago

API Changes: modified (diff)

Patch from comment:15 committed to trunk in [12244].

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Ryan J Ollos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Ryan J Ollos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.