Previously, sending a gift badge was not a durable operation, which
meant that crashes/failures could cause users to have their payment
methods charged without actually sending the badge.
Now, the flow is split up into two steps: non-durable parts before the
charge is attempted, and durable parts afterward.
The high-level flow is:
1. Prepare the payment, which involves a couple of repeatable network
requests.
2. Enqueue a job with the prepared payment, that:
1. Charges the payment method (idempotently)
2. Requests a receipt credential (idempotently)
3. Enqueues a gift message, and optionally a text message
3. When the job completes, open the conversation in the UI.
If you've got the `giftBadgeSending` flag enabled, you can now send gift
badges to anyone who has the capability.
This commit doesn't complete the feature, though. It is missing:
- Proper durability and error handling (to be addressed separately)
- Saving of receipts
- A few other cleanups
This makes a few small changes to `OWSRequestFactory.boostCreatePaymentIntent()`:
- Adds tests
- Rewrites the function in Swift
I made sure I could do a boost (in staging) in the simulator.
* Little fix for context menu
* Add 'My Stories' section to stories tab
* Add new story thread types
* Show stories in conversation picker
* Support for sending stories
* Update story list when sending stories
* Add basic 'My Stories' view controller
* Initial stories settings screens
* Consolidate TSPrivateStoryThread and TSMyStoryThread into one class
* Require an explicit read transaction to initialize an outgoing message
* Fix linting
* Allow enabling group story from internal settings
* Fix tests
* PR Feedback
This respects the `giftBadges` capability when trying to send gift
badges. In other words, it prevents you from sending gift badges to
someone who lacks the capability.
The bulk of this change involves fetching and saving of this new
capability. The rest of the code involves showing it on the "choose
recipient" screen (and some debug screens).
The gist is:
```diff
-foo = foo + 1
+foo += 1
```
Most of the violations were in generated files, so I changed and re-ran the generator.
A few of these violations required implementing some new methods, which I added tests for.
See [the docs for this rule][0].
[0]: https://realm.github.io/SwiftLint/shorthand_operator.html
In c5bdf6c094, we started to show errors
when a subscription failed to renew because of a charge failure.
Now, we show additional text depending on what the charge failure was.
For example, if you had an invalid card number, we show a special string
for that.
This fixes violations of [SwiftLint's `is_disjoint` rules][0], which
says that `set1.intersection(set2).isEmpty` should be replaced with
`set1.isDisjoint(with: set2)`.
I also took one additional step in a few cases: `isDisjoint` can be
called [with any `Sequence`][1], not just a `Set`. This let me remove
some conversions to `Set`. In other words:
```diff
-mySet.isDisjoint(with: Set(myArray))
+mySet.isDisjoint(with: myArray)
```
[0]: https://realm.github.io/SwiftLint/is_disjoint.html
[1]: https://developer.apple.com/documentation/swift/set/2853831-isdisjoint
When someone sends a message to your PNI, your responses (from your
ACI) must include a PNI signature, and the sealed sender certificate
you use during this period should include your phone number. This
confirms to the other user that your ACI is associated with your PNI.
This commit adds the state tracking that and ensures that both
TSOutgoingMessage and OWSUDManager check that state when building 1:1
messages and choosing certificates, respectively. Later commits will
set and clear this flag as needed.
This adds the first screen for badge gifting. It lets you see the gift
badge, pick the currency, and advance to the next screen.
It also adds a skeleton for the next screen, so there's somewhere to
advance to, but that screen is unfinished.
All of this is behind disabled flags, so this should have no user
impact.
Currently, when your subscription expires due a charge failure, we
incorrectly tell you that it's due to inactivity. This fixes that, by
telling you about the charge failure.
This is a bit difficult to test on its own, so I:
- Faked out the smallest pieces I could in an effort to test states
manually
- Created `BadgeErrorSheetState` which is pretty thoroughly tested
There are some Swift-only features that are part of these protocols, so
they were split into Obj-C and Swift variants. However, the class itself
only reports conformance to the Swift variant, which leads to warnings
when using the class in Objective-C.
- Each property is checked with `OWSAssertDebug` in the initializer.
They are also initialized in a simple way when the app is launching,
so any that are `nil` would be noticed quickly.
- Getting the shared environment also checks it with `OWSAssertDebug`.
In addition, it’s currently an implicitly-unwrapped optional in Swift,
so it’d already be crashing if it’s unexpectedly nil.
This removes calls to `arc4random` and `arc4random_uniform` and replaces
them with calls to `Int.random` or equivalent.
These are a little less readable, which may be [why SwiftLint doesn't
like them][0]. (SwiftLint calls them "legacy", possibly because they're
not strong random number generators, but I couldn't find a clear
explanation for this anywhere, including [the original PR][1].)
This is the kind of change that's error-prone, so I wrote [a simple
script to help avoid regressions][2]. The script runs 10,000 iterations
of the old and new RNG and compares the ranges, reporting differences.
(Some differences are likely, like the ones that involve floats; others
are very unlikely to have differences.)
`git grep arc4random | grep swift` returns no results after this change.
Same for [everything else SwiftLint checks for][3].
[0]: https://realm.github.io/SwiftLint/legacy_random.html
[1]: https://github.com/realm/SwiftLint/pull/2419
[2]: https://gist.github.com/EvanHahn-Signal/9c75c9f484f4778149cbde3eafc9b285
[3]: ea6cc50890/Source/SwiftLintFramework/Rules/Idiomatic/LegacyRandomRule.swift (L23-L27)
`Searcher`'s `matches` method needed a little cleanup. It iterated over
a collection twice, when it could do with only iterating once (and could
return early).
This fixes that, which also fixes a violation of [Swiftlint's
`reduce_boolean` rule][0].
[0]: https://realm.github.io/SwiftLint/reduce_boolean.html
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.
PniIdentity requests get sent from linked devices every time they are
launched, and primaries that don't understand them will drop them.
However, it's possible for several such requests to end up in the
queue, and we should avoid sending several responses (it's harmless
but wasteful). Wait to send any PniIdentity sync messages until
message processing has finished.
