Skip to main content

Meet the frontend

JasperWho? 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.

main-menu-2.png


Navigation

After logging in you land directly on the Report Configs overview — the central workspace. All other sections are reachable from the main navigation.

Section What you manage here
Report Configs Your report templates — the heart of JasperWho?
Report History Records Every past rendering with status, payload, and PDF
Report Print Tasks Print jobs dispatched to the print service
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 reused across multiple reports
Users User accounts and API token management

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.

report-history-record-index.png

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.


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.

report-config-edit.png

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 JasperWho? to create a new Report Config. JasperWho? 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.

report-resource-edit.png

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. JasperWho? 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 in the same step. The result is shown inline and logged as a History Record if desired.

filled

config


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 JasperWho? will use it for rendering. An untested or failed connection will cause render requests to be rejected.

connection-config-unapproved.png


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
  • Trigger a print job — creates a new Print Task for this specific rendering and dispatches it to the print service

history-record-detail.png


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.

print-task-index.png


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

user-edit-1.png


user-edit-2.png


token-modal.png

⚠️ Copy your token immediately after creation. JasperWho? only displays the token value once. If you lose it, you will need to revoke the old token and create a new one.

Permissions

Every user in JasperWho? 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, common-report-resource:

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.

ℹ️ API token permissions are inherited from the user. A token does not have its own permission set — it acts with exactly the permissions of the user it belongs to. Revoking a token removes API access; the user's frontend permissions remain unaffected.

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.

ℹ️ Ready to explore the API? See Meet the API for authentication, query parameters, and a practical render example.