---
title: "Verify bulk actions handle mixed-permission selections correctly"
description: "Select permitted and restricted fixture records through a supported mixed-result view and verify partial or atomic handling follows the documented bulk-action contract."
canonical_url: "https://vostride.com/agent-library/authorization/bulk-action-mixed-permissions.md"
md_url: "https://vostride.com/agent-library/authorization/bulk-action-mixed-permissions.md"
content_kind: "recipe"
topic: "authorization"
---

# Verify bulk actions handle mixed-permission selections correctly

Select permitted and restricted fixture records through a supported mixed-result view and verify partial or atomic handling follows the documented bulk-action contract.

## Risk

Bulk operations often use a different authorization path from single-record actions. The product must clearly state whether an unauthorized item causes an atomic rejection or a partial result, and its stored changes must match that statement.

## Fixtures

- A test account with edit access to one fixture record and read-only access to another.
- A product view that permits selecting both records and a reversible bulk status action.
- A documented atomic-or-partial bulk policy and a hook reporting each record status and revision.

## Steps

1. Open the mixed-permission list and verify both fixture record identifiers and their initial statuses.
2. Select exactly the two records and initiate the reversible bulk status change.
3. Read the confirmation or eligibility summary and verify it identifies the applicable action scope according to policy.
4. Confirm once and verify the resulting success, partial-success, or denial message states the actual affected record count.
5. Reload both record views and run the state hook; verify either only the permitted record changed or neither changed, as required by the documented bulk contract.

## Expected results

- The restricted record never changes through the bulk path.
- The permitted record changes only if the configured partial-success contract allows it.
- The visible affected count and error details agree with stored per-record results.

## False-pass traps

- A toast saying two items selected is not evidence that two items were eligible for mutation.
- Verifying only the permitted record can miss an unauthorized change to the restricted one.

## Cleanup

- Restore both fixture statuses and remove any bulk-operation test notifications.

## Use with agent-qa

Adapt this test design to your application's acceptance criteria and configured target using the [recipe execution guide](/agent-library/software-factory/turn-a-recipe-into-an-agent-qa-test.md). External fixture setup and non-UI checks require your own supported hooks or test tooling. Validate the authored test, execute it, and inspect the completed evidence; this recipe is not a recorded test result.

## References

- [agent-qa test](/docs/agent-qa/configuration/test.md)
- [agent-qa hooks](/docs/agent-qa/guides/hooks.md)
- [agent-qa auth state](/docs/agent-qa/guides/auth-state.md)

- [Authorization and permission QA recipes](/agent-library/authorization.md)
- [Software factory QA library](/agent-library.md)