feat(backend): add scheduled send functionality

[amaninyumu1]

issue
issue

[marclaporte]

Will this work with JMAP as well?

[kroky]

Yes, anything we add for IMAP, we should check JMAP support as well. Overall, it is built on top of IMAP, so it should work but please check if the new Scheduled folder is OK for JMAP.

Overall, the code is good but I have one concern - it only sends out while you are actively using Cypht and it seems to warn of unsent/scheduled messages each time you leave a page (onbeforeunload). That would be annoying for the end user. I believe this comment #576 (comment) proposes using sendAt support from jmap servers or scheduled send - if it is supported, we use it, if not, we fallback to a more annoying option. At any rate, it should be configurable.

This could be fully-supported in the Cypht-Tiki integration where there could be a Tiki command run periodically in the scheduler that checks and sends scheduled messages.

[josaphatim]

@kroky I added a commit to fix issue concerning onbeforeunload event and also add the option to change schedule time or send the message immediately. Can you check please.

[marclaporte]

@amaninyumu1 If you need help with JMAP, please reach out to @Shadow243 as he set up a JMAP server for testing.

[marclaporte]

@amaninyumu1 "This branch has conflicts that must be resolved"

[marclaporte]

@amaninyumu1 This branch has conflicts that must be resolved

[amaninyumu1]

Hello @marclaporte , @kroky I resolved the conflicts. please review

[kroky]

There are still conflicts and I believe big part of the reason is #1266 - @jacob-js , can you check if some handlers in this PR need to be updated according to the router changes you did in 1266?

[amaninyumu1]

Hello @marclaporte all tests pass successfully

[kroky]

I am fine with the changes. If @mercihabam approves as well, we can merge.

[mercihabam]

@amaninyumu1 in the future, when making code changes, please ensure the commit history is clean by avoiding combining all changes into the initial commit.

Please pay attention to the above statement.

Have a commit for each thread you resolve, that way, it is easy to keep up with the scope of the changes you do.

[mercihabam]

@amaninyumu1 you need to correct the commit history before I give you any other round of review.

[amaninyumu1]

Hello @mercihabam I merged the two commits that were before to make one. Maybe it's me who doesn't understand the maneuver to follow. please guide me

[mercihabam]

@amaninyumu1 I did not ask you to combine the commits into one. I'm telling you to do the opposite. Please re-read carefully the related comments!

[amaninyumu1]

I understand I misunderstood the comment. To be honest about the commit history, I don't know how to go about it. please guide me. THANKS

[amaninyumu1]

Hello @mercihabam , @kroky . please merge this PR if there is anything to fix we can do it later, we risk returning to square one with this presence repeating conflicts

[mercihabam]

@amaninyumu1, I'm sorry, but we cannot merge this as long as it still contains poor code that risks introducing regressions.
Also, the commit history! I still need to emphasize that aspect. You recently pushed a commit, but what changes did it bring to your existing code?

[amaninyumu1]

if you can't merge this while it still contains poor code that risks introducing regressions. I'm ready to fix that for the PR to merge. But when you say that it's the commit history that blocks evolution... I don't understand that

[marclaporte]

But when you say that it's the commit history that blocks evolution... I don't understand that

Please see: #1091 (comment)

The current situation is causing more work for the reviewers because they need to re-review everything instesd of just your latest modifications. Once everything is done, there will be the option to squash commits.

[amaninyumu1]

Okay I understand @marclaporte , soon I will make a commit for each change. because going back to the old history risks losing the current changes.