OIPC Extension - Notify Applicant

* As an IAO analyst
* I want to be able to notify an applicant of an OIPC extension
* so that I can meet the legislative requirements

**Assumptions & Scope**
This story will utilize our contact applicant functionality to add a new dimension to it, and further move IAO away from using the legacy system.

When an OIPC extension is approved in the new system OR an approved OIPC extension is synced from AXIS, then an email will be able to be sent to the applicant.

**What is IN scope?**
Sending an email to the applicant through the contact applicant log when a new OIPC extension is approved or synced in the application.

**What is NOT in scope?**

Sending an email to the applicant through the contact applicant log when a new, public body extension is approved in the application; covered in #3238

**Acceptance Criteria**

**Scenario 1: New Approved OIPC Extension – Contact Applicant**
* GIVEN an analyst is on the Contact Applicant Log
* AND the most recent extension is an approved OIPC extension in the extension log
* WHEN they select the template dropdown
* THEN there will be an option for Extension – OIPC

**Scenario 2: Email Template for Approved OIPC Extension**
* GIVEN an analyst has the template dropdown open on contact applicant
* WHEN the analyst selects Extension – OIPC
* THEN the extension template will populate (link to template needed)
* AND the reason for the extension will be shown in the template

**Scenario 3: Edit Email Template Before Sending**
* GIVEN the IAO analyst is on the Contact Applicant Log
* AND the analyst has selected an OIPC extension template
* WHEN the clicks into the email body
* THEN the analyst can edit the email template
* AND analysts can Bold, Italicize, Underline content
* AND analysts can put content in bullets or numbered lists

**Scenario 4: Preview and Send Email**
* GIVEN the analyst has a populated extension email template
* WHEN they click Preview and Send Email Button
* THEN a modal will open with a preview of what will be sent to the applicant
* AND there will be a 'Send Email" and "Cancel" button

**Scenario 5: Send Email**
* GIVEN the analyst is on the preview modal
* WHEN they click Send Email
* THEN the email will be sent
* AND a copy of the email will be saved to the contact applicant log, including the date and time sent

**Scenario 6: Cancel Send**
* GIVEN the analyst is on the Preview email modal
* WHEN the analyst clicks "Cancel"
* THEN the email will not be sent
* AND the modal will close
* AND the analyst will remain on the Contact Applicant Log
* AND the draft email will be there with an active "Preview and Send" button

**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?

Start by locating the Contact Applicant Log and the flows that approve or sync OIPC extensions; no files, tests, design, or template are named in the issue. Review the existing contact-applicant email behavior and extension data before defining the work. Done means the OIPC template, editable preview, send/cancel behavior, and saved contact-log entry satisfy all six scenarios.

Written by the indexing model from the issue text.