Answers.Body: <p>This sounds like a duplicate, or at least new variation in 4.7.1 of, <a href="https://civicrm.stackexchange.com/questions/8084/formatting-of-formatted-text-in-print-case-and-activiy-audit">Formatting of formatted text in print case and activiy audit</a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-10T10:05:43.930Z
Answers.Text: Could be new variation, but not a duplicate. If I understood the linked problem right, the tags are shown in a different "screen" (print case vs show activity). The linked issue was also present, iirc, before 4.7, whereas the one I'm reporting didn't show in 4.6.
Answers.UserDisplayName: T. Mich.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-11T14:42:18.933Z
Answers.Text: Yes I meant the same underlying reason, that fortunately/unfortunately HTML allows both formatting and executable code to be mixed, and so letting users enter it themselves means it needs to be validated, and the simplest solution is to escape it all, which affects both formatting and executable code. Since HTML is unlikely to change, and that's how WYSIWYG editors work, another way would be something that leaves formatting but removes the rest, but it's not clear (to me) whether the editor should do that or civi somewhere, or smarty/twig, or other.
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-12T19:33:40.543Z
Answers.Text: You're probably right. Problem is, this new variation is worse than the old one, as now there's no way to view the affected activities without all the tags, which in some cases mean they're nearly impossible to read.
Answers.UserDisplayName: T. Mich.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-09T05:33:49.913Z
Answers.LastActivityDate: 2016-02-09T05:33:49.913Z
Answers.LastEditDate: 2017-04-13T12:53:13.167Z
Answers.UserDisplayName: Demerit
Body: <p>It seems that any activity created in 4.7.1 (not sure about earlier 4.7 versions) sometimes shows all formatting tags when viewed.</p>
  
  <p>I reproduced this both in Wordpress and Drupal demos by creating a new case. When viewing the "Open case" activity, the &lt; p> tag was shown, as were tags for strike-through, italics and bold, as well as h2 heading. Same happened when adding and then viewing a single activity added to a contact.</p>
  
  <p>What is strange is that adding or editing an activity to an existing case went fine, no tags were shown in the subsequent view.</p>
  
  <p>As I was able to reproduce this on the demo, I believe it is a bug in CiviCRM. It can be rather big issue, since it can render activities with more formatting nearly impossible to read. I'd report this as a bug to jira directly, but instructions say first post here, so here I post.</p>
  
  <p>edit: The affected activities also show all tags on their print versions (of the single activity).</p>
  
  <p>edit2: I would even try to somehow fix this myself with my limited php/html knowledge, but I can't even find the file responsible for this. :(</p>
  
  <p>edit3: Just a small update, issue is still present in 4.7.2, <a href="https://issues.civicrm.org/jira/browse/CRM-17978" rel="nofollow">possible related/same issue on Jira</a></p>
  
Tags: <civicase><activities><issues>
Title: Formatting tags shown in activity view
ThreadText: # Formatting tags shown in activity view
  
  (Asked by: username_0 on 2016-02-08)
  
  It seems that any activity created in 4.7.1 (not sure about earlier 4.7 versions) sometimes shows all formatting tags when viewed.
  
  I reproduced this both in Wordpress and Drupal demos by creating a new case. When viewing the "Open case" activity, the < p> tag was shown, as were tags for strike-through, italics and bold, as well as h2 heading. Same happened when adding and then viewing a single activity added to a contact.
  
  What is strange is that adding or editing an activity to an existing case went fine, no tags were shown in the subsequent view.
  
  As I was able to reproduce this on the demo, I believe it is a bug in CiviCRM. It can be rather big issue, since it can render activities with more formatting nearly impossible to read. I'd report this as a bug to jira directly, but instructions say first post here, so here I post.
  
  edit: The affected activities also show all tags on their print versions (of the single activity).
  
  edit2: I would even try to somehow fix this myself with my limited php/html knowledge, but I can't even find the file responsible for this. :(
  
  edit3: Just a small update, issue is still present in 4.7.2, [possible related/same issue on Jira](https://issues.civicrm.org/jira/browse/CRM-17978)
  
  **Tags:** civicase, activities, issues
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2016-02-09. Score: 1
  
  This sounds like a duplicate, or at least new variation in 4.7.1 of, [Formatting of formatted text in print case and activiy audit](https://civicrm.stackexchange.com/questions/8084/formatting-of-formatted-text-in-print-case-and-activiy-audit)
  
  > **Comments:**
  > **username_0**: Could be new variation, but not a duplicate. If I understood the linked problem right, the tags are shown in a different "screen" (print case vs show activity). The linked issue was also present, iirc, before 4.7, whereas the one I'm reporting didn't show in 4.6.  
  > **username_1**: Yes I meant the same underlying reason, that fortunately/unfortunately HTML allows both formatting and executable code to be mixed, and so letting users enter it themselves means it needs to be validated, and the simplest solution is to escape it all, which affects both formatting and executable code. Since HTML is unlikely to change, and that's how WYSIWYG editors work, another way would be something that leaves formatting but removes the rest, but it's not clear (to me) whether the editor should do that or civi somewhere, or smarty/twig, or other.  
  > **username_0**: You're probably right. Problem is, this new variation is worse than the old one, as now there's no way to view the affected activities without all the tags, which in some cases mean they're nearly impossible to read.  
  
  ---
  
  