Meet the frontend

VeloxFactory comes with a built-in web frontend that gives you full access to every feature without writing a single line of code. It is built with Laravel Livewire, a reactive framework that delivers a dynamic, app-like feel while keeping everything server-rendered. No separate JavaScript build, no SPA complexity.

---

Navigation

After logging in you land directly on the Report Configs overview, the central workspace. Dedicated scan users without edit rights for report configurations land on Scan2Print instead. All other sections are reachable from the main navigation.

Section	What you manage here
Report Configs	Your report templates, the heart of VeloxFactory
Report History Records	Every past rendering with status, payload, and PDF
Report Print Tasks	Print jobs dispatched to the print service
Mail Queue	Every mail that was sent or is waiting to go out, see Report Mailing
Job Scheduler

Recurring renders and the cleanup run, plus the log of every run, see The Job Scheduler Scan2Print Mobile scan station that turns every barcode scan into a print job, see Scan2Print: Printing labels by scanning Report Contexts Organisational labels and visual tags for reports Report Connection Configs Live database connections for SQL-driven reports Common Report Resources Shared graphic assets, used by reports and as inline graphics in mails Printers Master data for your physical printers, see Printers Mailers Master data for your SMTP accounts, see Mailers Mail Templates Subject, body and whitelabeling of your mails, see Mail Templates Users User accounts and API token management

The last fiveseven entries are grouped under Configuration in the main navigation. They are master data you set up once and then pick by name everywhere else.

---

The Lookup Pattern

Every section opens with a list view, powered by a Livewire Lookup component. These views work the same way across all sections, so once you know one, you know them all.

Full-Text Search

A search bar at the top filters records instantly as you type, no page reload, no submit button. Depending on the section, the search covers names, descriptions, file names, and query text.

Column Filters

Each list view offers contextual filter dropdowns tailored to the entity. For Report Configs, for example, you can filter by Context, Data Adapter, Creator, or date ranges for creation and last update. Active filters are indicated by a badge count on the respective dropdown so you always see at a glance which filters are in play.

Pagination

Results are paginated. The default page size is controlled by the PAGINATION_DEFAULT_COUNT environment variable (default: 25). See Configuration and Data Models for all available environment settings.

Persistent Filters and Paging

Every list view remembers its state. The search term, all column filters (checkboxes, dropdown selections, date ranges) and the current page are stored in your session as soon as you change them. You can open a record, switch to another section and come back later, the list shows exactly the same filters and the same page as before.

The state is kept separately for each list view. Filters set on History Records do not affect Report Configs or any other section.

To start over, click the reset button of the respective list view, the dark button with the curved arrow icon between the search bar and the green Filter button. It clears the search term and all filters of this view and returns to the first page. All other views keep their filters.

---

Working with Report Configs

The Report Config section has the richest set of actions and is where most of your day-to-day work happens.

Uploading a Template

Report templates are designed in Jaspersoft Studio (compatible version: 6.21.5) and exported as .jrxml files. Once you have a .jrxml ready, you upload it to VeloxFactory to create a new Report Config. VeloxFactory immediately analyses the file and automatically creates all associated Parameters, Fields, and Resources, based on what is defined in the template. You do not need to add these manually.

After upload you review the auto-generated records: set example values where missing, assign a Data Adapter if the report uses SQL, and upload any resource files that were detected.

Managing Parameters, Fields, and Resources

Parameters, Fields, and Resources each have their own section within the Report Config edit view. You can edit example values, mark parameters as required, upload resource files, or link a resource to a Common Report Resource, all from the same screen.

Generating Previews

Once all example values are set and all resource files are uploaded, you can generate a preview rendering directly from the edit view. VeloxFactory renders the report using the stored example values and stores the result as a preview image and thumbnail on the Report Config.

Rendering from the Frontend

You can trigger a full render directly from the frontend, without touching the API. A render dialog lets you fill in parameter values, choose an output type, and optionally dispatch a print job or a mail in the same step. The result is shown inline and logged as a History Record if desired.

---

Report Connection Configs

When creating or editing a Connection Config, the form includes a Test Connection button. Use it before saving, a connection must be in status approved before VeloxFactory will use it for rendering. An untested or failed connection will cause render requests to be rejected.

---

Report History Records

The History Records section gives you a full log of every rendering that was saved. For each record you can see the status, the exact parameters and data that were submitted, the raw JasperReports response, and, if the rendering succeeded, the resulting PDF.

From a History Record you can:

