README

A portable Laravel engine for feature requests, one-vote-per-user voting, and status updates — with optional Blade and Livewire UI layers.

Drop a feature-voting board into any Laravel app. Users submit ideas, vote (one vote per user, toggleable), and comment. Admins update the status (under_review → planned → in_progress → completed or declined) and submitters are emailed when it changes.

Three layers, each opt-in from the one below:

Engine — models, migrations, service, events, policies, mailables. Always works.
HTTP + Blade — controllers, routes, Tailwind-styled views. Works in any Laravel + Tailwind app.
Livewire — reactive vote button, inline commenting, sortable board. Auto-registers only when livewire/livewire is installed.

Features

✅ One-vote-per-user enforced at the database level (unique index).
✅ Submission, voting (toggle), commenting — all through a single FeatureVotingService.
✅ Industry-standard status workflow: under_review, planned, in_progress, completed, declined.
✅ Admin response field on each request + styled admin comment thread.
✅ Email the configured admin on every new submission.
✅ Email the submitter every time the status changes — the "closed loop" that research shows is the #1 retention driver for feedback tools.
✅ Pluggable admin role — the consumer app defines a Gate; no hard-coded is_admin column.
✅ Events you can listen to: FeatureRequestCreated, FeatureRequestVoted, FeatureRequestCommented, FeatureRequestStatusChanged.
✅ Publishable config, migrations, views, and mail templates.
✅ Portable: no assumptions about the User model, theme, or UI library.

Requirements

PHP ^8.2
Laravel ^12.0 | ^13.0
Tailwind CSS in the consumer app (if using the shipped Blade views — not required if you build your own UI)
livewire/livewire ^3.0 | ^4.0 (optional — only for the Livewire layer)

Installation

composer require a2zwebltd/laravel-feature-voting

Publish and migrate:

php artisan vendor:publish --tag=feature-voting-config
php artisan vendor:publish --tag=feature-voting-migrations
php artisan migrate

Optionally publish the views if you want to restyle them:

php artisan vendor:publish --tag=feature-voting-views

Configuration

config/feature-voting.php:

'admin_email' => env('FEATURE_VOTING_ADMIN_EMAIL'),
'admin_gate' => 'manage-feature-requests',
'routes' => [
    'enabled' => true,
    'prefix' => 'feature-requests',
    'middleware' => ['web', 'auth'],
],
'views' => [
    'layout' => 'feature-voting::layouts.default',  // point at your own layout
    'section' => 'content',
],
'livewire' => ['register' => true],

.env:

FEATURE_VOTING_ADMIN_EMAIL=admin@yourcompany.com

Define who is an admin

The package delegates the "is this user an admin?" decision to a Gate the consumer app defines:

// app/Providers/AppServiceProvider.php — boot()
use Illuminate\Support\Facades\Gate;
use App\Models\User;

Gate::define('manage-feature-requests', function (User $user) {
    return in_array($user->email, ['dawid@a2zweb.co']);
    // or $user->is_admin, or a role check, etc.
});

If no gate is registered, the package falls back to comparing $user->email to config('feature-voting.admin_email'). If neither is set, nobody is an admin (fail-closed).

Point the views at your own layout

The shipped pages extend a layout you control. In your published config/feature-voting.php:

'views' => [
    'layout' => 'layouts.app',   // your existing layout
    'section' => 'content',       // the @yield name inside it
],

Usage

Drop-in: use the shipped pages

After install you get a working board at /feature-requests. Add a link from your app's nav:

<a href="{{ route('feature-voting.index') }}">Feature Requests</a>

Embed Blade components into your own pages

<x-feature-voting::board />                              {{-- full board --}}
<x-feature-voting::submit-form />
<x-feature-voting::request-card :request="$r" />
<x-feature-voting::vote-button :request="$r" />
<x-feature-voting::status-badge :status="$r->status" />
<x-feature-voting::comments :request="$r" />
<x-feature-voting::admin-panel :request="$r" />           {{-- renders only for admins --}}

Use the Livewire components

<livewire:feature-voting.board />
<livewire:feature-voting.request-show :request="$r" />
<livewire:feature-voting.vote-button :request="$r" />

Call the engine directly

use A2ZWeb\FeatureVoting\Services\FeatureVotingService;
use A2ZWeb\FeatureVoting\Enums\FeatureRequestStatus;

$service = app(FeatureVotingService::class);

$request = $service->submit($user, 'Add Slack export', 'Would love this');
$service->toggleVote($user, $request);
$service->comment($user, $request, 'Same here!');
$service->updateStatus($admin, $request, FeatureRequestStatus::Planned, 'Targeting Q3');
$service->isAdmin($user);

Listen for events

use A2ZWeb\FeatureVoting\Events\FeatureRequestCreated;
use Illuminate\Support\Facades\Event;

Event::listen(FeatureRequestCreated::class, function ($event) {
    // ping Slack, create a JIRA ticket, etc.
});

Data model

feature_requests — id, user_id (nullable), title, slug unique, description, status, votes_count, comments_count, admin_response, admin_responded_at, metadata (json), timestamps, soft deletes.

feature_request_votes — id, feature_request_id, user_id, timestamps. Unique (feature_request_id, user_id).

feature_request_comments — id, feature_request_id, user_id (nullable), body, is_admin_response, timestamps, soft deletes.

Disabling the HTTP layer

If you want to wire your own routes:

// config/feature-voting.php
'routes' => ['enabled' => false, /* ... */],

Then use the service directly and/or mount the Blade components into your own controllers.

Testing

composer install
vendor/bin/pest

Security Vulnerabilities

If you discover a security vulnerability, please report it responsibly through private communication with the maintainers.

License

MIT. See LICENSE.

Credits

Developed and maintained by the A2Z WEB crew:

a2zwebltd / laravel-feature-voting

Maintainers

Package info

Statistics

Security