Alert Processor vs Attachment File system can't send EMails properly

Description

Hi, I found one bug related to sending EMails by Alert Rules.

BUG:
FileNotFound Exception will raise when Alert engine tries to send email for more recipients and these recipients have set notification type as Notice+Email and also there has to be an attachment to be sent.

Problem is that attachment file system provider will delete temporary file after storing it as an attachment for first user and then file not found exception will raise when trying to send it for next users (Take a look at AlertProcessor.notifyUsers where you can see for loop).

I am wondering if could be the good solution to overload storage provider save method by new parameter Delete - it can be default true to keep current behaviour and only for this case call it with as false.

Environment

None

Attachments

1

Activity

Show:

Tomáš Švikruha October 2, 2015 at 5:20 AM

Can you please check attached patch? If I understood you wrong, I can change it.

Thanks

Carlos Ruiz October 1, 2015 at 12:06 PM

Yes , your solution is ok too, confirmed that's the behavior of AttachmentDBSystem.

Also saw that finishing the OSGi JVM is not deleting the temp files, so maybe is good to do the cleanup at least on the AlertProcessor and Scheduler.

Regards,

Carlos Ruiz

Tomáš Švikruha October 1, 2015 at 6:33 AM

And what If we just remove deleting of temporary AttachmentFileSystem and OS would become only responsible for deleting files? Because these files are dropped automatically by OS, we don't need to care about it. So if we don't create temp files in other directories, everything should be fine, or am I wrong?

Only use case which comes to my mind is what if more processes will try to create temp file with same name and try to work with it? Is this even possible?

Carlos Ruiz September 30, 2015 at 12:54 PM

,

There is a simple solution for this and it would be copying the alerted file before adding the attachment entry.

But, this seems more like a bug deleting the file (AttachmentFileSystem.save:97) - the program is assuming the file being attached is temporary and deleting it (this is old behavior inherited from adempiere MAttachment.saveLOBDataToFileSystem), but I can imagine cases where certain program could attach a file that is not temporary, and the result here is that the user will find the file removed.

For a more proper solution, I would suggest removing the lines that are deleting the file - and instead of that, we must ensure the temporary files are removed on AlertProcessor class.

Same behavior must be checked on Scheduler.runProcess and MWFActivity.performWork (the ACTION_AppsReport part).

Also in AbstractProcessDialog the getDownloadFiles() are being deleted, so, maybe we need to check also if possible to delete the temporary download files created on PackOutProcess and ImportCSVProcess - but this seems more complex as that is not synchronous operation. (Maybe not a big deal - the default AttachmentDBSystem is not deleting those temporary files anyways).

Regards,

Carlos Ruiz

Norbert Bede September 29, 2015 at 5:45 PM

need advice to this bug. we test it lot investigate tens of hours, just we wondering you would suggest us a right direction, then we can fix and test it. thanks

Fixed

Details

Assignee

Reporter

Labels

Due date

Priority

Created September 21, 2015 at 2:20 PM
Updated December 1, 2015 at 11:03 PM
Resolved October 3, 2015 at 1:27 PM