Each attachment-to-be-removed may have a different model object
representing the message, and there may have also been previous
deletions without refreshing these models. So asking whether the
message has any attachments left might give an out-of-date answer. Fix
this by doing an explicit database query to count remaining
attachments, and refreshing the message model before deletion if
necessary.
_I recommend reviewing this with whitespace changes disabled._
Signal has renamed its primary branch to `main`. This updates references
to the old name, `master`, to either reference `main` or a specific
commit hash.
I also fixed a couple of small whitespace issues in a file I was
editing.
Previously, MediaGallery built "album" objects as it loaded items,
adding them to the album as they were loaded. This could be a problem
if items were ever *re*loaded, because then the old model would be in
the album and the new model in the top-level "sections" table. Having
potentially-inconsistent models floating around already isn't great,
but MediaGalleryAlbum and MediaGalleryItem also formed a reference
cycle.
Now, MediaGalleryAlbums are built on demand when showing the "page"
view by walking forward and backwards from an item. GalleryRailView
uses object identity to check whether we've changed albums, so
MediaPageViewController now keeps track of the most recent album and
checks its items to see if it needs to refresh it. This is a linear
check, but that's just not that bad for a message album, which will
only ever have a handful of attachments. (Even if this gets up to,
say, 100 items, that's just not that much work for a modern phone.)
There was a bug that caused avatars to be
encrypted with the wrong key, causing them to be
undecryptable both by ourselves and others.
That bug (IOS-2262) was fixed in #4078.
The purpose of this PR is to replace the broken
avatars with good ones.
PNI identity keys for existing accounts are uploaded the first time
the primary notices that it doesn't have a PNI identity key. However,
if that upload is interrupted, the local state would be out of sync
with the server. We can try to be more careful about that, but *this*
PR will manually get them out of that state by explicitly doing a
profile fetch for our own PNI and seeing if the identity key we get
back is what we expect. If not, we upload it again as if it were the
first time.
The existing index was not useful for the query we needed. Running this
query would open a write transaction for several seconds on every
launch. This new index should be much faster.
We can only *really* trust this once the certificate validates, and
even then the certificate could be out of date. So now the mapping is
only treated as high-trust when the inner messages decrypts
successfully too.
If the CreatePreKeysOperation fails on registration, we don't ever
retry it, and registration is considered to have failed anyway. If it
fails for the first time we create PNI keys, though, the identity key
will still be saved locally, and therefore we won't try again until
regular pre-key rotation happens. To guard against this, wipe a
newly-generated identity key if the upload to the service fails.
If an existing account ever generates a new PNI identity key, it
should immediately tell its linked devices. This is faster than
waiting for a sync request, and also better for keeping linked devices
on the same page.
This small change cleans up two things for the donate URL:
1. Moves it into a constant in `TSConstants`
2. Adds a trailing slash to the URL (because the server will redirect
you without one)
I think these cleanups are useful by themselves, but I'll be using the
constant again in an upcoming change and split this off into its own
small commit.
Made sure I could still open the URL in the app.
This test-only change adds tests for [`Subscription`][0].
I did this because I'll be adding additional behavior to this struct and
want to be ready to test that logic. I think this is a useful change on
its own, however, so I split it out into its own change.
[0]: 2693c55232/SignalMessaging/Subscriptions/SubscriptionManager.swift (L70-L104)
This upgrades [GRDB][0] from v4.3.0 to v5.23.0, the latest version.
I closely followed the [migration guide][1] and stole from a prior
attempt at this upgrade. I also made sure to test the media gallery,
because that allegedly had problems before.
[0]: https://github.com/groue/GRDB.swift
[1]: 6d3f309cad/Documentation/GRDB5MigrationGuide.md
_I recommend reviewing this with whitespace changes disabled._
We have a kill switch that disables badge acquisition. If that kill
switch is active, we show a one-time donation view.
That kill switch has been off since January of 2021, so I think we can
remove this one-time donation view. That lets us remove hundreds of
lines of code, but it will also make future donation-related changes a
bit easier.
This isn't protecting any local state and wasn't being used
consistently, and it can result in lock inversion deadlocks if
-readWithUnfairLock: is called within a database write transaction.
This isolates all of the Obj-C runtime code in its own function.
If a class doesn’t have any properties, `class_copyPropertyList` may
return `NULL`. Previously, this would have resulted in an error while
force unwrapping the result, but all `BaseFlags` subclasses have
properties, so that wasn’t a problem in practice. Now, an empty array
will be returned, which seems correct when there aren’t any properties.
The class can be computed from `self`, and the lookup block is always
the same (essentially `self.value(forKey:)`), so there’s no need to
provide separate implementations for each subclass. The superclass can
provide a single implementation for all subclasses to share.
Messages always have an isGroupStoryReply of true or false (1 or 0),
but non-messages don't have this field, and GRDB treats that as NULL
rather than falling back to the table default.
