Merge master branch
#4874
Merged
Merge master branch
#4874
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Implement #4188 BREAKING CHANGE: Remove unused DC_STR_PROTECTION_(EN)ABLED* strings BREAKING CHANGE: Remove unused dc_set_chat_protection()
When `cargo test` is executed, all examples are built by default to ensure that they can be compiled. This is a documented and expected behaviour, even though it was previously reported as a bug: <rust-lang/cargo#6675> In particular, `examples/simple.rs` is built into a 67M binary `target/debug/examples/simple`. This is unnecessary to do so every time you change a line in the `deltachat` crate and want to rerun the tests. Workaround is to run `cargo test --tests`, but it is easy to forget and is not discoverable unless you read the "Target Selection" section of `cargo help test`. We have a maintained example at https://github.com/deltachat-bot/echo, so there is no need for an example in the core repository.
1:1 chats are automatically created as protected if the contact is verified, there is no need to explicitly do this. Plus, by removing this call, the test also tests that automatically creating 1:1 chats as protected works.
If the verification is broken, `can_send()` is false. But if the user was typing a message right when a verification-breaking message came in, the UI still needs to be able to save it as a draft. Steps to reproduce the bug: - Set a draft - Your chat partner breaks verification - Go back to the chats list - Go to the chat again - Accept the breakage - Expected: The draft is still there - Bug behavior: The draft is gone
Rust 1.66 is required by constant_time_eq 0.3.0.
looks like this was fogotten when changing the chat protection stock strings
Correctly handle messages with old timestamps for verified chats:
* They must not be sorted over a protection-changed info message
* If they change the protection, then they must not be sorted over existing other messages, because then the protection-changed info message would also be above these existing messages.
This PR fixes this:
1. Even seen messages can't be sorted into already-noticed messages anymore. **This also changes DC's behavior in the absence of verified 1:1 chats**. Before this PR, messages that are marked as seen when they are downloaded will always be sorted by their timestamp, even if it's very old.
2. protection-changed info messages are always sorted to the bottom.
**Edit:**
3. There is an exception to rule 1: Outgoing messages are still allowed to be sorted purely by their timestamp, and don't influence old messages. This is to the problem described at [*].
Together, these rules also make sure that the protection-changed info message is always right above the message causing the change.
[*] If we receive messages from two different folders, e.g. `Sent` and `Inbox`, then this will lead to wrong message ordering in many cases. I need to think about this more, or maybe someone else has an idea. One new idea that came to my mind is:
* Always sort noticed messages under the newest info message (this PR sorts them under the newest noticed message, master sorts them purely by their sent timestamp)
* Always sort unnoticed messages under the newest noticed message (that's the same behavior as in this PR and on master)
* Always sort protection-changed info messages to the bottom (as in this PR)
However, after a talk with @link2xt we instead decided to add rule 3. (see above) because it seemed a little bit easier.
No one used it anymore, and all occurences I could find (on GitHub)[https://github.com/search?q=%22is_verified_ex%22&type=code&p=1] are either forks of deltachat-core-rust or of deltachat-core (which is the old C core).
This change removes all traces of dc_keyring_t, which was a C implementation of dynamically sized array.
The return value was never used.
Opening the same account (context) from multiple processes is dangerous, can result in duplicate downloads of the same message etc. Same for account manager, attempts to modify the same accounts.toml even if done atomically with may result in corrupted files as atomic replacement procedure does not expect that multiple processes may write to the same temporary file. accounts.toml cannot be used as a lockfile because it is replaced during atomic update. Therefore, a new file next to accounts.toml is needed to prevent starting second account manager in the same directory. But iOS needs to be able to open accounts from multiple processes at the same time. This is required as the "share-to-DC extension" is a separate process by iOS design -- this process may or may not be started while the main app is running. Accounts are not altered however by this extension, so let's add to the `Accounts::new()` constructor an `rdwr` parameter which allows to read the accounts config w/o locking the lockfile.
Bumps [tokio-util](https://github.com/tokio-rs/tokio) from 0.7.8 to 0.7.9. - [Release notes](https://github.com/tokio-rs/tokio/releases) - [Commits](tokio-rs/tokio@tokio-util-0.7.8...tokio-util-0.7.9) --- updated-dependencies: - dependency-name: tokio-util dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [thiserror](https://github.com/dtolnay/thiserror) from 1.0.47 to 1.0.49. - [Release notes](https://github.com/dtolnay/thiserror/releases) - [Commits](dtolnay/thiserror@1.0.47...1.0.49) --- updated-dependencies: - dependency-name: thiserror dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [regex](https://github.com/rust-lang/regex) from 1.9.5 to 1.9.6. - [Release notes](https://github.com/rust-lang/regex/releases) - [Changelog](https://github.com/rust-lang/regex/blob/master/CHANGELOG.md) - [Commits](rust-lang/regex@1.9.5...1.9.6) --- updated-dependencies: - dependency-name: regex dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [smallvec](https://github.com/servo/rust-smallvec) from 1.11.0 to 1.11.1. - [Release notes](https://github.com/servo/rust-smallvec/releases) - [Commits](servo/rust-smallvec@v1.11.0...v1.11.1) --- updated-dependencies: - dependency-name: smallvec dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [sha2](https://github.com/RustCrypto/hashes) from 0.10.7 to 0.10.8. - [Commits](RustCrypto/hashes@sha2-v0.10.7...sha2-v0.10.8) --- updated-dependencies: - dependency-name: sha2 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [webpki](https://github.com/briansmith/webpki) from 0.22.0 to 0.22.2. - [Commits](https://github.com/briansmith/webpki/commits) --- updated-dependencies: - dependency-name: webpki dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [proptest](https://github.com/proptest-rs/proptest) from 1.2.0 to 1.3.1. - [Release notes](https://github.com/proptest-rs/proptest/releases) - [Changelog](https://github.com/proptest-rs/proptest/blob/master/CHANGELOG.md) - [Commits](proptest-rs/proptest@v1.2.0...v1.3.1) --- updated-dependencies: - dependency-name: proptest dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Resolved conflicts due to asyncio removal.
Release 1.125.0
This approach uses a param field to enable forcing the sticker `viewtype`. The first commit has the memory-only flag implemented, but this flag is not persistent through the database conversion needed for draft/undraft. That's why `param` has to be used. follow up to #4814 fixes #4739 --------- Co-authored-by: Septias <scoreplayer2000@gmail.comclear>
…erver_after Test was written for stable branch and has to be adjusted for verified 1:1 chats branch
Release 1.126.1
r10s
approved these changes
Oct 25, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changelog
I have generated a changelog for overview of what changed.
Features / Changes
Config::SendSyncMsgswithSyncMsgs(#4817).API-Changes
No one used it anymore, and all occurences I could find (on GitHub)[https://github.com/search?q=%22is_verified_ex%22&type=code&p=1] are either forks of deltachat-core-rust or of deltachat-core (which is the old C core)..
MsgId.delete_from_db()private.kindas a tag for all union typesBuild system
sphinxto 7.1.2.yumif it is available.CI
Documentation
Fixes
.
Miscellaneous Tasks
Other
configured_addrRefactor
deltachatcrate.Tests
test_qr_join_chatto check that the group is not verified.