Not all rules are processed

[soetheman]

Scenario: Send an email messagr containing an image with a different filetype compared to the filetype being defined in the first rule for this sender in the config section of the script.

Symptom: In case of multiple rules for one email sender, and the first rule causes a mismatch, the script only interpretes the first rule (resulting log entry: "INFO: Rejecting file 'aaa.png not matching.*.jpg$"). The subsequent rules (in this example the one for the .png filetype) are ignored. Loop terminated. Why?

I'm not able to correct the code myself. Could anyone review/update the coding?

Thanks in advance!

[soetheman]

Andreas, Could you comment on this issue? Thx, regards, Paul,

[ahochsteger]

@soetheman, can you give me some more information to analyze the issue (e.g. processing logs)? I've updated the respective section in the README file with information about how to acquire the logs.

[soetheman]

Andreas,

We created a config file for this test containing the following three processing rules:

1. Store all .jpg attachments from [email protected] to the folder "Graphics"
2. Store all.JPG attachments from [email protected] to the folder "Graphics"
3. Store all .png attachments from [email protected] to the folder "Graphics"

Scenario1, receiving the file 'scenario1.jpg' (lower case filetype), works ok as it matches the first rule. Scenario2 fails with the following msg: "Rejecting file ‘scenario2.JPG not matching.*.jpg$" Scenario3 fails with the following msg: "Rejecting file ‘scenario3.png not matching.*.jpg$" We notice that only the first rule is being processed. See the logbook.pdf attached here.

Thanks and regards, Paul,

P.S., We are using the code version you committed on 26 May 2018

Gmail2Gdrive issue#24 test results.pdf

[ahochsteger]

Hi Paul,

the processing of Gmai2GDrive is based on the assumption that a message can only be processed by a single rule since it must mark the message (really the whole thread) as processed to prevent processing it over and over again.

But I am currently working on a refactoring in #28 to provide a more flexible way to specify the storage location which may also solve your problem too.

Can you have a look at it and give me feedback if this would work for you too?

Regards, Andreas

[jowouters]

Hi Andreas,

I do not understand how #28 will change this behaviour where only 1 rule is executed after which the thread is marked as processed, preventing selection of the same thread for execution of other rules.

In order to solve the issue, I think we need to rethink the workflow.

I see 2 possible solutions:

1. Use a 'per rule' processedLabel: A specific label that is set after execution of a specific rule will prevent selection of this thread for the next execution of the same rule; but will not prevent selection of this thread for other rules. This has the smallest impact on the current code, but does not seem to be a very elegant solution.

2. Refactor the selection process: first select the threads involved in ALL rules, next run through these threads and execute all the relevant rules. Only after all rules for a specific thread are executed indicate the thread as processed.

What do you think ? In case you agree on this solution (my preference would be no 2) I could write the code needed, for review.

[ahochsteger]

Hi Paul,

the proposal in #28 introduces tree levels of matching compared to just one like before:

1. Search filter for threads (as it is now): Defines the level of processing (which is atomic by the possibilities the Gmail API provides)
2. Regular expression matching on message attributes: Allows to further filter the messages within threads
3. Regular expression matching on attachment attributes: Allows to define multiple storage rules to store individual attachments to different locations within a thread or message

Especially number 3 should give you the flexibility you need. But you will have to put both attachment storage rules within the same search rule since the thread still can be processed only once. This overcomes the problems you sketched in your solution 1 while keeping the simple iterative processing (that can be interrupted at any time) that would have to be changed for your solution 2.

I'm already pretty far at implementing the proposal in #28 and will push the changes to a branch for tests and review soon.

Please let me know, what you think.

Regards, Andreas

[jowouters]

Ok, great Andreas, Looking forward to your code, and ready to test it.

Kind regards, Jo

[ahochsteger]

I'm closing this issue since GMail2GDrive is discontinued and has been superseded by the much improved Gmail Processor. It provides all the possibilities mentioned above. See the Getting Started Guide as well as the Reference Docs for more information