[Outlook] Manual E2E parity validation (M365 tenant)
- Dominant language
- Python
- Stars
- 133
- Forks
- 205
- Avg merge
- 16h 3m
- Merged PRs (30d)
- 102
Description
## Parent
Part of #4264
Blocked by: `outlook_cloud` feature-complete
## Summary
Manual E2E parity validation on a real M365 tenant: side-by-side legacy `outlook` (cloud) vs `outlook_cloud`.
## Scope
- Requires M365 test tenant + Entra app with Graph app permissions (+ optional Application Access Policy for 2–5 mailboxes)
- Checklist: all document types (mail×4, calendar, contacts, DLs, tasks, attachments×3), DLS, incremental run
- Record gaps; block GA on critical parity failures
## Acceptance criteria
- [ ] Side-by-side run completed and results posted on this issue
- [ ] Critical gaps filed or fixed before release QA
- [ ] Non-critical gaps documented with follow-ups
## Out of scope
- Automated live CI against M365 (nice-to-have later)
Contributor guide
Research direction
Start with parent issue #4264 and confirm that the outlook_cloud feature is feature-complete before arranging access to the M365 test tenant and Entra app. Run the side-by-side legacy outlook and outlook_cloud checklist across mail, calendar, contacts, distribution lists, tasks, attachments, and incremental runs. Done means results are posted here, critical gaps are filed or fixed before release QA, and non-critical gaps have documented follow-ups.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, python
- Domain
- backend, cloud, testing
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100