Design – Designing a Ticketing System with User and Admin Functionalities

ArchitecturedesignlaravelPHP

I am designing a simple ticketing system in Laravel 4. The system will simply allow a User to create a ticket, and an Administrator to answer it.

The User will be able to:

View a list of his tickets.
Create a new ticket.
View the replies to one of his own ticket.
Add a reply to a one of his own ticket.
Close a one of his own ticket.
Perform the above tasks via the url www.example.com/support

The Administrator will be able to:

View a list of all tickets.
Cannot create a new ticket.
View the replies to any ticket.
Add a reply to any ticket.
Close any ticket.
Perform the above tasks via the url www.example.com/admin/support

In other words, a User and Administrator can perform very similar, but different functionality. What are ways that I can design this system to reduce the amount of copying and pasting that must be done?

So far, I have came up with two possibilities.

Create two sets of Routes with two Controllers – one for the user and one for the admin. Copy and paste most of the logic between the Controllers, but changing a few variables so that users can only see his own tickets. Both Controllers share the same Views and Model. Add in an additional check in the Views so that the admin do not see a button to create a new ticket.

The down side of this is that I have to put logic in the Views in order to hide certain things from the admin, and other things from the user. I am also copying and pasting code between controllers.
Create two sets of Routes but use the same Controller. Use if statements in the Controller to show different Views depending on whether it is a User or an Administrator.

However, now I am copying and pasting code between views. Having two different set of logic in the same Controller may be a bit confusing as well.

Is there a better way to go about this?

Best Answer

Write two different UIs.

Really. I work on exactly such a system every day, and the user experience for your User and Administrator personae are completely different. They're different because the needs of those users are completely different.

Administrators will spend large parts of their day with your ticket list open in front of them, interacting with tickets on and off all day. The Administrator UI needs to be efficient and powerful, as befits the primary application used by its humans.

Users will go to your site once in a rare while, create a ticket, check a ticket, and leave. The User UI needs to be simple to understand and navigate, and to require almost no thought to use, as befits a rarely used application.

Related Solutions

MVC Framework – Content Management with Admin Panel in PHP

I solved this when I started using service providers with a dependency injection container to implement a module system.

Treating modules as service providers for the application is what worked best, whether they are providing new services or providing to data to existing services, like routes.

The admin panel has itself become a module that simply provides admin related routes and services to the container. Any other modules can do the same thing.

Default routes in the config look like this in JSON format:

{
    "/:controller/:action/:params": {
        "namespace": "Darya\\Core\\Controllers"
    },
    "/:controller/:params": {
        "namespace": "Darya\\Core\\Controllers"
    },
    "/:page?/:subpage?": "Darya\\Core\\Controllers\\IndexController"
}

Module routes can look like this when defined in a module class (a service provider):

// Route path to namespace prefixes:
// "/admin/info" would become "Darya\Module\Admin\Controllers\InfoController"
$router->add(array(
    '/admin/:controller/:action/:params'  => 'Darya\Module\Admin\Controllers',
    '/admin/:controller/:params'          => 'Darya\Module\Admin\Controllers',
    '/:controller/:action/:params'        => 'Darya\Module\Controllers'
    '/:controller/:params'                => 'Darya\Module\Controllers'
));

This way all the URLs of the application are nice and extensible. The next problem is deciding on route priorities, but that becomes off topic.

Dependency injection is your friend. :)

Architecture – Where to Put UI/Domain Model Manipulation Logic in ASP.NET MVC

Bear in mind that the Model View Controller (MVC) principal has been hijacked and bastardized by the web development world. In a real MVC application the model view and controller are largely orthogonal. If you insert a record into the model, the view will receive a change event, possibly with a hint as to what part of the model has changed and then update only the part of the view that is affected. This is not applicable to the web because the web is stateless so the "view" is completely reconstructed with each action. Sometimes AJAX can help with this but generally, the view cannot react to changes in the model. So don't break your neck trying to reconcile the semantics of MVC with respect to web applications. The web stack is actually pretty horrible. You are not going to find elegant design patterns in this stuff. You just have to try different things and be creative. Don't commit yourself to some design because a lot of people are preaching a particular method. I've done a lot of different kinds of programming from DSP chips to network security software and web development is probably the most difficult of all not just because the web stack sucks but also because anyting that interfaces with a human being is going to be highly subjective.

Best Answer

Related Solutions

MVC Framework – Content Management with Admin Panel in PHP

Architecture – Where to Put UI/Domain Model Manipulation Logic in ASP.NET MVC

Related Topic