Social Login Over The Line
===

Goal: Social login should run on feature branch without bugs

## [[MACC-12846]](https://jira.grandvision.global/browse/MACC-12846) [BE] Update backend to only merge 2 accounts (and not more)

Currently we have 2 use-cases for merge accounts.

1. merge account one by one from my-settings (outside of mvp)
2. merge accounts (plural) from following use-case
- user creates account with email
- user does Social login with Google
- user clicks: Don't merge
- user does Social login with Apple
- user clicks: Yes merge (all my accounts)

The second implementation is more difficult / tricky to implement.

**Problems**

- problem 1: auth0 does not have atomic merge multiple accounts feature
- therefore accounts can be partially merged
- current implementation does not account for this
- problem 2: What do we do with a message on the bus that states merge 2 secondary accounts with 1 primary
- if one secondary account fails to link, we only have 1 message on DLQ
- also retries can create new issues

(Potential design issue is having 2 id's in 1 message.)

## Solution

### Proposed solution from 18 jan.

This has been discussed with Technical Architect. Proposed solution is to only allow for the
first use-case (merge accounts one-by-one).

This requires us to change the GraphQL schema a bit. From account `[ID]` to `ID` in some cases. Also the event currently contains a list of account id's to merge instead of only one secondary id.

### Counter proposal

For every account that can be merged we publish 1 event to the bus. For every merge request that goes wrong we put the message in the DLQ. This way we solve problem 1 and problem 2 and be able to merge all the accounts.

This solves the following issue:
- Merge A & B
- A succeeds
- B fails -> message fails
- Message is retried
- A does not exist -> message fails, repeating

Pro:
- no FE change needed

Note; Message model still needs to be changed and `linkAccounts` too.
Resolver / provider of the FE mutation also needs to be changed to send 2 events instead of one.

## Schema

### Current FE graph

type Mutation {
    # Initializes the social login flow
    initializeSocialLogin(input: InitializeSocialLoginInput!): InitializeSocialLoginResult!
    # Will fetch accounts with the same identity and propose accounts that can be merged if applicable
    completeSocialLogin: CompleteSocialLoginResult! @auth(roles: ["customer"], permissions: ["update:customer"])
    # Will initiate the account merge
    socialLoginMerge: SocialLoginMergeResult! @auth(roles: ["customer"], permissions: ["update:customer"])
}

### Current BE graph

type Mutation {
    # link user accounts
    linkAccounts(input: LinkAccountsInput!): LinkAccountsResult!
        @auth(roles: ["machine-internal"], permissions: ["update:customer"])
}

input LinkAccountsInput {
    primaryAccountId: ID!
    toMergeAccountsIds: [ID!]!
}

type LinkAccountsResult {
    linkedIds: [ID!]! # Problem: is we don't support arrays, also naming
    failures: [LinkAccountsFailure!]!
}

type LinkAccountFailure implements Failure {
    message: String! 
}

union LinkAccountsFailure = LinkAccountFailure

### Proposed BE graph change

input LinkAccountsInput {
    primaryAccountId: ID!
    secondaryAccountId: ID!
}

type LinkAccountsResult {
    linkedId: ID! # or `success: Boolean!`
    failures: [LinkAccountsFailure!]!
}

Or preferably without the indirection through ASB/functions. Function app can imo exist as input for other systems, no use to go from customer-service -> calm-functions -> customer-service.

CS --|> ASB
ASB --|> CALM
CALM --|> CS

## [[MACC-12608]](https://jira.grandvision.global/browse/MACC-12608) [FE + BE] Social login - add consent to merge to primary account

With changes to multiple messages on ASB the current implementation of updating consents has a possible race condition.

"customer-service (google)" ->> auth0 : get_consents (A)
auth0 ->> "customer-service (google)" : get_consents (A)

"customer-service (apple)" ->> auth0 : get_consents (A)
auth0 ->> "customer-service (apple)" : get_consents (A)

"customer-service (google)" ->> auth0 : write_consents (A + consents google = B)
"customer-service (apple)" ->> auth0 : write_consents (A + consents apple = C)

In this situation the google account merge consent will be overwritten by the apple account merge consent. To mitigate this issue we will move the writing of consents to the mutation where the merge request is started. Semantically this also makes more sense, because the consent is given before the actual merge is performed.

## To Do

### What we need to do to finish anyway

- [x] unit tests
- [x] move AccountService initialisation
- [ ] component tests
- [x] Customer-service: move customer repository

### Related to [[MACC-12846]](https://jira.grandvision.global/browse/MACC-12846) [BE] Update backend to only merge 2 accounts (and not more)

- [x] Merging of all accounts vs merging 1 account at the time
- [x] customer-service: remove initializeSocialLogin mutation (what/why???)
- [x] customer service schema.graphql aanpassen
- [x] event model aanpassen secondary is ID ipv [ID]
- [ ] UX/Design aanhaken
- from a Design / UX perspective is it better to merge multiple accounts or only one
- [x] TA @Anarag aanhaken, akkoord op schema changes

#### Changes to make
- [ ] Save consents before sending messages
- [ ] ~~Post multiple messages on bus to merge accounts one by one~~
- [x] Add mutation to merge a single pair of accounts from FE (just put one message on the bus)

### Related to [[MACC-12608]](https://jira.grandvision.global/browse/MACC-12608) [FE + BE] - Social login - add consent to merge to primary account

- [ ] move consents saving to before putting messages on bus
- [ ] consents issue merged to FB