We now show the onboarding intro requesting the user to accept the Terms of Use
& Privacy Policy with the new button "Explore the new Status" if the user had
installed any version of Status older than the one from this PR and had at
least one profile.
Fixes https://github.com/status-im/status-mobile/issues/21113
status-go PR https://github.com/status-im/status-go/pull/5766
In practice, this means:
- Users coming from Status v1 who had at least one profile will see the
modified onboarding intro screen and will need to accept the terms to proceed.
- Users who already installed v2 and are upgrading to this PR build (devs & QAs
mostly) and who had at least one profile will also see the modified intro
screen and will need to accept the terms to proceed.
Areas that may be impacted
- Onboarding
Steps to test:
The criteria used during development:
1. Given that user Alice had installed v1 and had one or more profiles.
2. When she installs v2 and opens it, she sees the new onboarding intro and must
agree to the terms to enable the button "Explore the new Status".
3. After pressing the button, she can login as usual in any of her profiles.
1. Given that user Alice already upgraded from v1 and accepted the terms.
2. When she reopens the app she does not need to accept terms again and can
immediately sign-in with any of her profiles.
1. Given that user Alice already upgraded from v1 and accepted the terms.
2. When she deletes all profiles, she sees the onboarding intro for users who
have not upgraded, i.e. she has to agree to terms and she sees the usual two
buttons "Create profile" and "Sync or recover profile".
1. Given that user Alice never installed Status.
2. When she installs v2, she sees the normal onboarding intro screen, where she
has to accept the terms and she sees two buttons "Create profile" and "Sync
or recover profile".
3. When she reopens the app, she doesn't see anymore the screen to accept terms.
https://github.com/status-im/status-go/compare/6e056348...1ef2434b
This commit adds support for pushing centralized metrics to mixpanel.
It uses an interceptor and only picks a few selected events to push
through.
In order to test:
1) Create an account in the app
2) Go to Settings->Privacy
3) Enable metrics
You should now see the events on the mixpanel dashboard (login with your
status-im account for access).
Only some example events are tracked, they are just for testing
fixes#19802
Contract Tests are failing with missing symbols runtime error on `MacOS` after `golang` version was upgraded to 1.20
A simple hack fix such a case is to use `go 1.19` only to build the status-go library that is used specifically for these integration tests.
Its ugly but it works and unblocks devs from running tests locally.
- execute `make test-contract` on MacOS and it should not fail.
not needed since this impacts only the integration tests.
- macOS
status: ready
## Summary
any `yarn` command calls `node-pre-gyp rebuild` which prints out this warning message :
```
make[1]: Entering directory '/Users/siddarthkumar/code/experiments/status-mobile/build'
CXX(target) Release/obj.target/status_nodejs_addon/modules/react-native-status/nodejs/status.o
../modules/react-native-status/nodejs/status.cpp:1153:11: warning: ignoring return value of function
declared with 'warn_unused_result' attribute [-Wunused-result]
func->Call(isolate->GetCurrentContext(), v8::Null(isolate), argc, argv);
^~~~ ~~~~~~~~~~~~~
1 warning generated.
```
This happens due to return value of `func->Call` here :
https://github.com/status-im/status-mobile/blob/52a6f5c17d3055a98a403505a354cde135b1966f/modules/react-native-status/nodejs/status.cpp#L1153
not being used.
Which is not a huge red flag but produces a warning which is not nice when looking at logs and can be sometimes misleading for other devs.
This commit fixes that warning by assigning return value of that function and checking if its empty or not.
## Testing notes
not needed since this impacts only the integration tests.
## Platforms
- macOS
status: ready
We log the entire signal data when it arrives from status-go in the native
layer, where our Clojure logging mechanism is unavailable. Sometimes, the
developer may not want that much noise during development, e.g. when managing
integration or contract tests.
This commit removes the native calls to log signals and adds a timbre
(log/debug ...) call in the event handler :signals/signal-received. We know
timbre will elide log calls at compile time given the minimum log level set,
therefore, we don't need to worry about performance because we will log signals
at the debug level only.
This PR does a few things:
1) Add fetch messages implementation on any kind of chat. It's behind a
toggle (on by default) as design is still unsure whether we want it,
but it's very useful for debugging.
2) Allow setting light client from mobile
It also partially remove node config management from the clojure part,
as it's better if that's not explicitly managed by clients.
Some parts are still relying on it but they are not functional
(keycard), while others are still using it and will need to be updated
eventually (syncing), in order to get rid completely of node config.
Sets fleet to shards.test
https://github.com/status-im/status-go/compare/90c31afe...1adcf02f
Icaro Motta