Restricted Requests - Reporting Conditions and Requirements

* As an IAO user runnings
* I want to ensure privacy of applicants of restricted requests are protected
* so that I can ensure we report out our work accurately

**Assumptions & Scope**
IAO currently does not report out on restricted files - this is largely due to the way reports are extracted out of AXIS

What is IN scope?
Redash and Restricted Flagged Requests

**Acceptance Criteria**

**Scenario 1: Request Description - Restricted Files**
* GIVEN a user is on Redash
* WHEN a restricted request appears in the spreadsheet widget, or any widget that includes a request description
* THEN the request description will only say "Restricted"

**Scenario 2: Applicant Name - Restricted Request**
* GIVEN a user is on redash, of a dashboard where applicant names could be seen
* WHEN a restricted request appears in the spreadsheet widget, or any widget that might include applicant names
* THEN the applicant name of the restrict request will read as "Restricted"

**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 tracing how restricted flagged requests are extracted for Redash and how request descriptions and applicant names reach spreadsheet and dashboard widgets. Confirm the existing AXIS reporting path and identify the tests covering restricted requests. Done means both fields display "Restricted" wherever the acceptance scenarios require it, without exposing applicant or request details.

Written by the indexing model from the issue text.