---
# System prepended metadata

title: Actions Due V3 - Tech Spec

---

# Actions Due V3 - Tech Spec
Actions Due is out of sync styles and filter-wise than the Inbox and reporting. 
## Requirements
### Functional requirements

As a receptionist, I want to... 
1. Be able to filter the actions due by datetime, types, labels, sources and snoozed. This includes Future dates (to know what my workload is like). This allows me the opportunity to process Actions in a way that suits me. 

As a Practice Owner, I want to...
1. Assign a different receptionist to handle specific treatment leads or leads from a specific source

As a LeadFlo Developer, I want..

1. Actions due to be inline with the new inbox v2 so training is more intuitive
2. Filtering to be handled by our existing backend filter systems instead of relying on the frontend which adds complexity

### Non-functional requirements

1. New actions UI must closer match to the Reporting and Inbox v2
2. API Endpoint will be transfering more data in shorter interval (view changes). Ensure load times dont increase significantly 

### Out of Scope

1. Action counts wont be changing. Ensure existing count code isnt changed (this is why we are moving to new folder)
2. Filters won't be stored on view change. Filter will reset with every view change

## Design

Use feature flag for Actions Due V3 to hide new actions bar and filtering system

### UI Components
#### Actions Due - Items

Update type `LegacyV2ActionSchema`

```
{
    ...
    snooze: boolean;
    snooze_date: string | null; // Add this
}
```
to include snooze_date pass through to `<ActionSummary />` - use `dates.delta` to get time in countdown style. See `Notification` for countdown example

This component comes with a design:`Snooze ends in {countdown}` - 
Figma: https://www.figma.com/file/ao2VLy9C0EJwlljK6q2v3y/Leadflo?type=design&node-id=3921-9431&mode=design&t=aTh6KvIXFy3u4tS6-0


#### Actions Due - Filter Bar

Design in Figma: https://www.figma.com/file/ao2VLy9C0EJwlljK6q2v3y/Leadflo?type=design&node-id=3921-9431&mode=design&t=aTh6KvIXFy3u4tS6-0

Note: Each View has its own filters

Modify Components to match design:
* Add in DateRange filter (allow future dates) & dropdowns for Types, labels, Sources. Uses same design as Reporting Filter Bar. Existing dropdowns code from Reporting
* Update sort order display to icon only (for space reasons) - uses same icon as Inbox V2

Create new Action folder for new types

Add Type for ActionsQuery. Filter bar will populate ActionsQuery in State - use selectors to pass via props
```typescript
export interface ActionsQuery {
    types: string[] | null;
    labels: string[] | null;
    sources: string[] | null;
    start: string;
    end: string;
    includeSnoozed: boolean;
}
```

Update `FetchActionsArgs` type to use ActionsQuery.
```typescript
interface FetchActionsArgs {
    stages?: string[];
    forView: string;
    query?: ActionsQuery; // new
}
```

Update FetchActions using the above ActionsQuery args pointing to the new query - mark as not required for backwards compatabilty
```typescript
stages?: string[],
referrals?: ReferralsFilter
// current ^
// Add params from ActionsQuery
```

```typescript
export const fetchActions = createAsyncThunk<ActionsPayload, FetchActionsArgs>(
    'actions/due',
    async ({ stages, start, end, types, labels, sources, includeSnoozed }: FetchActionsArgs) => {
        return fetchActionsApi(stages, start, end, types, labels, sources, includeSnoozed);
    }
);
```

Update ActionState to support the new query options. Use the ConnectedToolbar to pass props down
```typescript
// each view will need query so it resets upon change
export interface ActionViewMeta {
    ...
    query: ActionsQuery
    ...
}
// import {  epoch } from '@/utils/date';
// Add query to all views
export const initialState: ActionState = {
    ...
    views: {
        'New Leads': {
            ...
            query: {
                types: [],
                labels: [],
                sources: [],
                start: epoch.toISOString(), // default to Epoch start
                end: Date.now(), // default to today
                include_snoozed: false // defualt false
            }
```

Using the existing viewMeta selector you should be able to grab the query from each view

```typescript
const view = useAppSelector(withState(viewMeta, title));
const query = view.query; // pass to props on new filter bar
```
Store ActionQuery on fetchActions.pending - Update reducer to store ActionQuery
```typescript
    ...    
    builder.addCase(fetchActions.pending, (state, action) => {
        ...
        const viewName = arg.forView;
        const view = state.views[viewName];
        const actionQuery: ActionQuery = {
            types: action.meta.arg.types,
            labels: action.meta.arg.labels,
            sources: action.meta.arg.sources,
            start: action.meta.arg.from.toISOString(),
            end: action.meta.arg.to.toISOString(),
            include_snoozed: action.meta.arg.include_snoozed,
        }
        view.query = actionQuery;
        
    });
```

### API
No feature toggle needed for API due to backwards compatible 
Note: Current actions due API response isn't type safe. 
Update enpoint to accept these options
`GET /actions/due`

**Payload**:
```typescript
interface Payload {
    stages: string[]; // Array of stages
    referrals: boolean; // Include referrals
    start: string; // ISO 8601 - default to unix start
    end: string; // ISO 8601 - default to today
    types: string[]; // Array of types
    labels: string[]; // Array of labels
    sources: string[]; // Array of sources
    include_snoozed: boolean; // Include snoozed actions
}
```

**Behaviour**:
1. Returns list of actions based on query payload
2. Get all action within `from` to `to` dates
3. Filter by types, labels, sources - array of strings
4. Filter by include_snoozed - toggle

Update Open API spec for /actions/due

Update Action Read Model `services/leadflo-api/src/App/ReadModels/Actions/Action.php` add snooze_date return for actions. Ensure OpenAPI has been updated and contract test has been created

```yaml
    ...
    snooze_date:
      type: string
      format: date-time
      nullable: true
```


Update ActionsDue Query 
```php
final class ActionsDue
{
    public function __construct(
        public readonly array  $stages,
        public readonly ?bool  $referrals,
        public readonly ?string $startAt,
        public readonly ?string $endAt,
        public readonly ?array $types,
        public readonly ?array $labels,
        public readonly ?array $sources,
        public readonly ?bool  $include_snoozed,
    ) {
    }
}
```
Ensure Query for Actions Due takes frontend datetime strings and converts to UTC for datetimes - ensure it uses to_start_of_day and to_end_of_day -
```php
        $this->startAt = to_start_of_day($startAt);
        $this->endAt   = to_end_of_day($endAt);
```


### Testing
#### API
API will need multiple tests due to the increased complexity of the SQL query.

1. Test with a contract test and Open API - test returning the correct data and the dates are in the correct format (future date testing required) - DateTime in UTC etc

#### UI
Create an e2e test for the whole Actions Due page to ensure it is working as expected with filters (each filter needs specific test), load more actions and sorting. Ensure filter resets upon view change. All dropdowns will have multiple enabled so multiple options can be selected to filter by.

We should unit test the component, ensuring that:
1. Check To and From filtering by dates - Ensure future date filtering also works 
2. Check types dropdown filters
3. Check labels dropdown filters
4. Check sources dropdown filters 
5. Ensure load more actions uses existing view filters
6. Ensure sorting ordering still works with new filters in place.


## Implementation

### API
* Update ActionsDue Query and write test ensuring datetime params are correctly formatted to end/start of day
* Update endpoint `/v3/actions/due` Ensure theres an OpenAPI spec for this endpoint with contract test. New endpoint should return snooze_date along with original actions response (ends_at date within patient_snoozes table) - below to points can also be done is one PR
* Update resolver to take the ActionsDue Query and run sql to get a list of actions - example `services/leadflo-api/src/App/Resolvers/ActionsDueResolver.php`. This Requires integration test ensuring all params return correct data and future dates work as expected
* Update Action `services/leadflo-api/src/App/ReadModels/Actions/Action.php` read model ensuring the new ActionsDue Query returns type safe data. This will also need snooze adding - this read model doesn't seem to be used anywhere else but worth double checking.


### UI

* Update component Action Items (LegacyV2ActionSchema) with snooze_date and styles for displaying this date. Default to null (not display). Use a Story to get design correct
* Update ActionsQuery and FetchActionsArgs types. Add to new folder/file to ensure no conflicts for existing FetchActions queries
* Update fetchActions to get `/actions/due` function using the FetchActionsArgs types
* Update ActionViewMeta to use ActionsQuery. Update initial ActionState to use default values for ActionsQuery
* Update reducer fetchActions.fulfilled to handle the view.query
* Actions Due - Filter Bar - Modify Components to match design - add date filter and dropdowns - Use feature flag to display or hide new bar - story should be used to match design - e2e test will need creating to ensure dates and dropdown selectors work as expected
* Actions Due - Filter Bar - update state selectors to grab query params from bar and update store for added params
* Actions Due - Filter Bar - new filter bar needs to use new fetchActionsV3 - ensure behind feature flag
* Update the filter bar to get new actions (with queries) upon state update instead of clicking run (as in reporting)

### Release
* Record video release announcement
* Release for canaries (Beta testers)
* Release for all clients
* Remove feature flags
* Remove dead code - Best done a few weeks after full release incase we need to rollback but can be done with feature flag removal