Custom Post Types for Support Ticket plugin?

I am about to write a (quite simple) plugin for support tickets, where a user signs up, adds one or more sites, and adds support tickets under each of the sites.

My question is about how to structure this without relying on other plugins for functionality:

Read More
  • The user signs up and gets a new role (such as ‘Customer’).
  • When the Customer adds a Site, that Site is only visible to the Customer and noone else. A Site would be a Custom Post Type, I suppose.
  • When the Customer adds a Ticket to a Site, that is only visible to the Customer. Tickets would be CPT’s as well, I suppose.

In terms of best practice, am I right to use authors and roles for visibility and CPT’s for Sites and Tickets?

And how do I create the relationship between Site and Ticket? I know there is a Post 2 Posts plugin, in addition to others (like CPTR), that manage relationships between post types, but I would much prefer to avoid relying on others for core functionality in this plugin.

Edit: I’m trying to see if somehow custom taxonomies could play a role in this puzzle, but I don’t see how it can fit in. Any suggestions are welcome.

Related posts

Leave a Reply

1 comment

  1. Custom Post Types are a good solution for you what you are trying to achieve. In fact, in almost all cases, where regular Post of Page types don’t fit your use-case, then Custom Post Types will. They should be thought of more as Custom Content Types rather than the aforementioned. That gives a little significance to their purpose.

    Do you need the Posts 2 Posts plugin by Scribu? No. Good plugin, in fact the only one that is consistently recommended for associate one post to another or many other, however in your instance you are dealing with a client (customer), their personal particulars, which include a “site” as you say so…

    This can be handled with,

    How you create the relationship between Site and Ticket depends on what you are offering to the client. Is it one Site per User or is it Multiple Sites per User?

    Either way, I am thinking so far that User Sites should be added as user meta data, so whether you allow them to create ONE or MANY sites thats up to you. When a user is lodging a ticket, you might then offer them a drop down to select which site the ticket is applicable to. This drop down menu for example (select menu) would pull its data from the relevant user meta fields associated with that user.

    How you have this come together within the Custom Post Type edit screen is quite simple, through the use of Custom Meta Boxes which give you the ability to add a functional user interface to your custom fields.

    Two Custom Meta Box classes I recommend that you look into which will help ease the process of building meta boxes are;

    There are others, but these are two that I have used and still use consistently. I’m more partial to WPAlchemy because that was the first class of its type I started using on mass, but I now use both interchangeably. Some arguments have been made against both, which is better and why, but… That’s for those code connoisseur types to worry about :)

    Custom Taxonomies can play a role too, however you might think of using taxonomies as you would categories. For example you might use a taxonomy to classify the urgency of the ticket,

    - High priority
    - Medium priority
    - Low priority
    - Inquiry only
    - Bug report
    - Suggestion
    

    …whatever.

    You could even provide the above via post meta fields too, not just taxonomies. Some meta box classes allow you to easily integrate custom taxonomies right into the meta box design. Otherwise you can use the normal taxonomy meta box that renders itself once registered and associated with your post type. Possibilities are somewhat endless but don’t get too caught in taxonomies, just remember that they are going to be useful to help classify information and that which your users can make use of collectively on a per ticket basis.