• Download the PDF directly to your browser, and the xlsx export if the record has one
• Trigger a print job, creates a new Print Task for this specific rendering and dispatches it to the print service
• Send it by mail, opens a dialog for mailer, template, recipients and attachments and creates a new Mail Task

---

Report Print Tasks

The Print Tasks section shows all dispatched print jobs and their current status. For each task you can inspect the target printer, number of copies, and any error messages if printing failed.

If a task ended up in error state, you can reset it, the task returns to pending and the print service will pick it up again.

---

Mailing

A rendered document can be mailed as well as printed. Three sections work together, and all three behave like every other list view described above.

Mailers hold your SMTP accounts: host, port, credentials, sender address and the dispatch rate limits. The form has a Test Mailer button and a Send test mail action, the same idea as Test Connection on a Connection Config. A mailer has to be active before it is offered anywhere.

Mail Templates hold subject and body. The body is written in a built-in rich text editor, so no HTML knowledge is needed. A button opens the placeholder catalog, a searchable table of every token the template can use, each one copyable with a click. A preview shows the finished mail exactly as a recipient will see it, including the colours and the logo, which can be overridden per template.

Mail Queue lists every mail task with recipients, subject, attachments, mode and status. Opening one shows the mail that was actually sent, rendered in place. From there a mail can be repeated: a dialog lets you correct the mailer or the recipients before it goes out again, so a mail sent to the wrong address is fixed rather than cloned.

Mailing itself is never configured here. It is requested per rendering, in the Generate PDF page, in the Scan2Print settings, in the mail dialog of a History Record, in a render job of the Job Scheduler, or in the mailing segment of a render request. The three sections above only provide the building blocks.

---

Scheduling

Work that repeats has its own section. Job Scheduler lists every schedule with its type, its crontab expression, the next and the last run, and how that run ended. A Run Log button opens the full history of every run of every schedule, each with its trace id.

Creating a schedule starts with the type, a render job or the cleanup run, and the form follows from there. The expression is entered either in a guided mode with frequency, time and weekday pickers or as plain crontab syntax; both write the same field, and the next five run times are shown while you type. A render job additionally takes the report, an API token, the output and print settings, and the same parameter and data row tables as the Generate PDF page, here with a switch per field for entering a placeholder such as [now.date] instead of a fixed value.

Run now starts a schedule immediately without moving its next slot, which is how a new one is tried before it is switched on.

---

Users and API Tokens

User accounts are managed under the Users section, accessible to administrators only. Each user can hold one or more named API tokens, which grant API access under that user's identity.

From the user edit view you can:

• Create a new token and copy it immediately after generation (it is only shown once)
• Revoke any existing token with immediate effect

---

---

Permissions

Every user in VeloxFactory has a set of permissions that controls what they can see and do, both in the frontend and via the API. Since both use the same underlying controllers, a permission that restricts an action in the frontend restricts the exact same action via API, and vice versa. There is no way to grant API-only or frontend-only access to a resource.

Permissions fall into two categories: global and per-resource.

Global permissions:

Permission	Effect
global:admin	Full access to everything, including user management
global:use-api	Allows use of the API and management of own API tokens

Per-resource permissions, available for each of the following resources: report-config, report-connection-config, report-context, report-history-record, report-print-task, report-mail-task, common-report-resource, printer, mailer, mail-template, scheduled-job:

Permission	Effect
<resource>:full	Full read/create/update/delete access to this resource
<resource>:read	View records only
<resource>:create	Create new records
<resource>:update	Edit existing records
<resource>:delete	Delete records

global:admin always implies full access to all resources and overrides any per-resource setting.

scheduled-job:* also covers the run log. Changing or starting a render job is limited to its owner and to administrators, because it acts with the owner's permissions; reading it is not.

Feature permissions:

Permission	Effect
scan2print:use	Access to Scan2Print. Implicitly includes report-config:read, report-print-task:read and :create, report-history-record:create and :update

scheduled-job:create Creating a schedule means rendering, printing and mailing with it, so it implicitly includes report-config:read, report-print-task:create, report-mail-task:create and report-history-record:create and :update. scheduled-job:full does the same

---

Frontend vs. API - What is the Difference?

The short answer: there is no feature difference. The frontend calls the exact same controller methods as the API. Everything you can do in the UI, you can also automate via API.

The frontend is optimised for interactive, human-driven workflows, exploring reports, reviewing history records, testing connections. The API is the right choice when you want to integrate rendering into external systems, automate repetitive tasks, or process results programmatically.