DDLS-406: Allow a multi-client deputy to send a co-deputy invitation from a client linked to their secondary account

[MiaGordon91]

Purpose

A bug was identified whilst investigating another bug ticket (DDLS-396) where a multi-client deputy cannot send a co-deputy invitation from any client attached to their secondary accounts - they can only successfully invite a co-deputy from the client linked to their primary account.

Reason being, is because the deputy account that’s sending the invite is not attached to that particular client on a database level.

Fixes DDLS-406

Approach

• Update logic to use the clientId from the URL as part of the co-deputy invitation process

• Move function from the OrgService to the UserService as it did not apply to organisations

• Add a unit test for the updated endpoint in the CoDeputyController

• Add a behat test to cover the user journey

• Added in condition in Redirector that co-deputy verification only required when the user has been invited through the co-deputy invite route. The reason this was required is as follows:

1. Multi-client deputy sends co-deputy invitation from any client attached to their secondary account
2. Co-deputy then signs up
3. Multi-client deputy can sign in and see the co-deputy is attached to the client
4. However, the secondary account was not logging out and showing the login with your primary account error message. It was redirecting to the co-deputy verification page. I think this is to do with the user->getCoDeputyClientConfirmed() which would not be set for the secondary account as the invitation came from the primary account.

Learning

Any tips and tricks, blog posts or tools which helped you. Plus anything notable you've discovered about DigiDeps

Checklist

• I have performed a self-review of my own code
• I have updated documentation (Confluence/ADR/tech debt doc) where relevant
• I have added tests to prove my work
• The product team have approved these changes
• I have checked my work for potential security issues and refered to the OWASP top 10

Frontend

• I have run an in-browser accessibility test (e.g. WAVE, Lighthouse)
• There are no deprecated CSS classes noted in the profiler
• Translations are used and the profiler doesn't identify any missing
• Any links or buttons added are screen reader friendly and contextually complete
• If adding GA events, I have updated or checked the existing category or label values