Split a request

* As an intake analyst
* I want to be able split a request
* so that I can manage requests that should be directed at multiple ministries or external public bodies (i.e. redirects)

**Assumptions & Scope**
What are the assumptions for this story?

Intake will receive requests where the applicant has asked for more than 1 ministry

Intake will receive requests where the request should be directed at more than 1 ministry

Intake will receive requests where part of the request can be opened and where part of the request can be redirected to an external public body (e.g. ICBC, BC Hydro, etc.).

Multiple ministries do not need to be selected before an analyst can click split request

Any IAO analyst can split a request, but not a ministry client.

**What is in and not in scope?**
Redirects are not in scope - they are covered in another request

While an analyst can change the date range of the request the functinality of that change is not covered in this story (covered in #77)

The toggle to open only part of this request is not included in the scope of this story. The Toggle is in story #131

Checkmark functionality for selecting ministries is not covered in this story - covered in #81

This story only includes splitting the request, not opening requests - that is covered in #129

**Acceptance Criteria**

**Scenario 1: Click Split Request**
* GIVEN an analyst is on the Request View:
* https://jacklyn808742.invisionapp.com/console/FOI---Intake-ckpq19frj032r013q6gpm8t1m/ckpx6mtxp012d013e9kos1n1b/play
* AND a category has been selected
* WHEN the analyst clicks the 'Split Request' button
* THEN the Split Request view will open
* https://jacklyn808742.invisionapp.com/console/FOI---Intake-ckpq19frj032r013q6gpm8t1m/ckpx6mtxp012f013ebi30csot/play
* AND a Request Description will appear for each pre-selected ministry
* AND the selected ministries checkbox will be green with a white arrow
* AND the request descriptions and date ranges will be autofilled from the original request

**Scenario 2: Select a ministry(s)**
* GIVEN the analyst is on the Split Request view
* https://jacklyn808742.invisionapp.com/console/FOI---Intake-ckpq19frj032r013q6gpm8t1m/ckpx6mtxp012f013ebi30csot/play
* WHEN the analyst clicks in the checkbox next to a ministry
* THEN a new request description field will be displayed
* AND the selected ministry checkbox will turn green with a white checkmark
* https://jacklyn808742.invisionapp.com/console/FOI---Intake-ckpq19frj032r013q6gpm8t1m/ckpx6mtxp012g013efc38bchi/play
* AND the request descriptions and date ranges will be autofilled from the original request

A box will appear for each checkbox:
https://jacklyn808742.invisionapp.com/console/FOI---Intake-ckpq19frj032r013q6gpm8t1m/ckpx6mtxp012h013egppn0ra5/play

**Scenario 3: Unselect a ministry(s)**
* GIVEN the analyst is on the Split Request view
* https://jacklyn808742.invisionapp.com/console/FOI---Intake-ckpq19frj032r013q6gpm8t1m/ckpx6mtxp012f013ebi30csot/play
* WHEN the analyst clicks in the checkbox next to a pre-selected ministry
* THEN the request description field for that ministry will not longer be displayed
* AND the unselected ministry checkbox will be empty (no colour or checkmark)

**Scenario 4: Click Back**
* GIVEN the analyst is on the Split Request view
* https://jacklyn808742.invisionapp.com/console/FOI---Intake-ckpq19frj032r013q6gpm8t1m/ckpx6mtxp012f013ebi30csot/play
* WHEN the analyst clicks in the 'Back' button
* THEN the analyst will return to the Request view
* https://jacklyn808742.invisionapp.com/console/FOI---Intake-ckpq19frj032r013q6gpm8t1m/ckpx6mtxp012d013e9kos1n1b/play

**Dependencies? What is the impact of this dependency? (If so, link dependency in the ticket, make it visible in a team´s backlog)**

**Validation Rules? (If yes, list here)**

**Design**
@xxx - please link the Design here

**Definition of Ready**

1. [ ] Is there a well articulated User Story?
2. [ ] Is there Acceptance Criteria that covers all scenarios (happy/sad paths)?
3. [ ] If there is a user interface, is there a design?
4. [ ] Does the user story need user research/validation?
5. [ ] Does this User Story needs stakeholder approval?
6. [ ] Design / Solution accepted by Product Owner
7. [ ] Is this user story small enough to be completed in a Sprint? Should it be split?
8. [ ] Are the dependencies known/ understood? (technical, business, regulatory/policy)
9. [ ] Has the story been estimated?

**Definition of Done**

1. [ ] Passes developer unit tests
2. [ ] Passes peer code review
3. [ ] If there's a user interface, passes UX assurance
4. [ ] Passes QA of Acceptance Criteria with verification in Dev and Test
5. [ ] Confirm Test cases built and succeeding
6. [ ] No regression test failures
7. [ ] Test coverage acceptable by Product Owner
8. [ ] Ticket ready to be merged to master or story branch
9. [ ] Developer to list Config changes/ Update documents and designs
10. [ ] Can be demoed in Sprint Review
11. [ ] Tagged as part of a Release
12. [ ] Feature flagged if required
13. [ ] Change Management activities done?

No files or tests are named. Start from the Request View and the Split Request view described in the acceptance criteria, and review related stories #81, #129, and #131 before locating their implementation. Done means the four listed scenarios work for analysts, including selecting and unselecting ministries, autofilled fields, and returning with Back.

Written by the indexing model from the issue text.