New "Récurrences" section lets users define recurring depense/epargne models (name, category, default amount, day of month). Nothing is created automatically: from the day a recurrence is due, it appears as a pending proposal in Suivi (desktop + mobile) with an editable amount, so variable bills (electricity, etc.) can be adjusted before confirming. Dismissing a proposal skips it for the current month without creating a transaction, and it reappears the following month. - recurring_transactions table (household/category scoped, active flag, last_generated_year/month to prevent duplicate generation) - transactions.recurring_transaction_id nullable FK to trace origin - RecurringTransactionPolicy mirrors CategoryPolicy tenant scoping - 10 new Pest tests covering CRUD, tenant isolation, and the pending/confirm/dismiss lifecycle across month boundaries (travelTo) 58/58 tests pass, Pint clean, verified end-to-end against production data (test recurrence created and cleaned up). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
22 lines
525 B
PHP
22 lines
525 B
PHP
<?php
|
|
|
|
declare(strict_types=1);
|
|
|
|
namespace App\Policies;
|
|
|
|
use App\Models\RecurringTransaction;
|
|
use App\Models\User;
|
|
|
|
class RecurringTransactionPolicy
|
|
{
|
|
public function update(User $user, RecurringTransaction $recurringTransaction): bool
|
|
{
|
|
return $recurringTransaction->household_id === $user->current_household_id;
|
|
}
|
|
|
|
public function delete(User $user, RecurringTransaction $recurringTransaction): bool
|
|
{
|
|
return $recurringTransaction->household_id === $user->current_household_id;
|
|
}
|
|
}
|