[Tickets #14053] HTML body treated differently for new and updated notes with ActiveSync

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://bugs.horde.org/ticket/14053
------------------------------------------------------------------------------
  Ticket             | 14053
  Created By         | skhorde at smail.inf.fh-bonn-rhein-sieg.de
  Summary            | HTML body treated differently for new and updated notes
                     | with ActiveSync
  Queue              | Mnemo
  Version            | 4.2.6
  Type               | Bug
  State              | Unconfirmed
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


skhorde at smail.inf.fh-bonn-rhein-sieg.de (2015-07-14 10:01) wrote:

If one creates a new note via ActiveSync, in function import of  
lib/Api.php the HTML is denoted to plain text via:

         case 'activesync':
             // We only support plaintext
             if ($content->body->type ==  
Horde_ActiveSync::BODYPREF_TYPE_HTML) {
                 $body =  
Horde_Text_Filter::filter($content->body->data, 'Html2text');
             } else {
                 $body = $content->body->data;
             }

However, there is no such check in function replace() some lines below.

There is at least one way to produce the error:

1) create a new note on the ActiveSync device. It is denoted to plain  
text in the GUI, but remains unchanged on the device.
2) change the note on the device, Its body is sync'ed as HTML to Mnemo.

So the handling is inconsitent.

====

I don't know, if changed / converted notes should be flagged as  
changed and are sync'ed back to the device immediately, in order to  
reflect the changes. Now the user works with the original note on the  
device (incl. long subject and fancy HTML), but Horde keeps a possibly  
shortened subject and denoted body. The reference to "subject" applies  
to bug #14041.