First thing I would recommend is (if at all possible) moving your
attachments to an attachment form (as a child record) *or* slyly convince
your users to only attach one file per main record, but it can be a zip
file with 1-to-X files compressed within... (I'm not serious about that
last part, folks).

Moving the attachments around is pretty easy, presuming you are working
with the current email engine.

I've built something quite similar to what you are trying to do that covers
three different forms. On two of the forms, I have attachments going to a
shared attachment form, linked to the targeted parent record. That's very
easy. However, one form *has* to have the attachment field directly on the
parent form by user demand (unfortunately). This is still easy, but takes a
couple of extra steps.

My entire scheme hinges on the end user including the Request-ID of the
targeted record in the subject line of the incoming email. Ultimately, you
just need some way to uniquely identify the target record and schema.

On submit of an "Email Message" record (low in the firing order), I parse
that request ID (and schema based on the unique Request ID prefix) out of
the 'Subject' field and into some hidden fields on the email message form.

Then, (still on submit to the email message form) check the "Email
Association" form for entries related to the "Email Message" record. The
only association entries we generate are when an attachment is included -
you may have to add a qualification at your site. If you find an
Association record, you can get he GUID of the attachment record.

Once you have the GUID of the attachment record, it's a fairly simple
process of pushing a display only flag/field on the attachment record. Then
you can push the attachment slot (by it's $FieldID$) to another attachment
slot in the system.

If you are limited to 4 slots on the parent form, then before the
attachment push, you can locate an available slot by checking each slot (in
turn) for a $NULL$ value. You'd just have to build one push filter per
potential slot.

If you get more than one attachment per email, then you will want to either
accomodate that with a goto loop, or a push that modifies all matching
records (whatever you prefer).

The biggest stumbling block I encountered was trying to determine the order
of record creation by the email engine when an attachment bearing email was
processed. The logs I captured shows it creates records in the following
order:
1. The attachment record is created
2. The association record is created
3. The email message record is created.

So, if you key on the email message form for the initial triggering event,
you should be okay. It probably sounds harder than it actually is.
Apologies if I've only served to confuse things.

-JD-


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)

Couldn Remedy have done this a bit mot userfriendly ...Thanks, I will take look at what u are writing, and .. have to improve ny knowledge about all this emailform and how they are related ...Imcoming seemes to be a bit more complex that outgoing.

L ars

-----Ursprungligt meddelande-----
Från: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG]För J. D. Hood
Skickat: den 29 december 2004 16:42
Till: arslist@ARSLIST.ORG
Ämne: Re: Q:WF Email Engine: Incoming


First thing I would recommend is (if at all possible) moving your
attachments to an attachment form (as a child record) *or* slyly convince
your users to only attach one file per main record, but it can be a zip
file with 1-to-X files compressed within... (I'm not serious about that
last part, folks).

Moving the attachments around is pretty easy, presuming you are working
with the current email engine.

I've built something quite similar to what you are trying to do that covers
three different forms. On two of the forms, I have attachments going to a
shared attachment form, linked to the targeted parent record. That's very
easy. However, one form *has* to have the attachment field directly on the
parent form by user demand (unfortunately). This is still easy, but takes a
couple of extra steps.

My entire scheme hinges on the end user including the Request-ID of the
targeted record in the subject line of the incoming email. Ultimately, you
just need some way to uniquely identify the target record and schema.

On submit of an "Email Message" record (low in the firing order), I parse
that request ID (and schema based on the unique Request ID prefix) out of
the 'Subject' field and into some hidden fields on the email message form.

Then, (still on submit to the email message form) check the "Email
Association" form for entries related to the "Email Message" record. The
only association entries we generate are when an attachment is included -
you may have to add a qualification at your site. If you find an
Association record, you can get he GUID of the attachment record.

Once you have the GUID of the attachment record, it's a fairly simple
process of pushing a display only flag/field on the attachment record. Then
you can push the attachment slot (by it's $FieldID$) to another attachment
slot in the system.

If you are limited to 4 slots on the parent form, then before the
attachment push, you can locate an available slot by checking each slot (in
turn) for a $NULL$ value. You'd just have to build one push filter per
potential slot.

If you get more than one attachment per email, then you will want to either
accomodate that with a goto loop, or a push that modifies all matching
records (whatever you prefer).

The biggest stumbling block I encountered was trying to determine the order
of record creation by the email engine when an attachment bearing email was
processed. The logs I captured shows it creates records in the following
order:
1. The attachment record is created
2. The association record is created
3. The email message record is created.

So, if you key on the email message form for the initial triggering event,
you should be okay. It probably sounds harder than it actually is.
Apologies if I've only served to confuse things.

-JD-


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)


UNSUBSCRIBE or access ARSlist Archives at http://www.ARSLIST.org
(Support: mailto:support@arslist.org)