bcgov / bcgov/foi-flow

Section 5 Pending - Hold Like Function and Update

Open
#4,839 1 comment 0 reactions 0 assignees View on GitHub
Story
Dominant language
Python
Stars
8
Forks
2
Avg merge
14h 34m
Merged PRs (30d)
46

Description

* As an IAO user
* I want requests on section 5 pending to no longer count and act like an on hold type of function
* so that I can better organize my request queue

**Assumptions & Scope**
This comes from feedback from the Intake team. Section 5 pending, is not technically an on-hold state - what it means is the request can not start until it "meets" section 5. When a request meets section 5, its start date should reflect the date it was met, and update the start date accordingly. In other words - if a request was received on day 0 (received date), and put on section 5 pending on day 2 - when the request meets section 5, it will have a start date consistent with that date, and the initial 30 day counter will begin from that day.

In addition to the change to this feature - Intake has advised they often accidentally Open requests, and are unable to put them on section 5 pending, this story will address that pain point too.

What is IN scope?

What is NOT in scope?

**Acceptance Criteria**

**Scenario 1: Section 5 pending selectable from Open**
* GIVEN an IAO user is on a Open, Personal request
* WHEN they activate the state dropdown
* THEN they will see the following options - Call For Records, Section 5 Pending, Peer Review, and Closed

**Scenario 2: Section 5 Pending State**
* GIVEN an IAO user is on a personal request in the Open state OR Intake in progress
* AND they have the state drop down activated
* WHEN they select Section 5 pending
* THEN a modal will pop out with the message: 'Are you sure you want to change the request (Request ID) to Section 5 pending? The request's clock will be suspended.
* AND the options will be to continue or cancel

**Scenario 3: Section 5 Pending State**
* GIVEN an IAO user is on the Section 5 Pending Modal
* WHEN they select Continue
* THEN the modal will close and the state will be updated
* AND the the remaining days will switch to N/A
* AND The request processing days will stop counting

**Scenario 4: Section 5 Pending - Changing State**
* GIVEN an IAO user is on a request in the 'Section 5 Pending' state
* WHEN they select the state drop down
* THEN the Options will be the prior state they moved from and the closed state

**Scenario 5: Section 5 Pending - Changing State**
* GIVEN an IAO user is on a personal request in the 'Section 5 Pending' state
* AND they select the state drop down
* WHEN they change the state to another state other than closed
* THEN a modal will pop out with the message: 'Are you sure you want to change the request (Request ID) to (state)? The request will be taken off hold and new due date calculated based on the date it met section 5.
* AND there will be a calendar picker with the text "Date request met section 5"
* AND there will options will be to continue or cancel
* AND the continue button will be disabled

**Scenario 6: Section 5 Pending - Date Selector**
* GIVEN an IAO user is on the state change modal after the request was on Section 5 pending
* WHEN they activate the calendar picker
* THEN the default day selected will be todays date
* AND they will be able to choose any date in the PAST but not the future

**Scenario 7: Section 5 Pending - Date Selector**
* GIVEN an IAO user is on the calendar picker for the section 5 pending state
* WHEN they select a valid date
* THEN the picker will close
* AND The date will appear in MM/DD/YYYY format
* AND the continue button will be active

**Scenario 8: Completing State Change**
* GIVEN an IAO user is on the state change modal after the request was on section 5 pending state
* AND the continue button is active
* WHEN they select Continue
* THEN the modal will close and the state will be updated
* AND the start date of the request will update to the section 5 date selected in the modal
* AND the due date will be calculated from the new start date
* AND The request processing days will resume

**Scenario 9: Section 5 pending state options when previously in Open*
* GIVEN an IAO user is on a Personal request in a Section 5 state
* AND the previous state was Open
* WHEN they activate the state dropdown
* THEN they will see the following options - Open, Peer Review, Call For Records, Redirect, Closed

**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 -- cc @JHarrietha-AOT - may need a design update for calendar picker in state change modal. You may wish to check in with Arielle on the needs of this story, but this is based on feedback I got from the intake team in how these states need to be functioning to get full use out of them. This will be important for AXIS dismantling eventually.

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

Open the contributing guide

Research direction

Review the acceptance criteria and existing request-state flow in the repository; no implementation files or design are named, so first locate the Open, Intake, and Section 5 Pending dropdown and date-processing entry points. Verify the modal, allowed transitions, suspended and resumed clock, and recalculated dates against Scenarios 1–9, then cover the stated unit and acceptance tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
full-stack
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.