Documentation for larsasub v0.38.2. On an older version? Your release notes ship with the package (CHANGELOG.md).

Nova integration#

Laravel Nova admin resources for LarsaSub ship as a separate package, peters-development/larsasub-nova. Read this page when you run Nova and want to manage plans, subscribers, charges, credit, invoices and the Mollie records from it.

• Installation
• What it gives you
  • Resources
  • Actions
  • Feature labels and multilingual content
• Configuration
• Bell notifications
• Authorization
• Connect mode and per-tenant databases
• Not using Nova?

Installation#

The companion installs from the same private repository as the core package and is included with every license tier. The core package has no Nova dependency and never will: a host that does not use Nova should not carry it.

composer require peters-development/larsasub-nova

The service provider is auto-discovered and registers the resources whenever Nova is served. Add the LarsaSub section to your Nova menu in NovaServiceProvider::boot():

use Illuminate\Http\Request;
use Laravel\Nova\Nova;
use PetersDevelopment\LarsaSub\Nova\NovaMenu;

Nova::mainMenu(function (Request $request) {
    return [
        // ... your own menu sections
        NovaMenu::section(),                          // or NovaMenu::section('Billing', 'currency-dollar')
    ];
});

The section holds collapsible groups for subscriptions, payments, credit, invoicing (when invoicing is on), the payment provider (Mollie), Mollie Connect (Connect mode, admin-only) and system records.

Releases are paired with the core package: companion 0.38.x belongs to larsasub 0.38. Update the two together.

What it gives you#

Nova resources for every LarsaSub model you would administer, with the package's policies applied. Resources register in groups; with the default null a group switches itself on or off from your core configuration, and true or false forces it.

Resources#

In Connect mode the plan resource adds a tenant panel and the application-fee override, payment methods show tenant_usable, and charges and single payments show their platform fee. In simple mode those fields are not there at all.

Actions#

Feature labels and multilingual content#

Two details come back from the core package:

• Feature labels. The plan resource shows larsasub.features.labels instead of raw feature keys in the Features field, and maps them back to keys on save. Unlabeled keys fall back to the raw key; see Configuration.
• Multilingual plan content. With larsasub.locales.supported set, the plan resource renders one field per supported locale for name, description and content, and the subscriber-subscription resource does the same for its name and description. Only locales that are really set prefill, and the default locale is required for the name. Content stored under a locale that was later removed from supported renders empty and is refused on save. See Multilingual plan content.

Configuration#

Publish the configuration only if you want to change it:

php artisan vendor:publish --tag=larsasub-nova-config

// config/larsasub-nova.php
return [
    // The Nova resource of your billable owner model; links the "performed by"
    // field on credit transactions.
    'billable_resource' => \App\Nova\User::class,

    'resources' => [
        'core' => true,
        'invoicing' => null,        // null = follow invoicing.enabled
        'mollie_provider' => null,  // null = on when Mollie is the provider
        'mollie_connect' => null,   // null = follow connect.enabled
    ],

    'notifications' => [
        'enabled' => true,
        'connection' => null,       // where nova_notifications lives; null = database.default
        'subscription_events' => true,
        'recurring_charge_events' => true,
        'single_payment_events' => true,
        'credit_events' => true,
        'attention_events' => true,
    ],
];

If your billable owner is not User (a Company, say), point billable_resource at its Nova resource.

Bell notifications#

With larsasub-nova.notifications.enabled on, the companion listens to the core package's domain events and posts Nova bell notifications. Each group can be switched off on its own:

They go to the platform's own recipients only: the users behind larsasub.notifications.sales, never a tenant's admins. A bell notification lives in this Nova panel and links into it, so it is for the people who administer the panel. A sales address without a user account gets LarsaSub's company mail by mail only, and no bell notification: there is no model to store it against. larsasub:doctor names such an address when a company channel list holds no mail.

These notifications come from the companion's own event subscriber, not from larsasub.notification_channels. Adding Nova's channel there does nothing: no LarsaSub notification implements toNova(), and ConfigurableNotificationChannels drops a channel whose method is missing.

Authorization#

The resources and actions use LarsaSub's model policies, configured under larsasub.policies.* (Policies). With the default policy configuration, plans, payment methods, reminder series, model logs and Mollie customers are admin-only, and changing a charge or a subscription requires an admin. Who is an admin is larsasub.policies.admin_role: empty means nobody.

The policies apply the same way in Nova as anywhere else.

Connect mode and per-tenant databases#

• The admin button in mails is registered for the PLATFORM audience. The companion registers its panel URLs with AdminUrlResolver, and that registration answers for the operator's own recipients only. Tenant admins receive the same company mails and get their link from notifications.tenant_admin_url instead; see The admin button knows who is reading. The companion builds its URLs from nova.domain (when Nova has its own domain) or app.url, plus nova.path, never from the root URL active at send time, so keep app.url correct on queue workers and the scheduler. If you register a resolver of your own, do the same: a closure that builds its URL with url() inherits whatever root URL is active, which on a host that forces a per-tenant root is the tenant's domain.
• Bell notifications and per-tenant databases. Nova's notification model follows config('database.default') at write time. Inside LarsaSub's activated tenant context (webhooks, the execution loops) that is the tenant's database, while nova_notifications is landlord data. Set larsasub-nova.notifications.connection to the connection that holds the table. The default null is right for a single database. See Channels with their own model for the mechanism.

Not using Nova?#

The Filament companion gives a Filament panel the plans, subscriptions, charges, reminder series and payment methods. Without either admin panel, the bundled management dashboards cover plans, subscribers, charges and invoices: in Connect mode as the tenant owner's view, in simple mode as operator management through larsasub.policies.admin_role.