asked on

Preventing MailSend on edit of document

Experts,

Am working on an literature request/inventory database and need guidance on this issue -- somewhat urgent (need to finish prototype today) I'm using formula language to send alerts to users based on the following:

When Status = "Submitted", then send alert to Faciliator that a request has been submitted. The form is then locked down, and only the Facilitator can make changes.

When Status = "Completed", then send alert to requester that it has been processed.

By default, I have "Submitted" in the Status field which is computed, and is a hidden section that only the Facilitator can edit (is hidden when IsNewDoc)

I have my MailSend code in PostSave -- this prevents alerts from being sent if I use the QuerySave and a field does not pas validation.

My problem is this. If the Faciliator wants to make an edit to the document, but it has not yet been completed -- how do I prevent the MailSend code, from being sent again? I tried creating a computed hidden field -- that uses @SetDocField, but probably had the set up wrong.

Below is my code to send the alert -- as it currently stands, which does not prevent mail from being sent again, if changes are made to the document, but it has not been processed. There are only two choices for the LiteratureStatus field -- either Submitted or Completed
------------------------------------------------------------------------------------------------------------------------
In PostSave:

@If(LiteratureStatus="Submitted";@MailSend(Facilitator;ProjectManager;Null;"New Literature Request";
"A New Request for Literature has been created by "+ DocAuthor+@NewLine+"Please click the link to vierw the request and take the required action to process --> ";Null;[IncludeDoclink]);
@MailSend(DocAuthor;"";"";"Literature Request Completed!"; "Your request for literature has been processed. " +@NewLine+"You can click this link to view the status on the request document ---> ";Null;[IncludeDoclink]))
-----------------------------------------------------------------------------------------------------------------------------------

Thanks in advance,
AliciaVee

Sjef Bosman

If it's the current document you want to update, don't use @SetDocField but @SetField.

I think it's best to add a field MailSent, with a date value, so you know if and when a mail is sent out. Then you can check on that field if a mail is actually sent or not.

AliciaVee

ASKER

sjef,

Hmm? A little confused. Okay, so I need two alerts sent. When a user submits a request, an alert goes out. So, if I use the MailSent field, it will always be valid with a date -- same as the status will always be" Submitted".

Maybe if you give me an example on my Formula script, I can see how this might work?

Sjef Bosman

Also a little confused here, to be honest. It seems to me there are two things that influence the sending of a mail, or even three: there is a Status field, there could be a MailSent field, and there may be a button(??). Or is everything to be handled automatically?

What works for me is to set up an action table for all combinations of statuses, a State Transition Diagram.

Statuses: Action (s)
Status=Submitted, MailSent=empty Send mail, Set MailSent to Now
Status=Submitted, MailSent!=empty -

I may be totally off here, don't hesitate to say so!

AliciaVee

ASKER

sjef,

Yeah, I'm just learning, so I'm taking scripts/examples out of several books I have, in addition to searching on EE and other net areas.

So, I am not using buttons on the form, instead I am just using the Save event of a document. In one of my books, the example says to add the @MailSend code in the QuerySave event by doing this:

@If(@IsNewDoc;@MailSend(Facilitator;ProjectManager;Null;"New Literature Request";
"A New Request for Literature has been created by "+ DocAuthor+@NewLine+"Please click the link to vierw the request and take the required action to process --> ";Null;[IncludeDoclink]);Null)

This option would work fine for new docs, and then it would solve my problem that the Facilitator will not get this message again, because even if changes were made, since it is not a new doc, no alert would be sent 'again' to the faciliator.

The problem I have with this code is that putting it on the QuerySave event will send the alert, if the form does not pass validation, and send again and again. And, maybe the user decides not to save at all and exits -- and no request is actually saved, but the Facilitator received an alert.

So, maybe there is another way to prevent QuerySave from happening unless the form has passed validation? Is this an easier way to go?

AliciaVee

Sjef Bosman

As it seems, the QuerySave occurs before the validation, indeed. To force validation of the fields, add a
@Command([ViewRefreshFields]);
as the first line. Might work...

