Laravel Filterable Laravel Package

Product Decisions This Supports

• Feature delivery: The new $filterable property supports shipping user-facing filtering/search safely by making allowed filter fields explicit on models. PMs can approve filter features with a clearer security boundary rather than relying on ad-hoc request-to-query logic.
• Security/risk roadmap: The release is framed as preventing security issues. Treat v2.0.0 as a risk-reduction upgrade candidate: prioritize auditing existing filter endpoints, confirming sensitive columns cannot be filtered, and documenting the approved filter surface per model.
• Build vs buy: If the product needs standard Eloquent-backed filtering, this package can replace custom filter parsing and whitelisting code. Build custom only if filtering requirements exceed allowlisted fields—e.g. complex faceting, full-text search, reporting aggregates, or authorization rules beyond field-level filtering.
• Upgrade planning: v2.0.0 is a major version. Even with a small release note, PMs should not assume a drop-in upgrade. Plan regression testing for existing filter behavior, confirm default behavior when $filterable is absent, and check the upgrade guide before tying roadmap work to v2.
• Product scope control: Use $filterable as a product contract: every exposed filter field should be intentionally approved. This helps prevent accidental exposure of internal columns and reduces the chance of costly or abusive query patterns.

When to Consider This Package

• Consider adoption when the Laravel/Eloquent application exposes query-param filtering and the team wants an explicit allowlist model rather than custom per-controller filtering.
• Consider it when security review asks for “deny by default” control over filterable fields, and when the team can maintain $filterable declarations alongside model changes.
• Consider upgrading when existing filter endpoints are business-critical and the security hardening in v2.0.0 reduces exposure risk.
• Look elsewhere if requirements include full-text search, advanced faceting, reporting/aggregation, multi-tenant authorization beyond field allowlisting, or if the package lacks a clear upgrade path, maintenance activity, or tests for bypass/performance edge cases.
• Before adoption or upgrade, require: release/upgrade documentation, a regression test plan for v1-to-v2 behavior, security validation of filter bypass scenarios, and performance checks on large tables.

How to Pitch It (Stakeholders)

For executives: This release adds a security-oriented $filterable property that makes allowed filter fields explicit. It supports faster delivery of safe search/filter features and reduces the risk of accidental data exposure through query parameters. Because it is a v2.0.0 major release, treat it as a planned upgrade with regression testing rather than an automatic patch.

For engineering: Adopt the $filterable allowlist as the standard way to expose model filtering. Audit existing endpoints for sensitive fields, confirm behavior when the property is not defined, add regression tests for filter bypass and query cost, and document the model-level filtering contract before rolling v2.0.0 into production.