feat: new enterprise login validations for initial screen (WPB-15520)

[yamilmedina]

WPB-15520 [Android] - Implement error handling for initial screens

---

PR Submission Checklist for internal contributors

• The PR Title

  • conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
  • contains a reference JIRA issue number like SQPIT-764
  • answers the question: If merged, this PR will: ... ³

• The PR Description

  • is free of optional paragraphs and you have filled the relevant parts to the best of your ability

---

What's new in this PR?

We need to provide initial validation for the email and SSO code input, later this will decide some part of the flows to follow.

• Add the validations reusing existing logic on Kalium (a coming PR there should follow)
• Add the ADR, with the approach followed in this epic effort.

Dependencies (Optional)

• feat: new enterprise login validations expose SSO code validator use case (WPB-15520) kalium#3242

Needs releases with:

• GitHub link to other pull request

Testing

Will add test coverage.

Test Coverage (Optional)

• I have added automated test to this contribution

How to Test

Briefly describe how this change was tested and if applicable the exact steps taken to verify that it works as expected.

Attachments (Optional)

---

PR Post Submission Checklist for internal contributors (Optional)

• Wire's Github Workflow has automatically linked the PR to a JIRA issue

---

PR Post Merge Checklist for internal contributors

• If any soft of configuration variable was introduced by this PR, it has been added to the relevant documents and the CI jobs have been updated.

---

References

1. https://sparkbox.com/foundry/semantic_commit_messages
2. https://github.com/wireapp/.github#usage
3. E.g. feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764.

[pull-request-size]

Ups 🫰🟨

This PR is too big. Please try to break it up into smaller PRs.

[AndroidBob]

New ADR(s) in this PR 📚:

5. Simplified enterprise login

Date: 2025-01-23

Status

Accepted

Context

Starting (potentially) from Android 4.12.x the app will support the new enterprise login flows, this means in practice that the app needs to support both flows current/old.

The current flow (old)

Customers configure their setup manually in their backend.
The user experience for this makes the user selects manually which flow they must use by going to the correct screens, i.e. going to the tab and select login with SSO code, or login with email, or use a deeplink to load the on premise configuration, and then select the correct flow.

The new flow

Customers, via team settings and Back-office tools, will be able to load this config to facilitate the decision of which flow the user must use. This will make the app, in conjunction with the backend, decide for the user which path/flow they must use to login by just having one input field, “email or SSO code”.
The adoption won’t be automatically via deprecation, hence the need to support both flows for some time. To clarify a bit how this looks in practice for the code we have, how this will be implemented, a high level look of the two flows living together, the following diagram can be used.

Decision

We will keep both flows, the current as-is and the new one, being the app able to decide which one to use based on the configuration received from the backend.

%%{
  init: {
    'theme': 'neutral'
  }
}%%

flowchart LR
    z((App loads</br> BE/API context)) --> di
    di{BE supports </br>API >= 8 ?}:::someclass -- Yes --> a1
    di -- No</br>OR Authenticated Proxy --> b1
    classDef someclass fill:#f96
    subgraph new_flow
      a0@{ shape: braces, label: "These flows are selected by the app and the BE" }
      a1[StartLoginScreen </br>'Enter email or SSO code'] -- looks like SSO code --> a2[Go to SSO flow path 6-7] 
      a1 -- Looks like an email? --> a3[BE replies which path to go 1-4]
    end
    subgraph current_flow
      b0@{ shape: braces, label: "These flows are selected manually by the user" }
      b1[WelcomeScreen] --> b2[LoginEmailScreen]
      b1 --> b3[LoginWithSSOCodeScreen]
    end

Loading

Consequences

• The code base will have some duplication for some time, but this will be removed when the old flow is deprecated.
• To select the correct flow, the app will need to load the BE context, based on the API version, and then decide which flow to use.
• The navigation, entry point will need to be dynamic, based on the flow selected.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud