Vendventory Documentation
v1.0.0 Changelog

Configuration

This page covers the post-install configuration model for Vendventory. It explains which defaults come from code, which values are stored in the settings table, which areas are changed in the Settings module, and which values still depend on the server environment.

Recommended sequence: configure general settings, branding, security, sessions, mail, 2FA policy, AI runtime, then run a smoke test before opening the system to other users.

Configuration Layers

Where configuration lives
  • Framework config: values from files such as config/app.php, config/mail.php, and config/twofa.php.
  • Environment values: deployment-specific values from .env.
  • Database settings: editable operational settings stored in the settings table and loaded at runtime.
  • Seeder defaults: initial application defaults such as app name, short name, app type, timezone, and mail sender labels.
  • Installer capture: initial values collected during the installation flow before the admin enters the main panel.

Vendventory Baseline Defaults

Vendventory ships with sensible baseline values, but the runtime identity of the application is settings-driven. The seeded defaults give the installer and the first admin session a coherent starting point without forcing hard-coded names throughout the live UI.

Runtime defaults
  • App name: Vendventory
  • Short name: V
  • App type: Inventory
  • Timezone: Asia/Karachi
  • Locale: English
  • Currency: PKR with Rs. before the amount
  • Mail sender and TOTP issuer: follow the same seeded brand defaults until changed in Settings.
Seeder and installer baseline
  • DatabaseSeeder now seeds only the essential baseline.
  • EssentialDataSeeder loads settings, essential roles/permissions, and units.
  • DemoDataSeeder is optional and adds sample staff plus inventory transactions.
  • Installer Step 4 uses InstallerRequiredSeeder and optionally InstallerDemoSeeder.
  • DevelopmentAdminUserSeeder remains explicit for local/demo environments and is not part of the buyer install path.
Branding model: runtime headers, login pages, exported documents, notifications, and mail/TOTP labels now rely on shared brand defaults instead of scattered hard-coded product names.
Reset boundary: Settings > Tools > Refresh Database clears operational/demo data, but it does not reinstall the app and it does not re-run installer seeders.

General Settings

The General section is the business identity layer for Vendventory. It controls how the application describes itself in headings, metadata, emails, invoices, installer summaries, and login surfaces.

General section checklist
  • Confirm the app name and short name match your deployment.
  • Use a description that explains the business purpose of the environment.
  • Set the public app URL correctly before testing mail links.
  • Verify timezone and date format before reviewing reports.
  • Confirm the currency code and symbol before approving production transactions.

Branding

Branding settings change how the system looks, not how it calculates. They are still important because users rely on clear brand markers in the sidebar, login screen, browser tab, and exported material.

Branding scope
  • Logos and favicon.
  • Primary and secondary colors.
  • Sidebar theme, application mode, and layout mode.
  • Login-branding visibility.

Security and 2FA Policy

Security areas to verify
  • Password length, complexity, and symbol requirements.
  • Login rate limits and lock durations.
  • Email verification requirements.
  • OTP lifetime, resend cooldown, max attempts, and lock windows.
  • TOTP issuer label and recovery-code workflow.
High-risk configuration: if you loosen login limits or disable verification, document the reason and restrict access by role.

Sessions

Session settings affect how long users stay signed in, whether cookies are encrypted, whether sessions end on browser close, and whether signing in logs out other devices.

Session review points
  • Confirm the session driver matches the server capabilities.
  • Use secure cookies on HTTPS deployments.
  • Review the lifetime carefully for shared-office environments.
  • Consider forced logout on other devices for high-privilege roles.

Channels and Mail

Outbound notifications depend on correct mail and Twilio configuration. Even if SMS or WhatsApp are disabled, the mail sender details should be configured and tested so password resets, OTP messages, and invoices can be delivered reliably.

Channel verification order
  1. Set mail_from_address and mail_from_name.
  2. Verify SMTP transport details in SMTP Setup.
  3. Only enable SMS or WhatsApp after credentials and sender IDs are confirmed.
  4. Test password reset and OTP delivery with a non-admin account first.
Shared-hosting default: buyer installs now default to QUEUE_CONNECTION=sync so password reset, OTP, and admin alerts work immediately without a queue worker. Switch to database or Redis only when you have a real worker process in place.

AI Runtime

Vendventory includes a copilot layer for read-only analytics. The AI settings control whether that layer is enabled, which provider is used, the timeout, the retained question history, and the model credentials.

AI configuration rules
  • Do not paste production keys into screenshots or shared tickets.
  • Test runtime status after saving credentials.
  • Use the built-in connection test before announcing copilot availability.
  • If AI is disabled or the key is missing, Vendventory should still operate in analytics-only mode.

Production Hardening

Pre-production hardening checklist
  1. Set the correct application URL and HTTPS behavior.
  2. Enable secure cookies when the deployment is served over TLS.
  3. Review admin roles and remove unused default access.
  4. Turn on TOTP for privileged users.
  5. Validate mail and notification paths.
  6. Run automated tests and a small manual smoke pass.

Common Mistakes

Configuration failures that cause avoidable issues
  • Using a wrong app URL and breaking email links.
  • Leaving the timezone at an incorrect default and misreading report dates.
  • Using inconsistent mail sender names across environments.
  • Enabling AI without testing the connection.
  • Changing permissions without rechecking role assignments.