feat(accounts)_: Persist acceptance of Terms of Use & Privacy policy #5766

ilmotta · 2024-08-24T00:02:39Z

Summary

The original GH issue status-im/status-mobile#21113 came from a request from the Legal team. We must show to Status v1 users the new terms (Terms of Use & Privacy Policy) right after they upgrade to Status v2 from the stores.

Solution

The solution we use is to create a flag in the accounts table, named hasAcceptedTerms. The flag will be set to true on the first account ever created in v2 and we provide a native call in mobile/status.go#AcceptTerms, which allows the client to persist the user's choice in case they are upgrading (from v1 -> v2, or from a v2 older than this PR).

Check out the flow in Figma https://www.figma.com/design/o4qG1bnFyuyFOvHQVGgeFY/Onboarding-for-Mobile?node-id=13865-45479&t=mok7OSFMqussN7aC-0

Mobile PR feat(onboarding): Present Terms to users upgrading from v1 status-mobile#21124
We will have to merge directly into the release branch due to the release deadline on Monday, otherwise QAs would need to first test in develop and release branches.

status-im-auto · 2024-08-24T00:05:33Z

Jenkins Builds

Click to see older builds (24)

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
✔️	`6d6eb2d`	#1	2024-08-24 00:05:32	~2 min	`tests-rpc`	📄`log`
✖️	`6d6eb2d`	#1	2024-08-24 00:05:35	~2 min	`tests`	📄`log`
✔️	`6d6eb2d`	#1	2024-08-24 00:07:14	~4 min	`linux`	📦`zip`
✔️	`6d6eb2d`	#1	2024-08-24 00:07:30	~4 min	`ios`	📦`zip`
✔️	`6d6eb2d`	#1	2024-08-24 00:08:22	~5 min	`android`	📦`aar`

✔️	`5daec47`	#2	2024-08-24 00:18:34	~1 min	`android`	📦`aar`
✔️	`5daec47`	#2	2024-08-24 00:19:10	~1 min	`linux`	📦`zip`
✔️	`5daec47`	#2	2024-08-24 00:19:20	~2 min	`tests-rpc`	📄`log`
✔️	`5daec47`	#2	2024-08-24 00:20:05	~2 min	`ios`	📦`zip`
✔️	`5daec47`	#2	2024-08-24 01:01:45	~44 min	`tests`	📄`log`

✔️	`d8e2a36`	#3	2024-08-24 00:23:32	~1 min	`android`	📦`aar`
✔️	`d8e2a36`	#3	2024-08-24 00:24:08	~2 min	`linux`	📦`zip`
✔️	`d8e2a36`	#3	2024-08-24 00:24:27	~2 min	`tests-rpc`	📄`log`
✔️	`d8e2a36`	#3	2024-08-24 00:25:26	~3 min	`ios`	📦`zip`

✔️	`cef2220`	#4	2024-08-24 00:36:52	~1 min	`android`	📦`aar`
✔️	`cef2220`	#4	2024-08-24 00:37:24	~1 min	`linux`	📦`zip`
✔️	`cef2220`	#4	2024-08-24 00:37:59	~2 min	`tests-rpc`	📄`log`
✔️	`cef2220`	#4	2024-08-24 00:38:51	~3 min	`ios`	📦`zip`
✔️	`cef2220`	#3	2024-08-24 01:48:00	~46 min	`tests`	📄`log`

✖️	`af07c75`	#4	2024-08-26 08:48:51	~1 min	`tests`	📄`log`
✔️	`af07c75`	#5	2024-08-26 08:49:19	~1 min	`android`	📦`aar`
✔️	`af07c75`	#5	2024-08-26 08:49:39	~2 min	`linux`	📦`zip`
✔️	`af07c75`	#5	2024-08-26 08:50:07	~2 min	`tests-rpc`	📄`log`
✔️	`af07c75`	#5	2024-08-26 08:50:45	~3 min	`ios`	📦`zip`

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
✔️	`38d72c0`	#6	2024-08-26 12:26:01	~1 min	`tests-rpc`	📄`log`
✔️	`38d72c0`	#6	2024-08-26 12:26:07	~1 min	`android`	📦`aar`
✔️	`38d72c0`	#6	2024-08-26 12:27:57	~3 min	`ios`	📦`zip`
✔️	`38d72c0`	#6	2024-08-26 12:28:35	~4 min	`linux`	📦`zip`
✖️	`38d72c0`	#5	2024-08-26 12:32:33	~7 min	`tests`	📄`log`

