mirror of
https://github.com/chatmail/core.git
synced 2026-04-23 00:16:34 +03:00
6e7f63dba7
fix https://github.com/deltachat/deltachat-core-rust/issues/2463 fix #2116 The email could be private (i.e. only sent to me) or non-private (i.e. also sent to sb else). Also, it could be a classical email or a chat message. Below, I'm describing for each of the four combinations whether they should be assigned to a chat by create_or_lookup_group() or lookup_chat_by_reply(). Because I needed to use these function names a lot, I shortened them to l:group() and l:by_reply() in this PR description. (!) means todo, (! -> Done) means I fixed something. ## Private classical email: l:group() and l:by_reply() must both take care not to put it into group l:group() no (! -> Done), l:by_reply no (! -> Done) except for classical MUA replies to two-member-groups, they should be put into the parent group ### wrt alias-support: A private classical email is very probably not going to be an answer to email that went to an alias address: Suppose Alice writes to support@example.com. support@example.com forwards to bob@example.com and claire@example.com. When Bob answers, he will _probably_ answer `To: alice@example.com, support@example.com` (=> it's a non-private classical email). With this PR, if he does only answer `To: alice@example.com`, (=> it's a private classical email), Alice's DC will show the answer in the private chat with Bob. Which actually makes more sense than showing it in the support@example.com chat I think. Also, if it was shown in the support@example.com chat, then Alice would answer in the support@example.com chat, then Claire would get Alice's message but not Bob's and therefore miss some context. That being said - **I could change this**. Pretty easily actually, I would just have to remove the call to `is_probably_private_reply()` from `lookup_chat_by_reply()`. Didn't think through all edge cases yet, but should work. ## Private chat message: l:group() has to put private chat messages into the group: It won't mistakenly put a message there (because it can rely on Chat-Group-Id). Currently, `is_probably_private_reply()` returns true for private chat messages, but l:group still has to put them into the group chat. (it's not nice that the function called is_probably_private_reply returns true for all private chat messages, but I didn't find any nicer solution) l:by_reply() must not assign it to sth special l:group yes, l:by_reply no By the way, for chat messages, `try_getting_grpid()` doesn't look at InReplyTo or References, in order not to put private chat-message replies into the group chat. For alias-support, the same goes as for the private classical emails. ## Non-private classical email: Just put it into any group, and if there is none, create one. _Off-topic: We currently don't look at the recipients lists, which means that a message can easily be assigned to a group although it was not sent to all group members. One day we could somehow compare the recipients list with the members list, but that needs some more discussing (esp. what do we do if they don't match? Create a new group? Show a hint in the UI?) and is nothing for a bug-fixing PR like this one._ l_group yes, l_by_reply yes, even for outgoing messages (! -> Done, this also was the issue reported by @gerryfrancis in the testing group: Outgoing messages were not put into a chat by In-Reply-To/References, which is correct for chat messages, but for non-private classical outgoing emails, a new ad-hoc group was created everytime. So, I added this: https://github.com/deltachat/deltachat-core-rust/pull/2465/files#diff-e7606b521f6710ddc6e5236ba5d7eefc917b7ad744b9e71762fd42830c55485bR703-R711) ## Non-private chat message: Can be put into chat by l:by_reply() because it must be a group message l:group yes, l:by_reply yes (to make alias support work if the support person uses DC) Nothing to test or fix here; we have to put chat group messages into the group, which is trivial. And we have to make sure that alias-support works, which already was well tested.
Delta Chat Rust
Deltachat-core written in Rust
Installing Rust and Cargo
To download and install the official compiler for the Rust programming language, and the Cargo package manager, run the command in your user environment:
$ curl https://sh.rustup.rs -sSf | sh
Using the CLI client
Compile and run Delta Chat Core command line utility, using cargo:
$ RUST_LOG=repl=info cargo run --example repl --features repl -- ~/deltachat-db
where ~/deltachat-db is the database file. Delta Chat will create it if it does not exist.
Configure your account (if not already configured):
Delta Chat Core is awaiting your commands.
> set addr your@email.org
> set mail_pw yourpassword
> configure
Connect to your mail server (if already configured):
> connect
Create a contact:
> addcontact yourfriends@email.org
Command executed successfully.
List contacts:
> listcontacts
Contact#10: <name unset> <yourfriends@email.org>
Contact#1: Me √√ <your@email.org>
Create a chat with your friend and send a message:
> createchat 10
Single#10 created successfully.
> chat 10
Single#10: yourfriends@email.org [yourfriends@email.org]
> send hi
Message sent.
If yourfriend@email.org uses DeltaChat, but does not receive message just
sent, it is advisable to check Spam folder. It is known that at least
gmx.com treat such test messages as spam, unless told otherwise with web
interface.
List messages when inside a chat:
> chat
For more commands type:
> help
Development
# run tests
$ cargo test --all
# build c-ffi
$ cargo build -p deltachat_ffi --release
Debugging environment variables
-
DCC_IMAP_DEBUG: if set IMAP protocol commands and responses will be printed -
DCC_MIME_DEBUG: if set outgoing and incoming message will be printed -
RUST_LOG=repl=info,async_imap=trace,async_smtp=trace: enable IMAP and SMTP tracing in addition to info messages.
Expensive tests
Some tests are expensive and marked with #[ignore], to run these
use the --ignored argument to the test binary (not to cargo itself):
$ cargo test -- --ignored
Features
vendored: When using Openssl for TLS, this bundles a vendored version.nightly: Enable nightly only performance and security related features.
Language bindings and frontend projects
Language bindings are available for:
- C
- Node.js
- Python
- Go
- Free Pascal
- Java and Swift (contained in the Android/iOS repos)
The following "frontend" projects make use of the Rust-library or its language bindings: