Org Web Adapter

hungryroot/jira/be_7540_allow_staff_to_fetch_inactive_cookbooks_and_cookbookcollections_is_active_false.org

ID
7ca261bb-e303-4301-a080-bde671eaa8dc

BE-7540 Allow staff to fetch inactive Cookbooks and CookbookCollections (is_active = False)

- source :: https://hungryroot.atlassian.net/browse/BE-7540

- tags :: Hungryroot API Project

- epic :: EP-627 Exp 232: Cookbook MVP

- sprint :: HR BE Sprint 107

- status :: Status - Code Review

- priority :: Priority - High

- points :: 1

Description

Staff currently can only fetch Cookbook and CookbookCollection instances where

is_active = True. We need to extend the API/data-access layer so staff can also

query and retrieve inactive resources when explicitly requested.

Background / Context

Staff workflows sometimes require reviewing or restoring previously deactivated

cookbooks and collections.

Today, these inactive records are effectively hidden from normal staff queries.

We want to maintain the default behavior (only active records) while adding an

explicit way for staff to include inactive ones.

Requirements / Acceptance Criteria

Staff-facing API supports fetching:

Cookbook instances with is_active = False

CookbookCollection instances with is_active = False

Default behavior remains unchanged:

If no explicit flag is provided, only is_active = True records are returned.

Provide a clear, documented mechanism to include inactive items, for example:

A query parameter or filter flag (e.g. include_inactive=true or status=inactive)

Or an equivalent filter option at the data-access layer used by staff endpoints.

The mechanism:

Is available for both Cookbook and CookbookCollection queries.

Is only exposed on staff/internal endpoints, not public/consumer-facing ones

(confirm scope with PM if needed).

Add/update tests to cover:

Fetching only active items (current behavior)

Fetching inactive items only

Fetching both active and inactive when explicitly requested

Update relevant API or internal documentation to describe:

New query parameters / filter options

Any permission/scope limitations

Technical Notes / Implementation Ideas

Introduce optional filter(s) on the repository/ORM layer for:

is_active in [True] (current default)

is_active in [False]

is_active in [True, False] when including inactive

Ensure any existing callers that assume “active only” continue to behave as-is

(no breaking changes).

Confirm any authorization/role constraints so only appropriate staff roles can

access inactive items.