Impossible de récupérer en LS les PJ d'un mail iPhone

[ubu89]

Bonjour,

Je suis confronté à un gros souci au niveau d'une appli Notes avec un traitement de mail entrant en Lotus Script.

En effet, pour les mails avec PJ envoyées depuis un iPhone, elle ne sont pas détectées par le traitement en question.
Depuis le webmail Gmail, une boite Domino ou depuis mon Black, RAS pourtant.

J'utilise une fonction qui compte les PJ, et qui renvoie désespèrement zéro. On compte à deux endroits :

Code : Tout sélectionner

If doc.HasEmbedded Then
      'Recherche dans le doc
      On Error Goto suiteBody
      Forall o In doc.EmbeddedObjects
         If (o.Type = EMBED_ATTACHMENT) Then PJ = PJ+1
      End Forall
   End If

Code : Tout sélectionner

If rt.Type = RICHTEXT Then
      Forall o In rt.EmbeddedObjects
         If(o.Type = EMBED_ATTACHMENT) Then PJ = PJ+1
      End Forall
   End If

Vu que cela fait plusieurs années que ça tourne et que le problème ne se pose que maintenant, quelque chose a changé du côté de la pomme ?

A noter que "visuellement", les mails en question avec leur PJ ne semblent pas présenter d'anomalies. J'ai aussi essayé de faire un réenregistrement du doc reçu côté UI avant que l'agent planifié ne se déclenche, rien à faire non plus.

Avez-vous déjà été confronté à ce problème ?

Merci à vous !

François

EDIT : Domino est en 8.5.2.2

[ubu89]

J'ai rendu l'agent un peu plus verbeux...

Le premier code, il n'y va jamais. D'ailleurs il fait un type mismatch (ce qui, à la lecture du net, semble etre assez courant, les PJ étant sur le Body) ce pourquoi il y avait un on error goto vers la 2nde condition (c'est un code que j'ai récupéré)

Dans le second, il affiche bien "1454" quand je fais o.Type (1454 étant bien un EMBED_ATTACHMENT) mais, quand c'est un mail iPhone, il ne rentre pas plus loin que la condition If rt.Type = RICHTEXT

[Michael DELIQUE]

salut, es tu certain qu'elles soient dans un champ richtext et pas tout simplement dans le document

[ubu89]

Hello,

J'ai regardé les documents en mode debug Lotus Script.

Dans les mails ne posant pas de problème, je vois bien la propriété EmbeddedObjects de mon Body avec les différentes pièces jointes

Dans mon mail problématique, EmbeddedObjects de Body est vide, comme celui du doc entier.
Le seul moyen que j'ai de retrouver les PJ est de chercher les items $FILE dans mon document.

J'ai essayé de faire ça, sauf que problème, pour les mails "sains", ça me compte une seconde fois une PJ. Apparemment le EmbeddedObjects du body est une sorte de lien vers un élément $FILE.

J'ai donc l'impression que j'y peux pas grand chose... Compliqué

[Michael DELIQUE]

salut,

les $file sont les champs systeme ou sont réélement stocker les pieces jointes

[ubu89]

Bonjour,

J'ai mis au clair ce matin mon problème qui, à l'origine, était présenté comme un bug sur une appli de traitement de mail réalisée et maintenue chez un client. Hors, j'ai reproduit sans difficulté ce problème dans l'environnement Domino de ma société.

Premier cas de test, un mail "sain" envoyé depuis le webmail Gmail vers ma boite pro :


HasEmbedded du Document est true, et vu que la propriété EmbeddedObjects du NotesDocument ne vaut rien, c'est que les pièces jointes sont dans le Body.

All right !


Jusque là pas de problème. Le traitement mis en place depuis plusieurs années a toujours fonctionné parfaitement de cette sorte.

Maintenant, un e-mail gentiment envoyé par un ami depuis son iPhone avec une image en pièce jointe.


Jusqu'ici, même constat que le mail précédent. HasEmbedded est true et la propriété EmbeddedObject du NotesDocument est vide.

Sauf qu'ici, on ne trouve rien dans le Body !


Mais comment Notes peut-il afficher la pièce jointe dans l'IHM ? $FILE, évidemment :


