[CNB] [MU] Mailrepository: filter content

[chibenwa]

https://issues.apache.org/jira/browse/JAMES-4092

[hungphan227]

It seems MailRepository interface does not support listing mails by specific conditions

[chibenwa]

No need to change this. Just do this onto the presentation layer (webadmin).

No need to be optional, I just want to easily filter this...

[hungphan227]

No need to change this. Just do this onto the presentation layer (webadmin).

No need to be optional, I just want to easily filter this...

Does this mean we have to fetch all mails from storage and do filter in memory?

[chibenwa]

Does this mean we have to fetch all mails from storage and do filter in memory?

This is what it means. Though filtering is only done on metadata. Loading all mail content is not acceptable.

Maybe the current MailRepository API would not allow for filtering wwithout retrieving the mail content, we might need to provide methods for this in MailRepository...

So IMO:

• Provide a defaultmethod in MailRepository listing the mails and doing 100% in memory filtering
• Provide a smarter implementation reading only Cassandra metadata

API suggestion:

public interface MailRepository {
   interface MailReposory.Condition extends Predicate<Mail> {} 
   class UpdatedBefore implements MailReposory.Condition {
       private final ZOnedDateTime date;
       // ...
   }
   class UpdatedAfter implements MailReposory.Condition {
       private final ZOnedDateTime date;
       // ...
   }
   // ... 

    Iterator<MailKey> list(MailReposory.Condition condition) throws MessagingException;
}

Let's do it only for listing. Lets not do it for reprocessing nor deletes as it will be super verbose!

[hungphan227]

As an administrator I want:
    To list emails in a repository in matching sender pattern
    To list emails in a repository in matching recipient pattern

Anything in regular expression could be used?

[chibenwa]

Anything in regular expression could be used?

Let's not go with REGEXP

Let allow extact match: [email protected]

Prefix match: *@linagora.com

[hungphan227]

curl -XGET /mailRepositories/var%2Fmail%2Ferror%2F/mails?updatedBefore=2d
curl -XGET /mailRepositories/var%2Fmail%2Ferror%2F/mails?updatedAfter=2d

what does 2d mean?

[chibenwa]

It's pretty explicit: it means the mail had been updated in the last 2 day, so the update date is more recent than this.

[hungphan227]

It's pretty explicit: it means the mail had been updated in the last 2 day, so the update date is more recent than this.

Ah ok got it:

updatedBefore=2d means updatedDate < currentDate - 2d
updatedAfter=2d means updatedDate > currentDate - 2d

Only 'd' is accepted or any other units (h,m,...) ?

[chibenwa]

Only 'd' is accepted or any other units (h,m,...) ?

Of course other units of DurationParser are accepted.

[hungphan227]

PR for listing mails: https://github.com/apache/james-project/pull/2600/files

[hungphan227]

Apply it also for DELETE:

curl -XDELETE /mailRepositories/var%2Fmail%2Ferror%2F/mails?remoteHost=mx.domain.tld

And for Reprocess All (PATCH):

curl -XPATCH 127.0.0.1:8000/mailRepositories/var%2Fmail%2Ferror%2F/mails?action=reprocess&processor=transport&remoteHost=mx.domain.tld

Similar to listing api, we will apply all query paras (updatedBefore, updatedAfter, sender, ...) to delete and reprocess api, right?

[chibenwa]

Yes but the big issue is carrying that through the task API. I really fear the upcoming boiler plate here....

Have a look if you want but in a separate PR please.

[hungphan227]

Yes but the big issue is carrying that through the task API. I really fear the upcoming boiler plate here....

Have a look if you want but in a separate PR please.

I see that boiler plate as well but of course it can still be done. Do you still want to implement those api? Are they neccessary?

[chibenwa]

Let's keep it for later

[hungphan227]

Done: get api
Remaining tasks: delete and reprocessing api