Authorized Attributes Laravel Package

Product Decisions This Supports

• Field-level access control as a product feature. The package targets a recurring need: showing or hiding individual Eloquent model attributes based on who is asking. That directly supports decisions like "should managers see compensation fields?", "should support agents see customer PII?", or "should free-tier API consumers receive the same payload as enterprise ones?" — decisions that otherwise get hard-coded into serializers and rot.
• Monetization and packaging. Tiered data visibility is a lever for plan differentiation (e.g., premium exports expose more fields). Deciding whether field visibility is core domain logic or a cross-cutting concern is a roadmap decision this package makes cheap to revisit.
• Compliance and least-privilege posture. Attribute-level authorization supports GDPR/CCPA-style data minimization and internal least-privilege narratives. It gives a defensible, centralized place to answer "why was this field exposed?" during audit or incident review — a build-vs-buy input for security review.
• Build vs buy for a commodity concern. Writing per-attribute authorization rules by hand is small but pervasive work: custom API resources, $visible toggling per role, ad-hoc makeHidden() calls. Buying (adopting) a focused MIT package is attractive if the abstraction matches your mental model; building is attractive if your rules are row- or context-dependent.
• API contract decisions. If attribute visibility varies by role, your public API contract is conditional. Adopting a declarative layer forces the team to document that contract explicitly rather than letting it emerge from controller code — useful signal for versioning and client-facing documentation.
• Roadmap sequencing. Because it is small and MIT, it can be adopted as a spike in a single sprint to validate the field-visibility model before committing to a larger RBAC/ABAC investment.

When to Consider This Package

Consider it when:

• You are on Laravel with Eloquent and already lean on Laravel's authorization primitives (gates/policies); this slots into that mental model rather than competing with it.
• Your visibility rules are genuinely per-attribute and role-driven, and the set of rules is large enough that scattered $hidden/$visible/resource classes have become a maintenance problem.
• You need one declarative source of truth for sensitive fields (PII, financials, internal notes) that security and product can both read.
• Your team can absorb early-stage dependency risk: 23 stars and 0 dependents means effectively no ecosystem validation, minimal community troubleshooting, and a likely single-maintainer bus factor. Budget for a code read, a pinned version, and a fork-or-vendor contingency.
• You want a fast, reversible experiment — the MIT license and narrow scope make it easy to trial and easy to rip out.

Look elsewhere (or build) when:

• You need row-level or relationship-level security rather than attribute masking. This is a different problem; combine Laravel policies with query scoping or a dedicated authorization service.
• You need complex ABAC (context-, time-, or tenant-condition-driven rules). You will likely outgrow a package this focused.
• You require vendor support, SLAs, or a proven production track record — none of which 0 dependents provides.
• Attribute visibility is on a hot serialization path and you cannot tolerate another layer of indirection; benchmark before adopting.
• You are not on Laravel, or your API layer does not serialize Eloquent models directly (e.g., DTO-first architecture), in which case the value proposition largely evaporates.
• Your organization's dependency policy requires a minimum adoption/maintenance threshold; treat the low star count and zero dependents as a formal gate, not a footnote.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed Laravel library that lets us control which data fields each user role can see, declaratively, in one place. It supports two business outcomes: (1) selling differentiated data access by plan, and (2) demonstrating least-privilege handling of customer data for compliance and security reviews. Cost is near zero and it is easy to remove, but it is early-stage — 23 stars, no known dependents — so the recommendation is a scoped pilot with a fork contingency, not a platform-wide standard.

For engineering: It addresses attribute-level authorization, a concern we currently handle inconsistently across API resources and ad-hoc makeHidden() calls. Adoption means one declarative rule set instead of scattered conditionals, aligned with Laravel's existing gate/policy model. The trade-off is dependency maturity: we should read the source, pin a version, cover it with tests at the serialization boundary, and be prepared to vendor it. If our requirements drift toward row-level or context-heavy authorization, we stop and build instead.