Table of contents

Definition

Open questions

• Who are the migrated users?

• If you change the T&C, does the user have to accept it again?

• Currently check how and where T&C acceptances are saved.

• @Raphael Ferreira Gomes please send email to Paula asking for the examples of what they have in mind as inspiration.

• There are fields in Dynamo DB - @Silva, Carlos to help

Requirements

Problem statement

By law, every customer must comply with the privacy policy established by the company so it's possible to collect and use their personal information. For this reason, we need that, with each update of the privacy policy, the customer is notified and that he must accept it so that he can continue accessing the Popeyes login area on the Web and APP. 

Acceptance criteria

• Privacy policy and terms of use contents are updated via CMS with version control.

• Customers who have not accepted the most up-to-date version of the privacy policy will not be able to enter the Popeyes login area on the Web and APP. 

• For customers who have not accepted the latest version of the privacy policy: 

  • After logging in, they will be informed that they need to accept it and will have access to the most up-to-date information (link). A link to the terms of use will also be shown temporarily. 

  • Check if they have already accepted to receive commercial communications from RBI, if not, the option to accept will be presented too. 

  • Access to the logged area is released immediately after accepting the new version. 

• Metrics - tags will be applied that will allow us to answer the following questions:

  • How many customers were impacted by this modal? 

  • How many of these customers did not accept the new version? 

  • How many customers were we able to activate commercial communications using this modal? 

  • Store date, time and the last version of the privacy policy that each customer accepted. 

  • If the customer accepts commercial communications from RBI, this information will be stored in mParticle and Salesforce 

• For user registration (sign up), acceptance of the privacy policy for the latest available version will be stored.

• Import information from customers who have already accepted the latest version of the privacy policy in the current application (web/app) 

• For the launch of this functionality, it is not foreseen to update the privacy policy and the terms of use. This means that the modal should only be presented to customers who have not yet accepted the privacy policy in the current App/Web. 

Success metrics

• 99% of customers accept the privacy policy 

• 50% increase in commercial communication activation 

Text internationalized - Agreements modal

Open

Solution

Scenarios

Scenario 1: guest accepts agreements during sign up

Scenario 2: guest does not accept agreements during sign up

Scenario 3: update Privacy Policy while user is signed out

Scenario 4: update privacy policy while user is signed in

Scenario 5: update terms & conditions

Design

Figma design here: https://www.figma.com/file/sfH3mHXoEUfHbm5qMul0Vn/branch/akfj5Zk3gDEGHUXfBuLR3W/Popeyes?node-id=353-55073&t=ayZ3EGHIVY7vQT0Z-0

Development

Existing Behavior

No user agreements are stored. See tech details in https://rbictg.atlassian.net/wiki/spaces/IN/pages/4044391349 . He/she only accepts it in sign-up process. After that, he/she uses the app normally.

Success Metrics

Increase compliance of users. Metrics should rely on the required acceptance document info that is stored in database for each user.

Potential Challenges

Existent customers. They have no stored user agreement. Some of them may be old, some of them are new. For all, app must check if it is consistent and apply privacy policy terms.

Solution

• Sanity:

  • We should enhance sanity configuration to enable requiredAcceptance flag for each document (static page)

    • Marketing Content

      • Static Page

        • requiredAcceptance : bool ( default is false)

Repo: https://github.com/rbilabs/rbi-whitelabel-cms

https://dev-plk-menu.es.rbi.tools/desk/marketingContent;staticPages;0e0d12e4-d6cd-4b0e-bc9e-0cfbd590c922

Reason: That’s the place where it’s is used to configure this static page shown in the sign-up flow. Besides, there’s the possibility to retrieve the updateAt attribute, so that we can use it to take the decision to display new privacy policy to the customer or not.

• Whitelabel:

  • Sign-up of users must enforce user acceptance of the latest politics of privacy (configuration).

  • Terms of loyalty and terms and conditions aren’t mandatory (configuration).

    • New user data must be saved into dynamodb

      • aws-rbi-<env>-brand. E.g.: aws-rbi-dev-plk

        • pk: user cognito pk

        • sk: v0_User

        • details

          • requiredAcceptanceDocumentInfo ( Id, updateAt)

  • Sign-in / Home

    • Home loading

      • Call service to check whether user has up-to-date

        • Get latest Sanity requiredAcceptanceDocumentInfo(s) (Id, UpdateAt) → Check first in cache

          • If applicable, store in cache.

        • Get dynamodb customer requiredAcceptanceDocumentInfo(s) (Id, UpdateAt) → Check first in cache

          • If applicable, store in cache.

        • For each sanity required acceptance document, verify if there’s a corresponding entry for the retrieved customer accepted documents → compare using id

          • If dynamodb customer document UpdatedAt >= Sanity document UpdatedAt

          • Enables home and user access

        • Otherwise

          • Blocks user access.

          • Renders new UI - Forces user to either:

          • - accept latest required document → We can retrieve this info via IStaticPage.Widgets

          • - signout.

          • - Optionally, propose user to accept receiving emails.

          • ----> impact when fetching user data to read promotionalEmails flag / call set-user-attributes.ts (mParticle) - To handle it in a separate User Story.

        • If user accepts latest required document, then it should call a service to update user requiredAcceptanceDocumentInfo(s) (Id, UpdateAt) ( function updateMe? ) and enable user access

Note: Another tool can send only emails to inform the user in such cases, but this is not in the scope of this epic. Maybe enhancing mParticle events should be considered for that.

Repo : https://github.com/rbilabs/intl-whitelabel-app

RULE feature flag: switch-update-date-acceptance-agreement

RULE:

Currently, we don't have a "feature flag" to enable or disable this feature.

The "feature flag" switch-update-date-acceptance-agreement, was created to hide the modal in case of unnecessary updates.

If the feature flag is turned on, the modal will always appear with this date; it is mandatory. If it is turned off, the date is the update date from Sanity.

The date of the feature flag MUST always be less than the date in Sanity.

Example:

• My update date in DynamoDB (my_date): 2023-10-01

• Update date of the document in Sanity (date_sanity): 2023-10-04

• Feature flag date (date_flag): 2023-10-22

• dateUpdate = date_flag > my_date

If yes, the modal appears; otherwise, it doesn't appear.

Since the feature was designed to hide and not display the modal.

Any date that we put in the flag that makes the modal appear is a date insertion error. The feature is not prepared for this behavior.

But why, when I click the continue button, does the modal not close?

The date for the user's update is the date of the Sanity document (2023-10-04).

In other words:

• My update date in Dynamo (my_date): 2023-10-04 (new date updated)

• Update date of the document in Sanity (date_sanity): 2023-10-04

• Feature flag date (date_flag): 2023-10-22

Applying the rule:

• dateUpdate = date_flag > my_date

It always appears.

Reference Materials & Links

• Reference material is in the page attachments

• Sequence diagrams:

  https://lucid.app/lucidchart/56ec4afb-d8ea-42a2-a2dd-3cc38bfd87e7/edit?viewport_loc=-11%2C-75%2C2219%2C1004%2C0_0&invitationId=inv_57ecb6ad-cde2-4c13-be58-853204ed3007