Community
Participate
Working Groups
Build ID: M20070212-1330 Steps To Reproduce: 1. Enable markup in you're JIRA (eg Confluence style markup) 2. Write a ticket with some markup 3. You'll see these codes: HTML2TextReader.listItemPrefix etc. More information: I'm not sure if it's possible to actually render the markup properly. But, it should be a simple fix to at least strip the HTML2TextReader.* codes out.
*** Bug 202298 has been marked as a duplicate of this bug. ***
Eugene: are you doing this one or should we reassign?
Please feel free to reassign if you find time to do it before I get to this.
Assigning to Inbox. If someone (possibly me) starts working on this assign to yourself.
Steffen: I wrote some of that HTML2TextReader transformation, please bug me about how to get rid of it.
Bumping priority and milestone due to the votes.
*** Bug 207713 has been marked as a duplicate of this bug. ***
Note that this bug makes the rich editor pretty much unusable for jira repos with wiki markup widely used in descriptions. This is because any change (e.g. adding a comment) will update the issue with the corrupted description.
Steffen: let's discuss how we could improve on this for 2.3.
The HTML2TextReader codes were removed as part of fixing bug 189695. Proper support for issues that have markup in the description will require more involved changes. Currently information about tickets is parsed from an XML representation. If rich-text rendering is enabled for the repository that representation only provides rendered HTML but not the original markup. That means it will be necessary to use either a SOAP or XML-RPC call to get the source markup.
Steffen, can you please clarify why it was necessary to remove HTML2TextReader code? To me it seem possible to tweak HTML2TextReader to get acceptable results and add missing handling for li elements to show lists properly. Without that the only option for showing description and comments is to use browser widget (I don't think that using xmlrpc for synchronizing tasks would be as performant as parsing rss) and use xmlrpc on demand only when user want to edit description or comments.
Eugene, please file a separate report if you require proper rendering of the HTML. First of all I would like to get into a state where it is possible to edit issues that have markup in the description, i.e. send the original markup to the repository and not HTML.
I truly don't see why rendering of html markup should be a separate issue. From the common sense, rendering should be fixed before editing. From my experience with current jira connector, issues with markup are practically not readable in the rich task editor.
Steffen: please do file a new bug as you suggest. I agree that rendering of markup is separate. Afaik the key use case is that while for descriptions it is valuable to preserve HTML formatting (to avoid information loss) given our current UI for displaying comments it is best to discard the HTML in the UI layer. Then later we consider using the Browser widget based rendering of comments, which will require the formatting to be preserved. I'll comment more on bug 189695.
Opened bug 215262 to improve presentation of markup.
Committed first pass at this: - If rendered markup is detected for an attribute an extra server round-trip is made to retrieve the source markup. This allows editing of the source markup (e.g. Wiki text) and submission to the server without causing data conversion. - For comments HTML tags are stripped from the rendered markup. That is how the implementation worked so far except that bullet points of lists are now rendered as '-' instead of 'HTML2TextReader.listItemPrefixItem'. These changes will need additional testing particularly with older versions of JIRA that ship with a different version of the JIRA RPC plug-in.
The direction and all the code pieces seem right, but I think it would be better to move all code related to html manipulation and markup detection out of RssContentHandler into the task data handler. Also, Issue.isMarkupDetected() sound a bit odd and maybe it is better to call it hasMarkup()
(In reply to comment #17) > The direction and all the code pieces seem right, but I think it would be better > to move all code related to html manipulation and markup detection out of > RssContentHandler into the task data handler. As I have commented on bug 189695 the RSS feed adds tags (a, br) that are neither part of the rendered HTML markup nor part of the source markup and should therefore be filtered in the RSS parser. Unless you can convince me that this assumption is incorrect I will keep the current architecture. > Also, Issue.isMarkupDetected() sound a bit odd and maybe it is better to call it > hasMarkup() Yes, that's a better name. We could also consider a type, e.g. enum Format { Html, Text }.
(In reply to comment #18) > As I have commented on bug 189695 the RSS feed adds tags (a, br) that are > neither part of the rendered HTML markup nor part of the source markup and > should therefore be filtered in the RSS parser. > Unless you can convince me that this assumption is incorrect I will keep the current architecture. I still don't understand your rationale why it should they be "filtered" in the rss parser. The responsibility of that class is to retrieve task data from RSS, but not to guess about text markup. Basically, the rss feed return html that is ready to be shown (i.e. with the browser widget as Mik suggested in comment #14 above), but filtering that you've added is practically negate such option. I do realize that there are some oddities between data in Issue instance used with task submission and with Issue instance returned from the rss parser. You probably attempting to make those the same, but I don't think it is achievable in all cases (especially when markup is used), so it is better to preserve information that we've got and reuse it as much as possible instead of throwing it away.
As per comment #16 support for Wiki markup is available in the latest weekly build.
