Implement "clients" as an entity type

That is an interesting idea. Ideally we'd want to allow clients to be any number of content-types, allowing complete integration of CCK into support tickets. It's worth exploring, but doubtful to be implemented anytime soon.

I think this would be a wonderful idea. I think it's unfortunate that there doesn't seem to be all that much interest in supporting different content types and content customization via CCK.

I wish I was more code oriented because I would be interested in seeing this move ahead.

This would a great idea. It would be great if you could use the the client as an og

I've been pondering this as well and my thoughts have been something like this:

My first thought was to implement a way of getting STS to support different content types, this however seems hard to integrate and would probably mean a big change to the way the module works today.

My next thought was to make a custom module that would integrate with STS and the default content type. The way I picture it working is like this:

You add all the fields you want to be able to choose from to the support_ticket content type. One would then make the custom module do 2 alter_form calls where the first call would add checkboxes/radio buttons to each client so that you can choose to configure the client with extra fields.

The other alter_form would be for the display where it decides what fields to display based on what fields are 'activated' in the client settings.

What are your thoughts on this?

I plan to convert the support module to make clients content types, allowing you to build any number of different client types each with different fields. However, at this time I'm also leaning heavily toward adding this functionality only in the upcoming Drupal 7 branch, where Fields UI is in core.

I'm keen on doing this for version 6 as well.

Have you started anything that I could continue or should I start from scratch working from my idea in comment #4?

If you don't want it in 6, perhaps I could make a plugin for this?

+1, subscribing...

@span, I have not yet started this effort, I'm merely thinking about how it will work yet. In 7.x, it will be part of the core support module, and should make the module significantly more configurable. You'll be able to build clients, and add any number of fields to the tickets thanks to Fields in core.

In the 6.x version, a plugin module would likely be the best approach, agreed. What I discuss above is vapor ware until I find time and energy to tackle it.

@jeffschuler, I'm not sure how your link is relevant to this issue?

There is now an add-on module available that allows the admin to go into the settings for each client and select which custom cck fields are to be displayed.

Module can be found here:
http://drupal.org/project/support_fields

I'm still developing this and doing refinements but it gets the basic functionality in place.

I have started working on a module to do this and would like a little feedback before I get in too deep. My thoughts were to add a hook to support_admin_client_submit that fires when a client is added/updated/deleted. My module would hook in and maintain a parallel node with the client information that is based on CCK. I would also update any information that is changed in the node back to the support client table.

Does this sound like a reasonable way of making clients available as nodes? Does anyone see any major issues that I should watch out for?

Thanks for your input.

@qjensen, how does your effort differ from what span is working on and links from update #9? Are you looking to add information to the clients themselves, versus their tickets?

I would like to be able to add information to the clients themselves but more importantly I want to expose the Clients as actual nodes. Here is my use case.

My customer has multiple clients. Each client can have multiple locations and multiple contacts. We could create a support client for each combination of client/contact/location, but that gets messy over hundreds or even thousands of combinations. It also limits the kind of information we can collect/track/report on. By exposing the client as a node, I can create a contact type and a location type that are both related to the client using a nodereference field. I can also add fields to the client that have nothing to do with the support system (such as a bill-to address for billable calls) that isn't supported by any other solution.

To accomplish this, I would need a hook in the core support code that would be called when clients are added, modified or deleted. I have a beta started and it only requires 3 module_invoke_all lines in support_client_admin_submit.

I am assuming based on discussions in this node that others would like to see the clients available as actual CCK types as well, and it sounds like you are planning on doing this for D7. I just wanted to make it for D6.

Once the 7.x-1.x port is completed, I intend to branch 7.x-2.x where Clients and Tickets will be fully configurable entities.

Clients as an entity type is in git as of now.

This is a first step towards the goal of allowing stuff like this.

Jeremy, do you think there will be an upgrade path from 7.x-1.x to 7.x-2.x?

@Jeff, yes, we intend to provide an upgrade path. We're using the module heavily ourselves, and will certainly be testing the upgrade path for our own content...

i just started using this module a few days ago. was also thinking if it included a clients function would be great. its already in motion, good stuff. was also thinking that projects could also be integrated as an entity. would be pretty much complete as a project management system. any thoughts?