Skip to content

Filament Admin Panel

The Filament admin panel, registered at path admin by AdminPanelProvider, is Yaya Engine's deep-configuration back office: a full CRUD surface over every domain table plus a set of singleton settings pages, built for engineers and super-admins doing catalog and system-wide work rather than day-to-day operational tasks [@panel-provider]. It runs on its own auth guard (admin) and discovers resources and pages by directory scan (discoverResources(in: app_path('Filament/Resources')), discoverPages(in: app_path('Filament/Pages'))), so adding a resource class in the right namespace is enough to register it in the panel without touching a service provider [@panel-provider]. This is the same panel and the same login that back Yaya Manager, which is a lighter, task-focused console layered on top of the same accounts.

Access model

Filament and Yaya Manager share one authentication guard and one user model: AdminUser, authenticated against the admin guard, using Spatie HasRoles/HasApiTokens traits [@admin-user]. AdminUser::canAccessPanel() is the single gate for entering /admin at all — it checks the admin.panel.access permission, not a role name, so panel access can be granted or revoked independently of what a user can do once inside [@admin-user].

Permissions and roles are centralized in App\Support\AdminAccess, which defines the fixed vocabulary of permission strings (admin.panel.access, manager.access, manager.validation.review, manager.payouts.process, manager.payouts.cancel, manager.payouts.export, mcp.access, mcp.tools.read, mcp.tools.write) and maps them onto four roles [@admin-access]:

  • super_admin — every permission, including admin.panel.access, so only this role can reach the Filament panel at all.
  • manager — the manager.* permissions plus mcp.access/mcp.tools.read, giving Yaya Manager access and read-only MCP tool visibility, but not Filament.
  • mcp_admin — mcp.access plus both mcp.tools.read and mcp.tools.write, for automation/tooling accounts.
  • mcp_viewer — mcp.access and mcp.tools.read only.

AdminAccess::sync() is idempotent: it upserts these permissions and roles under the admin guard, then assignRole() calls it before syncing a single role onto an AdminUser, so role assignment always sees the current permission set rather than a stale cached one [@admin-access]. Because admin.panel.access is only ever granted to super_admin, the practical rule is that Filament is a super-admin-only surface, while manager accounts live entirely inside Yaya Manager.

Resource catalog

app/Filament/Resources/ holds 14 resources, each following the same generated Filament v4 shape — a *Resource.php root class plus Pages/, Schemas/ (form and infolist), Tables/, and, where the model has child records worth editing inline, RelationManagers/ [@resources-dir]:

  • Actions — the catalog of preparation-task templates that preparation plans are built from, with a StepsRelationManager for editing an action's ordered steps. ListActions adds workbook import/export so the catalog can be bulk-edited in Excel instead of row by row — see Bulk-editing the action catalog [@actions-list-page].
  • AdminUsers — staff accounts and their roles, the resource that manages the AdminUser records described above.
  • Conversations — chat threads, with a MessagesRelationManager to inspect the messages in a thread without leaving the conversation record.
  • Fsps — the FSP directory, with relation managers for SMS config, WhatsApp config, alert config, and marketing flows, so an FSP's entire messaging setup is editable from one screen.
  • GeneratedLinks — with ClicksRelationManager and RegisteredUsersRelationManager, letting staff trace a shared link through to the clicks and signups it produced.
  • MarketingFlows, MessageBatches, MessageBroadcasts (the admin SMS broadcast tool), MessageDeliveryLogs, Messages — the messaging and broadcast catalog, each exposing its own relation managers (steps, executions, delivery logs) where a parent record has structured children.
  • RequestedPayouts — payout records, plus a DataBenefitsPage sub-page for the airtime/data-benefit disbursement workflow, listed and marked disbursed from its own table view rather than the main payouts table [@databenefits-page].
  • UserActions and UserActionSteps — the step-level execution records behind preparation plans. UserActionStepResource scopes its Eloquent query to steps with status = EvidenceUploaded and sets its navigation label to "Verification Queue", making it the Filament-side twin of the evidence review queue that Yaya Manager exposes as /manager/validation [@user-action-step-resource].
  • Users — the user directory, with relation managers for channel accounts, locations, messages, and delivery logs attached to a user.
  • UserTypes — the small lookup table driving user segmentation.

Settings pages and reporting tools

app/Filament/Pages/ holds pages that do not map to a single Eloquent resource [@pages-dir]:

  • ManageGeneralSettings, ManageDefaultAlertSettings, ManageKillSwitchSettings, ManageMcpTokens are configuration singletons — each edits one row or one config surface rather than a list of records.
  • CreativeFunnelReport is a reporting page under the "Reports" navigation group backed by CreativeFunnelAggregator, showing creative-level funnel metrics with a date-range filter rather than raw rows [@creative-funnel-report].
  • UserExportPage is an ops export tool: it lets staff filter the user table by FSP, gender, country, onboarded/verified state, and alert history, then streams the filtered set to a downloadable CSV via UserExportService. It also caches its filter option lists (countries, hazard types, loan products, network names) for three days and exposes a manual "Refresh filter cache" action for after a bulk import [@user-export-page].

This bulk/reporting split is deliberate: Filament owns wide, filterable exports and catalog-level bulk edits, while Yaya Manager owns narrow, recurring task workflows against the same underlying tables — see Yaya Manager for the other half of that split.