The Data Model Behind osTicket 2.0
One of the most powerful ideas in the original osTicket was the concept of queues.
Queues allowed administrators and agents to organize tickets dynamically, with access controls applied automatically. Instead of browsing through everything, you could define rules — “My Tickets,” “Overdue Tickets,” “Answered Tickets” — and the system would present exactly the subset of data that mattered.
Under the hood, queues were essentially a clever combination of filters, conditions, and permissions layered on top of the ticket data.
If you squinted a little, they behaved a lot like smart folders or labels in an email system.
Or, from a developer’s perspective, a well-crafted WHERE clause with a user interface.
For years, that simple idea proved incredibly powerful.
But as osTicket evolved, it became clear that queues were only scratching the surface of what we really needed.
In osTicket 2.0, that idea evolved into something much broader:
Views.
Views are no longer limited to tickets. In osTicket 2.0, a view defines how a collection of models is filtered, sorted, and projected as either tabular data with dynamic columns or card-based layouts.
Those projections can then be reused throughout the system — appearing as lists within the interface, rendered as card layouts, or serving as the underlying data source for dashboards and widgets.
In other words, views are no longer just a feature.
They’re part of the system’s data architecture.
Views Everywhere
In osTicket 2.0, views are designed to work everywhere.
A view describes how a collection of models should be filtered, sorted, and projected into either tabular data with dynamic columns or card-based layouts. Instead of defining these rules separately for every interface, the system defines them once and allows different parts of the platform to reuse them.
The same view can appear as a list in the interface, power a card layout, or serve as the data source behind dashboards and widgets. Each surface simply projects the data differently while relying on the same underlying definition.
This approach aligns naturally with the projection architecture introduced in the previous article. The platform defines capabilities and data structures, while different interfaces project those capabilities in ways that make sense for their context.
In that sense, views become the language the system uses to describe data.
But making that language work across the entire platform introduced a new challenge.
When Eloquent Meets Reality
Laravel’s Eloquent ORM is one of the reasons Laravel became so popular.
It’s expressive, intuitive, and elegant when dealing with straightforward relationships. Defining models, navigating relationships, and writing queries often feels almost conversational.
But like most ORMs, things become more complicated once queries need to cross multiple relationships dynamically.
Developers who have worked with Eloquent long enough know the moment when things start getting awkward.
Simple relationships are beautiful.
Dynamic joins… not so much. That’s usually the point where Eloquent starts losing some of its eloquence.
To be clear, this isn’t a criticism of Eloquent. The problem itself is difficult.
Once you allow users to build dynamic views across models — filtering by related data, nested relationships, and conditions that aren’t known ahead of time — the underlying query generation quickly becomes one of the hardest parts of the system.
And osTicket 2.0 needed to solve exactly that problem.
Because if views were going to exist everywhere, the system needed a way to dynamically understand how models relate to each other and construct the appropriate joins automatically.
That’s not something traditional query builders handle particularly well.
The Hard Problem: Relationships
Consider a simple example.
Imagine a view filtering tickets based on attributes of the ticket owner’s organization.
The path might look something like this:
ticket.user.organization.name
To retrieve that information, the system must understand the chain of relationships and construct the correct joins behind the scenes.
Now imagine that this logic needs to work dynamically, based on filters defined at runtime rather than hardcoded queries.
Multiply that across dozens of models and relationships.
And suddenly the system needs to solve a surprisingly complex problem:
how to build the correct joins automatically, every time.
The Auto Joiner
After exploring existing approaches, it became clear that nothing in the ecosystem quite solved the problem the way osTicket needed.
So we built one.
The result is a small Laravel package called Auto Join Eloquent.
The goal of the library is straightforward: allow the system to reason about relationships between models and automatically compile & construct the joins required to satisfy dynamic queries.
Instead of manually defining every relationship traversal in advance, the system can analyze the columns and criteria defined by a view, and determine the appropriate joins needed to retrieve the data.
In practical terms, this allows views to operate across relationships without requiring developers to handcraft complex query logic every time a new filter is introduced.
Sometimes the only way forward is to build the tool you need.
Why This Matters
This capability is what makes Views Everywhere possible.
Once the system can dynamically traverse relationships and construct queries safely, views become far more powerful.
They can operate across models.
They can filter by related attributes.
They can aggregate and organize data in ways that were previously difficult to express.
And because views now describe data independently of how it is rendered, they can power multiple parts of the system simultaneously.
A view defined once can appear as a table or card layout, and can also serve as the data source for dashboards, widgets, or reports.
A New Data Layer for the Platform
Just as osTicket 2.0 introduced a new architectural foundation for the platform itself, views introduce a new foundation for how the system works with data.
They allow the platform to describe what data means, rather than just how it should be queried.
And once that language exists, the rest of the system becomes far more flexible.
New interfaces can be built more easily.
New visualizations can appear without rewriting queries.
And new automation tools — including AI-driven workflows — can reason about the same underlying data model.
In many ways, views are the connective tissue between the platform’s architecture and the experiences built on top of it.
What Comes Next
Views are only the beginning.
In future articles we’ll take a closer look at the pieces that make this system work, including:
the criteria language that defines view logic
how the auto-joiner understands relationships
how views power widgets and dashboards
and how developers can extend the system with their own data projections.
For now, it’s enough to say that queues were just the starting point.
In osTicket 2.0, views are everywhere.