your opinion for integration in existing app

[fbollon]

Hello I would like to have your opinion. I would like to integrate panichd to an existing application that is used to manage stuff and from this stuff offer the possibility to create tickets and therefore have a link between this stuff and the associated tickets, to be able to list the tickets from the stuff and have a link in the tickets to the stuff. I created a pivot table (ticket_id, stuff_id), I created a form in my application and I create the ticket as suggested in the wiki :

use PanicHD\PanicHD\Models\Ticket;

$ticket = new Ticket;
$ticket->subject = "Your ticket subject";
...
$ticket->save();

Then I insert a row in my pivot table.

The principle works, I can list the tickets created this way in my stuff. But it will force me to rewrite a whole specific form and there will be the problem of the link from the ticket to my stuff ...

I thought that a solution would be to add two columns in the tickets table (linkable_type and linkable_id for example) and to be able to fill them in hidden fields of the ticket creation form by passing them in parameter when calling the form.

What do you think about it? Any other ideas?

[fbollon]

with the pull request #44 I solve the problem of link from the ticket to my stuff

[xaviqv]

Hi @fbollon,

As a resume for your issue and using "Element" as a model example, you want to integrate PanicHD tickets with the "Element" model in your app with these requirements:

• Link between Ticket and Element models in your database
• Open related Tickets from a specific Element view
• Open related single Element from the ticket view. You don't want to be able to relate a Ticket to many Elements.
• Create a reusable relationship from the Ticket model, so in the future be able to link a ticket to a "Computer" model, as an example, instead of Element.

Are these points correct? Or am I missing something?

[fbollon]

this seems to me to be a good summary unless I make a translation error

[xaviqv]

Hi @fbollon,

In PR #44 you have created a Laravel eloquent polymorphic one to many relationship to cover your current needs, as we have pointed out in this issue.

In the Laravel docs you may have already seen that the perfect example for this kind of relationship is a "Comment" model. If we have for example some publications in our app managed by the "Publication" model, where we may have comments, It would be really weird to have a single comment related to a Ticket and to a Publication, so this relationship would fit well.

I think that a PanicHD "Ticket" as a concept may have a more general application manner than a "Comment". I will add some examples to clarify how actually can it be used:

• Imagine you have some hardware inventory models in your app, like i do. One of these let's say is the "Phone" model. When I have to register a repair report for several phones, I create a single ticket and add links in ticket description to the phones pages. If I plan someday to link the models directly instead of this manual job, I would need a single Ticket to link to many "Phone" instances, so It would not fit with a one to many relationship.
• You have a "Computer" model and a "Printer" model. From both of them your interest is to keep track of any related tickets. A PanicHD member registers a new ticket with this content: My default printer doesn't work. Even though you finally realise that the user was trying to print in color and that's a forbidden option for her/him, you have two related instances from different models on the same ticket.

I could add more examples to try to explain better what I mean. I would not use a One to Many Polymorphic relationship because It's not flexible enough for a growing Laravel app. Sooner or later, It will simply not be sufficient. Instead of this approach, why not creating a Many to Many kind of relationship? I think that your first comment in the issue was pointing in the right way and later in your PR you changed your mind. In fact, this kind of relationship will let you link a ticket to a single model if you want to, it's your decision.

I deliberately said "kind of relationship" because i also think that the best approach for several Many to Many relationships with a single Ticket is to have a dedicated pivot table for each of them, instead of having a Laravel flavored mixed pivot table with a bunch of different relations in it. I've tested the polymorphic one but I'm not convinced of any advantage for it over the "traditional" one.

Regarding to these URL additional parameters for the ticket creation in your PR #44 I recommend you a different approach to have this feature, that consists in:

• Make your "Create ticket" link from the "Element" view open a new route
• In the new route, register your required variables as session keys and redirect to panichd ticket creation
• This point is just a suggestion: In the ticket creation view, you could add custom visual information to notice the user that the registered ticket will be related to your Element
• Create a Laravel observer for the Ticket model
• Use this observer to register your ticket relation to the Element model using the created session variables.

I recommend also to think carefully the way you're going to implement these session variables, to ensure that they come form a concatenated event of 1. Element view 2. Ticket creation. This basically means to add some checking before using them and also don't forget to erase them when they're not needed anymore.