J'imagine que c'est un champ système (ce que confirme Michael) dans lequel est vraiment stocké le fichier, alors que EmbeddedObjects n'est qu'une référence. Cette impression est à mon sens exacte car j'ai aussi un $FILE dans mon mail "sain" et je doute que je stocke une pièce jointe par deux fois :


Bref, voici donc mon problème, très ennuyant, et qui ne se pose qu'avec iPhone. Ca ressemble à un bug de Domino au moment de transformer un mail iPhone en document Notes conformément au DOM de Lotus. Autrement dit je suis confronté à une petite impasse...

[roubech]

ouvrir le mail provenant de l'iPhone
menu Vue \ Afficher \ Source de la page
regarder le code source MIME pour comprendre comment le mail est structuré (ou nous le montrer si tu as du mal à t'y retrouver)

[ubu89]

Je connaissais pas cette fonctionnalité de source de page. Et pour me punir de cela, cette option est grisée, quoi que je fasse (même en copiant le doc sur une mailbox sur laquelle je suis gestionnaire)

[ubu89]

On m'a donné deux extraits :

Mail Lotus

Code : Tout sélectionner

--=_alternative 0029C180C1257936_=--
--=_mixed 0029C180C1257936_=
Content-Type: image/jpeg; name="IMG_0809.JPG"
Content-Disposition: attachment; filename="IMG_0809.JPG"
Content-Transfer-Encoding: base64

Mail Apple

Code : Tout sélectionner

--Apple-Mail-1--566436917
Content-Type: image/jpeg;
       name=photo.JPG
Content-Disposition: inline;
       filename=photo.JPG
Content-Transfer-Encoding: base64

Sans y connaître quoi que ce soit en mailing pur, je pense pouvoir dire qu'il n'y a pas de différence notable qui justifierait cette différence à l'instanciation du NotesDocument

[ubu89]

Je comprends pas qu'un truc pareil :

Code : Tout sélectionner

Content-Type: application/octet-stream;
       name=Test.doc
Content-Disposition: attachment;
       filename=Test.doc
Content-Transfer-Encoding: base64

ne se retrouve ni dans les EmbeddedObjects du doc, ni dans les EmbeddedObjects du body

[roubech]

la différence que je vois qui ne dois pas être anodine, c'est attachment ou inline pour content-disposition

http://forum.dominoarea.org/convertion- ... 26168.html

[ubu89]

Ca le fait aussi avec ces pièces jointes là :

Code : Tout sélectionner

--Apple-Mail-852855B2-0FAE-4976-8E6C-361B5D07E024
Content-Type: application/octet-stream;
       name=Test.doc
Content-Disposition: attachment;
       filename=Test.doc
Content-Transfer-Encoding: base64

Dans les faits, je pense avoir contourné mon pb de pièces jointes en faisant un Evaluate de @AttachmentNames qui me permet d'utiliser la méthode getAttachement du NotesDocument à partir du nom du fichier joint.
Donc j'arrive maintenant à extraire et enregistrer des PJ d'un iPhone de type doc ou pdf, bien que ça n'explique toujours pas leur absence dans la structure objet du document.

Sauf que l'iPhone semble manifestement envoyer en inline les images (et peut-être d'autres trucs), dans quel cas ils ne sont pas dans la liste renvoyée par @AttachmentsNames (même avec le paramètre documenté)

@AttachmentNames
Returns the operating system file names of any files attached to a document. If there are multiple files attached, the names are returned as a multiple-value text list.

Syntax
@AttachmentNames( excludeMIMEBody )

Parameters
excludeMIMEBody

Boolean. Optional.

Specify True (1) to exclude large MIME parts that are stored as attachments (but displayed in-line). This is the default.
Specify False (0) to include large MIME parts that are stored as attachments (but displayed in-line).

Donc en lieu et place de mon problème, qualifiable de contourné, je me retrouve avec un nouveau problème : récupérer les PJ de type "inline"...

[ubu89]

Elément de réponse ce matin :
http://www-10.lotus.com/ldd/dominowiki. ... WEBP48.htm

En mettant ce paramètre sur 1, les images, même petites, qui arrivent en inline sont quand même considérées par Notes comme des PJ et deviennent récupérables grâce à la liste renvoyée par @AttachmentNames

Même si le (gros) problème de base n'est toujours pas expliqué, je commence donc à avoir un réel contournement

EDIT : Fausse bonne idée, vu que du coup on se retrouve avec comme pièce jointe le petit GIF qui traine en signature...