Assign ticket to someone

[yhanini]

Thanks for sharing this projet.

If you have not already planned, it would be logic to have a functionality for assigning to somone a ticket. Even with notification by email.

[hackzilla]

Thinking about this, I can't understand how the assigning would work.

In the bundle there are 2 types of user, those with ticket admin role, and those without. The way it works at the moment is admin users can see all tickets, and those without can only see their tickets.

There are events firing so adding email notification would straight forward for someone to do outside of the bundle.

[yhanini]

We should be able to assign a ticket to a specific user then this user could show his tasks and treat them by priorities or scheduled date and when it's done (resolved), he will assigne the ticket to the owner. The way it work now, it's like a private messaging with status and priority. We should turn the real goal of the bundle to a system such a bug tracking system or redmine.

You can add in the entity Ticket a new field assigned_to and date limit ? Do you agree ?

[hackzilla]

This sounds interesting, but will require more thought.

I will revisit this after some of my other neglected projects.

[jdambacher]

+1 We need this for our project. Maybe I will implement it and open a PR.

[mistris]

Has someone implemented assigning?

[hackzilla]

Not at present.

I have been quite busy recently.

The next feature I'll be implementing will be #51

[mistris]

@hackzilla do you know when could you implement assigning functionality?

[hackzilla]

It's probably going to be at least month.

51 is currently in progress.

[hackzilla]

I've decided I will attempt this for v3. I haven't made a start of this, but I will soon.

[Filoz]

hi @hackzilla , I need something like "assign ticket to someone", but simpler: I need to assign the ticket programmatically.

So I'm writing the code but I would like to have the same name for entity field you will use for the assignee. Which name do you think you will put in Ticket Entity for that user?

so... in the future I will have no problem if I would like to switch to your more complex system (assign ticket from the gui)

[hackzilla]

I have no planned names at the moment. If you name it something then I'm likely to stick with it. (actually, I'm moving away from entities and towards interfaces. i.e. https://github.com/hackzilla/ticket-message/tree/master/Model).

I haven't given ticket-bundle the time it deserves for the last few months. However, I am currently at Symfony Live London, learning about Symfony 4.

So I think I'm going to have to do a proper push, and get Ticket Bundle v4 working/released.

[Filoz]

Wow, I would like to be there too!

I was thinking to something like "userAssigned" because of "userCreated" field. What do you think? If you have a better name do not hesitate to suggest it :)

Using intefarces is really a better choice when working on open project like this.

Thank You!

[hackzilla]

my preference would be userAssigned.

Yhea, interfaces feel better. A bit more work for the setup, but it allows people to store whatever they want in addition to the stuff for ticketing.

[hackzilla]

@Filoz Symfony Flex is awesome. I didn't know about it until now.

[masonen]

@hackzilla in another service I developed a way to make tickets asignable to any entity (even other tickets) wich obviously includes users. Making entitys assignable is as simple as implementing an interface and 2 static functions for mapping purposes to the disired entitys. If this is still an active request I will be happy to prepare a PR implementing my aproach into your service. Need some time though. This could be used further to implement an access con troll feature by users usergroups or any other entitys assigned to a ticketable entity.

[hackzilla]

I've taken a step back. @phansys Does this feature still make sense?

[phansys]

Hi! I think this feature is useful for scenarios which the implementation tries to cover features like provided by helpdesk platforms or similar, where the ticket must have a responsible regardless its creator. In my own use case, I have this feature implemented via inheritance of the provided model, adding the missing properties at my own persistence layer. As first step, I think we need to work in #128, in order to add support for specific use cases, while later we could analyze which features must be provided out of the box.

[masonen]

That helpdesk scenario was exactly my usecase. I needed to be able to assign users to a ticket to give them responsibility for the ticket but also make tickets filterable by any entity or even its child entities. Its a maintenance system for real life objects wich need to be maintained by technicians.

I introduced a own TicketAssignment entity wich handles the Mapping. Each entity wich is assignable implements an interface and thats basicly how you make entitys assignable in my Bundle. Quite easy to make new Entitys assignable. Could provide my aproach. Possibly even after #128, if you need any help there, let me know