✔️	`0c3efd7`	#7	2024-08-26 13:09:49	~1 min	`android`	📦`aar`
✔️	`0c3efd7`	#7	2024-08-26 13:10:30	~2 min	`tests-rpc`	📄`log`
✔️	`0c3efd7`	#7	2024-08-26 13:10:39	~2 min	`linux`	📦`zip`
✔️	`0c3efd7`	#7	2024-08-26 13:11:36	~3 min	`ios`	📦`zip`
✔️	`0c3efd7`	#6	2024-08-26 13:53:36	~45 min	`tests`	📄`log`

api/backend_test.go

igor-sirotin · 2024-08-24T00:10:17Z

api/geth_backend.go

+		return errors.New("accounts is empty")
+	}
+
+	return b.multiaccountsDB.UpdateHasAcceptedTerms(accounts[0].KeyUID, true)


Is it always accounts[0]? 🤔
UPD: I see now your comment about HasAcceptedTerms will be set to true when the first account is created.. So it's the idea, we only store it for the first account? Basically, this setting is "per device"?

Correct @igor-sirotin, this setting is per device.

But does it make sense to store it in accounts table then?
Maybe we could use some single-row table, not to confuse us?

Also, just thought of this now, maybe it should be not a boolean flag, but a version?

So that any time in the future the policy changes and we need to show it again to the user, we could compare the new version with the version agreed by user.

Maybe we could use some single-row table, not to confuse us?

I pondered a lot about this, and in retrospect I wish I went this route in the beginning. The solution using the accounts table was something Andrea and I agreed on was good enough, but yes, there's some confusion around this solution. After the release we can make this improvement, I can personally do it 🙏🏼

So that any time in the future the policy changes and we need to show it again to the user, we could compare the new version with the version agreed by user.

@igor-sirotin I thought about this before, but there are many subtle details that were too much for me to solve until Monday (new tentative deadline). We don't have a proper version of the terms to refer to (and we can't use the software version as fallback). The version of a policy would need at least a special major and minor version because not all changes are legally significant to require the user to re-accept terms.

There's a case to be made as well that we don't need to optimize this whole process too much because the policies should change as little as possible or almost never ideally. Legally significant changes in the terms of use & privacy policy are risky. See now, how we will need to make public announcements to help users understand the changes. This is expensive on many layers.

Another detail is that there's no central source of truth for the terms of use and privacy policy. Mobile points to a file, desktop points to another file, legal uses another Google Docs.

With this PR's solution, in a future release, where the terms change (in a legally significant way), we will need to add a quick migration that resets all accounts hasAcceptedTerms to false. This will automatically be picked up by the client (mobile only at the moment).

But with all that said, I still think your suggestion is ideal. We just need to outline all the details in the process before jumping in the code.

just to clarify, maybe there was some misunderstanding, I suggested to check if there is more than one account and terms have not been accepted that we should show the modal, but I didn't suggest to keep this value within an account row, keeping it in a global separate table is better. I think actually that could be buggy, because accounts can be deleted, and then the user would be asked to reaccept the terms most likely (but haven't checked deeply the code to see if that's the case).
Either ways I am ok with both in the interest of time of course

With this PR's solution, in a future release, where the terms change (in a legally significant way), we will need to add a quick migration that resets all accounts hasAcceptedTerms to false. This will automatically be picked up by the client (mobile only at the moment).

@ilmotta True, this works as well and is seems much simpler, considering that we don't expect the policy to change frequently.

I think actually that could be buggy, because accounts can be deleted

Indeed 🤔

Either ways I am ok with both in the interest of time of course

Agree 👍 No need to change anything in release branch, if we're sure that it will not be difficult to change later.

