Extensions - Extension Count in Request Queue and Advanced Search
- Dominant language
- Python
- Stars
- 8
- Forks
- 2
- Avg merge
- 14h 34m
- Merged PRs (30d)
- 46
Description
* As an IAO processing team user
* I want to see an accurate extension count in the Request Queues and Advanced Search
* so that I can know what requests to prioritize
**Assumptions & Scope**
What are the assumptions for this story?
I believe we missed this in the original tickets around extensions. Right now, the extension counter (EXT.) in the Request Queues and Advanced Search only show the total number of extensions, regardless of whether they are approved, pending or denied.
Instead, the extension counter (EXT.) in the Request Queues and Advanced Search should show the extensions similar to how they are displayed in the left pane. I.e., extension count should be displayed in the Requests Queue and Advanced Search similar to #946.
Denied extensions are not displayed in the extension counter (EXT.)
Approved extensions:

Pending Extension:

Approved and Pending Extensions:

What is IN scope?
What is NOT in scope?
**Acceptance Criteria**
**Scenario 1: Extension is approved**
* GIVEN an IAO user has created or synced an extension on a request
* WHEN the IAO user approves the extension (in Mod, or AXIS and synced)
* THEN the extension counter (EXT.) in the Request Queue and Advanced Search will update to display the number of approved extensions as "1"
**Scenario 2: Extension is saved as pending**
* GIVEN an IAO user has created or synced an extension on a request
* WHEN the IAO user changes the extension to pending (in Mod, or AXIS and synced)
* THEN the extension counter (EXT.) in the Request Queue and Advanced Search will update to display the number of pending extensions as "(1)"
**Scenario 3: Extensions in pending and approved**
* GIVEN an IAO user has created or synced two or more extensions on a request
* WHEN the IAO user approves an extension (in Mod, or AXIS and synced)
* AND the IAO user changes another extension to pending (in Mod, or AXIS and synced)
* THEN the extension counter (EXT.) in the Request Queue and Advanced Search will update to display the number of approved and pending extensions as "1(1)"
**Scenario 4: Extension is denied**
* GIVEN an IAO user has created or synced an extension on a request
* WHEN the IAO user denies an extension (in Mod, or AXIS and synced)
* THEN the extension counter (EXT.) in the Request Queue and Advanced Search will not display the denied extension, or include it in the extension counter
**Scenario 5: Extension is moved from pending to approved**
* GIVEN an IAO user has created or synced an extension on a request
* AND the extension is pending
* WHEN the IAO user changes the extension to approved in the extension modal
* THEN the extension counter (EXT.) in the Request Queue and Advanced Search will update to display the new number of approved extensions
* AND the extension will no longer be counted as a pending extension
**Scenario 6: Extension is moved from pending to denied**
* GIVEN an IAO user has created or synced an extension on a request
* AND the extension is pending
* WHEN the IAO user changes the extension to denied in the extension modal
* THEN the extension counter (EXT.) in the Request Queue and Advanced Search will update, and no longer count, and display, the extension as being pending
**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?
Contributor guide
Research direction
Start by tracing how the extension counter is produced in the Request Queue and Advanced Search, then compare it with the extension display in the left pane. Check the extension modal and Mod or AXIS sync paths for approved, pending, and denied states. Done means the counter matches all six acceptance scenarios in both views, with denied extensions excluded.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- full-stack, search
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100