ASKER CERTIFIED SOLUTION

qwaletee

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

AliciaVee

ASKER

qwaletee,

Yes -- your solution is a good one and I have worked it into my form -- and it works! Yay! However, I'd like to tweak it a little as follows:

The request forms will be entered by our Customer Service Reps. Typically, it will be done because someone (customer or sales person) wants literature mailed out. So, for CSRs, they do not need a draft status. They will enter and the LiteratureStatus will be set as default "Submitted". This field is in a section that the facilator will edit. And, it is hidden with @IsNewDoc, so the CSRs do not see or edit until the form is submitted.

Okay, now my concern is that the Faciltator, may go into the form, and maybe make some edits, or comments, but the request is not completed, and he forgets to go to the combo box (dropdown list) to change this value to Draft. And -- then what I am trying to prevent, I cannot control.

So, in using your theory, I thought I would add the following on the Edit button:

@Command([EditDocument]);
@SetField(LiteratureStatus;"Draft");
@Command([ViewRefreshFields])

So, then it puts the field in Draft mode. I would use a text field, computed, with default as "Submitted".

Then, if he saves, the DRAFT value should be stored. yes? No! It didn't work for me :(

Then, in finishing this up, I would put this in the Completed Button:

@Command([EditDocument]);
@SetField(LiteratureStatus;"Completed");
@Command([ViewRefreshFields]);
@Command([FileSave]);
@Command([FileCloseWindow])

Well -- this didn't work either. What am I doing wrong? Can you help tweak? Worst case -- I have a working solution, but again, I'm trying to prevent the facilitator from not forgetting to put the document in draft mode, before he saves, otherwise the alert will go out to him again.

Hope you are following me.

Waiting anxiously for your comments...

AliciaVee

Sjef Bosman

AliciaVee,

> I would use a text field, computed, with default as "Submitted".
Computed fields have no default value. Their value is computed every time the form is evaluated or refreshed. What you can do is set it to Computed when Composed. Such a field will be given only its initial value, and the field's formula will never be computed again.

Sjef

AliciaVee

ASKER

sjef,

okay -- I understand this. But I'm not clear how this will help me with my code? I want the followig to occur:
User completes form and submits/save.
The form/request triggers an @MailSend formula that sends mail to Faclitor.
The faciltator 'may' edit the document -- so the form should be put in edit mode -- marked draft (I want to do this automatically -- right now, it works manually using qwaltee's solution).
Then, when the process is completed, I want the status to change to Completed, and then a final email sent to the original requester letting them know their request was submitted.

I guess what this is similar to is a routing system, but not as elaborate or as complicated.

Anyone?

Sjef Bosman

I suppose the form should only trigger an @MailSend when the right conditions are met, i.e.
- previous status was "Draft" or "Submitted"
- new status is "Completed"

True?

AliciaVee

ASKER

sjef,

Yes -- correct! But once submitted -- I dont want it submitted again if changes are made on the document (processing/Draft) so then I'd like to be able to update the status field in these cases when Facilitator wants to edit the document, but it is not yet completed.

Sjef Bosman

You could create buttons or actions for all functions you need, they can change the status any way they want, but the bottom line is this (in 'formula' code) in the PostSave:
@If(previousStatus="Draft":"Submitted" & status="Completed"; @MailSend...; "");
@SetField("previousStatus"; status);

For this to work, you need to have a hidden field previousStatus, computed, with value
@If(@IsDocumentBeingLoaded; Status; previousStatus=""; "Draft"; previousStatus)
so it will get the value of Status when the document is opened.

The mail will then be sent in the PostSave.

AliciaVee

ASKER

qwaletee,

I winded up using your solution with the dropdown (combo) box option. User requests literature, and the Staus field is default "Submitted". Facilitator, gets an alert, goes into the document and begins processing. When he edits, he changes the status to: Being Processed. Once he is finished with the request, the goes back in and changes Status to "Completed". Simple solution. Not as automatic as I would have liked -- but it was easy, and hey -- I'm still a beginner at this stuff!

Thanks again.
AliciaVee