I think actually that could be buggy, because accounts can be deleted, and then the user would be asked to reaccept the terms most likely

This is already how the app works in develop @cammellos. Deleting all accounts brings the user back to the intro screen, where they need to accept terms again. Whether this is good or bad depends a bit on perspective, not necessarily buggy.

So this PR's implementation had this benefit of matching how the app currently works without further changes.

Agree 👍 No need to change anything in release branch, if we're sure that it will not be difficult to change later.

@igor-sirotin it should be doable to change later.

@ilmotta I was referring to maybe a different case, not sure if that happens, but just by looking at the code it might:

user has 3 accounts on v1

user is presented with a pop up when upgrading

user accepts, setting account 1 has accepted

user deletes account 1

In this case, would the user be presented with terms again?

(Not that is an issue as it's an edge case, but good to be aware if it does happen)

Also my assumption is that the user is presented with terms in case of upgrade only once before login, not after (i haven't checked).

It would be solved easily by marking all accounts as accepted if we want to keep the per account flag.

Apologies if i misunderstood the code, admiteddly i haven t looked at the frontend pr yet :)

No no, apologies myself. This is a possibility indeed, and I hope to do the best implementation after the release.

multiaccounts/database_test.go

ilmotta · 2024-08-26T12:57:05Z

@igor-sirotin, a new flaky test TestEnableInstallationAndPair https://ci.status.im/blue/organizations/jenkins/status-go%2Fprs%2Ftests/detail/PR-5766/5/tests. Test pass locally, but fail very frequently.

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 #21113 status-go PR status-im/status-go#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.

…5766) The original GH issue status-im/status-mobile#21113 came from a request from the Legal team. We must show to Status v1 users the new terms (Terms of Use & Privacy Policy) right after they upgrade to Status v2 from the stores. The solution we use is to create a flag in the accounts table, named hasAcceptedTerms. The flag will be set to true on the first account ever created in v2 and we provide a native call in mobile/status.go#AcceptTerms, which allows the client to persist the user's choice in case they are upgrading (from v1 -> v2, or from a v2 older than this PR). This solution is not the best because we should store the setting in a separate table, not in the accounts table. Related Mobile PR status-im/status-mobile#21124

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 #21113 status-go PR status-im/status-go#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.

…5766) The original GH issue status-im/status-mobile#21113 came from a request from the Legal team. We must show to Status v1 users the new terms (Terms of Use & Privacy Policy) right after they upgrade to Status v2 from the stores. The solution we use is to create a flag in the accounts table, named hasAcceptedTerms. The flag will be set to true on the first account ever created in v2 and we provide a native call in mobile/status.go#AcceptTerms, which allows the client to persist the user's choice in case they are upgrading (from v1 -> v2, or from a v2 older than this PR). This solution is not the best because we should store the setting in a separate table, not in the accounts table. Related Mobile PR status-im/status-mobile#21124

…vacy policy (#5766) (#5977) * feat(accounts)_: Persist acceptance of Terms of Use & Privacy policy (#5766) The original GH issue status-im/status-mobile#21113 came from a request from the Legal team. We must show to Status v1 users the new terms (Terms of Use & Privacy Policy) right after they upgrade to Status v2 from the stores. The solution we use is to create a flag in the accounts table, named hasAcceptedTerms. The flag will be set to true on the first account ever created in v2 and we provide a native call in mobile/status.go#AcceptTerms, which allows the client to persist the user's choice in case they are upgrading (from v1 -> v2, or from a v2 older than this PR). This solution is not the best because we should store the setting in a separate table, not in the accounts table. Related Mobile PR status-im/status-mobile#21124 * fix(test)_: Compare addresses using uppercased strings --------- Co-authored-by: Icaro Motta <icaro.ldm@gmail.com>

fix_: functional tests (#5979) * fix_: generate on test-functional * chore(test)_: fix functional test assertion --------- Co-authored-by: Siddarth Kumar <siddarthkay@gmail.com> feat(accounts)_: cherry-pick Persist acceptance of Terms of Use & Privacy policy (#5766) (#5977) * feat(accounts)_: Persist acceptance of Terms of Use & Privacy policy (#5766) The original GH issue status-im/status-mobile#21113 came from a request from the Legal team. We must show to Status v1 users the new terms (Terms of Use & Privacy Policy) right after they upgrade to Status v2 from the stores. The solution we use is to create a flag in the accounts table, named hasAcceptedTerms. The flag will be set to true on the first account ever created in v2 and we provide a native call in mobile/status.go#AcceptTerms, which allows the client to persist the user's choice in case they are upgrading (from v1 -> v2, or from a v2 older than this PR). This solution is not the best because we should store the setting in a separate table, not in the accounts table. Related Mobile PR status-im/status-mobile#21124 * fix(test)_: Compare addresses using uppercased strings --------- Co-authored-by: Icaro Motta <icaro.ldm@gmail.com> test_: restore account (#5960) feat_: `LogOnPanic` linter (#5969) * feat_: LogOnPanic linter * fix_: add missing defer LogOnPanic * chore_: make vendor * fix_: tests, address pr comments * fix_: address pr comments fix(ci)_: remove workspace and tmp dir This ensures we do not encounter weird errors like: ``` + ln -s /home/jenkins/workspace/go_prs_linux_x86_64_main_PR-5907 /home/jenkins/workspace/go_prs_linux_x86_64_main_PR-5907@tmp/go/src/github.com/status-im/status-go ln: failed to create symbolic link '/home/jenkins/workspace/go_prs_linux_x86_64_main_PR-5907@tmp/go/src/github.com/status-im/status-go': File exists script returned exit code 1 ``` Signed-off-by: Jakub Sokołowski <jakub@status.im> chore_: enable windows and macos CI build (#5840) - Added support for Windows and macOS in CI pipelines - Added missing dependencies for Windows and x86-64-darwin - Resolved macOS SDK version compatibility for darwin-x86_64 The `mkShell` override was necessary to ensure compatibility with the newer macOS SDK (version 11.0) for x86_64. The default SDK (10.12) was causing build failures because of the missing libs and frameworks. OverrideSDK creates a mapping from the default SDK in all package categories to the requested SDK (11.0). fix(contacts)_: fix trust status not being saved to cache when changed (#5965) Fixes status-im/status-desktop#16392 cleanup added logger and cleanup review comments changes

author shashankshampi <shashank.sanket1995@gmail.com> 1729780155 +0530 committer shashankshampi <shashank.sanket1995@gmail.com> 1730274350 +0530 test: Code Migration from status-cli-tests fix_: functional tests (#5979) * fix_: generate on test-functional * chore(test)_: fix functional test assertion --------- Co-authored-by: Siddarth Kumar <siddarthkay@gmail.com> feat(accounts)_: cherry-pick Persist acceptance of Terms of Use & Privacy policy (#5766) (#5977) * feat(accounts)_: Persist acceptance of Terms of Use & Privacy policy (#5766) The original GH issue status-im/status-mobile#21113 came from a request from the Legal team. We must show to Status v1 users the new terms (Terms of Use & Privacy Policy) right after they upgrade to Status v2 from the stores. The solution we use is to create a flag in the accounts table, named hasAcceptedTerms. The flag will be set to true on the first account ever created in v2 and we provide a native call in mobile/status.go#AcceptTerms, which allows the client to persist the user's choice in case they are upgrading (from v1 -> v2, or from a v2 older than this PR). This solution is not the best because we should store the setting in a separate table, not in the accounts table. Related Mobile PR status-im/status-mobile#21124 * fix(test)_: Compare addresses using uppercased strings --------- Co-authored-by: Icaro Motta <icaro.ldm@gmail.com> test_: restore account (#5960) feat_: `LogOnPanic` linter (#5969) * feat_: LogOnPanic linter * fix_: add missing defer LogOnPanic * chore_: make vendor * fix_: tests, address pr comments * fix_: address pr comments fix(ci)_: remove workspace and tmp dir This ensures we do not encounter weird errors like: ``` + ln -s /home/jenkins/workspace/go_prs_linux_x86_64_main_PR-5907 /home/jenkins/workspace/go_prs_linux_x86_64_main_PR-5907@tmp/go/src/github.com/status-im/status-go ln: failed to create symbolic link '/home/jenkins/workspace/go_prs_linux_x86_64_main_PR-5907@tmp/go/src/github.com/status-im/status-go': File exists script returned exit code 1 ``` Signed-off-by: Jakub Sokołowski <jakub@status.im> chore_: enable windows and macos CI build (#5840) - Added support for Windows and macOS in CI pipelines - Added missing dependencies for Windows and x86-64-darwin - Resolved macOS SDK version compatibility for darwin-x86_64 The `mkShell` override was necessary to ensure compatibility with the newer macOS SDK (version 11.0) for x86_64. The default SDK (10.12) was causing build failures because of the missing libs and frameworks. OverrideSDK creates a mapping from the default SDK in all package categories to the requested SDK (11.0). fix(contacts)_: fix trust status not being saved to cache when changed (#5965) Fixes status-im/status-desktop#16392 cleanup added logger and cleanup review comments changes fix_: functional tests (#5979) * fix_: generate on test-functional * chore(test)_: fix functional test assertion --------- Co-authored-by: Siddarth Kumar <siddarthkay@gmail.com> feat(accounts)_: cherry-pick Persist acceptance of Terms of Use & Privacy policy (#5766) (#5977) * feat(accounts)_: Persist acceptance of Terms of Use & Privacy policy (#5766) The original GH issue status-im/status-mobile#21113 came from a request from the Legal team. We must show to Status v1 users the new terms (Terms of Use & Privacy Policy) right after they upgrade to Status v2 from the stores. The solution we use is to create a flag in the accounts table, named hasAcceptedTerms. The flag will be set to true on the first account ever created in v2 and we provide a native call in mobile/status.go#AcceptTerms, which allows the client to persist the user's choice in case they are upgrading (from v1 -> v2, or from a v2 older than this PR). This solution is not the best because we should store the setting in a separate table, not in the accounts table. Related Mobile PR status-im/status-mobile#21124 * fix(test)_: Compare addresses using uppercased strings --------- Co-authored-by: Icaro Motta <icaro.ldm@gmail.com> test_: restore account (#5960) feat_: `LogOnPanic` linter (#5969) * feat_: LogOnPanic linter * fix_: add missing defer LogOnPanic * chore_: make vendor * fix_: tests, address pr comments * fix_: address pr comments chore_: enable windows and macos CI build (#5840) - Added support for Windows and macOS in CI pipelines - Added missing dependencies for Windows and x86-64-darwin - Resolved macOS SDK version compatibility for darwin-x86_64 The `mkShell` override was necessary to ensure compatibility with the newer macOS SDK (version 11.0) for x86_64. The default SDK (10.12) was causing build failures because of the missing libs and frameworks. OverrideSDK creates a mapping from the default SDK in all package categories to the requested SDK (11.0). fix(contacts)_: fix trust status not being saved to cache when changed (#5965) Fixes status-im/status-desktop#16392 test_: remove port bind chore(wallet)_: move route execution code to separate module chore_: replace geth logger with zap logger (#5962) closes: #6002 feat(telemetry)_: add metrics for message reliability (#5899) * feat(telemetry)_: track message reliability Add metrics for dial errors, missed messages, missed relevant messages, and confirmed delivery. * fix_: handle error from json marshal chore_: use zap logger as request logger iterates: status-im/status-desktop#16536 test_: unique project per run test_: use docker compose v2, more concrete project name fix(codecov)_: ignore folders without tests Otherwise Codecov reports incorrect numbers when making changes. https://docs.codecov.com/docs/ignoring-paths Signed-off-by: Jakub Sokołowski <jakub@status.im> test_: verify schema of signals during init; fix schema verification warnings (#5947) fix_: update defaultGorushURL (#6011) fix(tests)_: use non-standard port to avoid conflicts We have observed `nimbus-eth2` build failures reporting this port: ```json { "lvl": "NTC", "ts": "2024-10-28 13:51:32.308+00:00", "msg": "REST HTTP server could not be started", "topics": "beacnde", "address": "127.0.0.1:5432", "reason": "(98) Address already in use" } ``` https://ci.status.im/job/nimbus-eth2/job/platforms/job/linux/job/x86_64/job/main/job/PR-6683/3/ Signed-off-by: Jakub Sokołowski <jakub@status.im> fix_: create request logger ad-hoc in tests Fixes `TestCall` failing when run concurrently. chore_: configure codecov (#6005) * chore_: configure codecov * fix_: after_n_builds

ilmotta requested review from cammellos, seanstrom, Samyoul, qfrank, igor-sirotin and saledjenic August 24, 2024 00:02

ilmotta self-assigned this Aug 24, 2024

ilmotta mentioned this pull request Aug 24, 2024

feat(onboarding): Present Terms to users upgrading from v1 status-im/status-mobile#21124

Merged

ilmotta force-pushed the ilmotta-release/add-accepted-terms-flag-to-accounts branch from 6d6eb2d to 5daec47 Compare August 24, 2024 00:16

igor-sirotin approved these changes Aug 24, 2024

View reviewed changes

qfrank approved these changes Aug 26, 2024

View reviewed changes

ilmotta force-pushed the ilmotta-release/add-accepted-terms-flag-to-accounts branch from cef2220 to af07c75 Compare August 26, 2024 08:47

cammellos force-pushed the release/0.182.x branch from 4a18c85 to 3b9d82f Compare August 26, 2024 12:19

ilmotta added 5 commits August 26, 2024 09:24

chore(multiaccount)_: Create migration

dc5946e

chore(multiaccount)_: Adapt database functions to handle new column

7665dc0

chore(multiaccount)_: Provide geth_backend API to accept terms

e264fa6

chore(multiaccount)_: Simplify function

73d4bfe

chore(multiaccount)_: Move assertion to proper place

38d72c0

ilmotta force-pushed the ilmotta-release/add-accepted-terms-flag-to-accounts branch from af07c75 to 38d72c0 Compare August 26, 2024 12:24

chore_: skip flaky TestEnableInstallationAndPair

0c3efd7

ilmotta merged commit 14c9961 into release/0.182.x Aug 26, 2024
7 checks passed

ilmotta deleted the ilmotta-release/add-accepted-terms-flag-to-accounts branch August 26, 2024 13:56

ilmotta mentioned this pull request Oct 22, 2024

feat(accounts)_: cherry-pick Persist acceptance of Terms of Use & Privacy policy (#5766) #5976

Merged

jrainville mentioned this pull request Oct 23, 2024

Fix/migration problem status-im/status-desktop#16572

Merged

ilmotta mentioned this pull request Oct 23, 2024

chore: Update release branch 2.31.x status-im/status-mobile#21491

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(accounts)_: Persist acceptance of Terms of Use & Privacy policy #5766

feat(accounts)_: Persist acceptance of Terms of Use & Privacy policy #5766

ilmotta commented Aug 24, 2024

status-im-auto commented Aug 24, 2024 •

edited

Loading

igor-sirotin Aug 24, 2024

ilmotta Aug 24, 2024

igor-sirotin Aug 24, 2024

igor-sirotin Aug 24, 2024

ilmotta Aug 24, 2024

cammellos Aug 24, 2024

igor-sirotin Aug 24, 2024 •

edited

Loading

ilmotta Aug 26, 2024

cammellos Aug 26, 2024

ilmotta Aug 26, 2024

ilmotta commented Aug 26, 2024 •

edited

Loading

feat(accounts)_: Persist acceptance of Terms of Use & Privacy policy #5766

feat(accounts)_: Persist acceptance of Terms of Use & Privacy policy #5766

Conversation

ilmotta commented Aug 24, 2024

Summary

Solution

status-im-auto commented Aug 24, 2024 • edited Loading

Jenkins Builds

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

igor-sirotin Aug 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ilmotta commented Aug 26, 2024 • edited Loading

status-im-auto commented Aug 24, 2024 •

edited

Loading

igor-sirotin Aug 24, 2024 •

edited

Loading

ilmotta commented Aug 26, 2024 •

edited

Loading