Open new ticket via email

[dmecke]

First, thanks for sharing this bundle!

I would like to know if you are planning / accepting a pull request to add support for creating new tickets via incoming emails. So customers could send an email to support@acme.com and a new ticket is opened automatically and answers are sent back to the customers email.

[hackzilla]

I'm happy taking this bundle in new directions, as long as they are optional (via config).

If you send me a PR I'm very likely to accept it.

[hackzilla]

The TicketManager was added a while ago, so this would be straight forward to add as to an additional project.

Receiving email within this bundle would be too bespoke.

[Filoz]

@dmecke , @hackzilla ... in my opinion this optional feature would be fantastic...

[hackzilla]

The TicketBundle allows anyone to create tickets and messages using the TicketManager.

Hackzilla\Bundle\TicketBundle\Manager\TicketManager->createTicket();

The only bit missing would be the reading of the email messages and figuring out what to do with them.
That is the bit I feel is too bespoke for this bundle.

I could write a guide of how I'd create a bot for Telegram.me, that anyone could adapt to email, or any other system.

[Filoz]

@hackzilla , yes... a bot for telegram would be interesting too!
There are many system that can be adapted (email, facebook bot, ?whatsapp?, ...). An example of how you did for telegram would be very usefull

[Filoz]

@hackzilla I thought about the possibility to add more systems, in particular imap/pop3.
This can be an optional feature (with optional dependancy) that should not so difficult to do.
There are some way to read email from php, for example: http://php.net/manual/en/function.imap-check.php or this library https://github.com/barbushin/php-imap

This feature can be disabled by default and enabled with a setting, the same as others system (telegram, facebook, ...).
Provide to user some extra system they can extend can be very interesting, IMHO :)

[nicolas-san]

I work on this, someone would try it ? I finish today on my dev env, I will push to my preprod on monday, I miss the configuration option in the docs, if someone wants to test, I can explain before monday :) @Filoz @dmecke

[Filoz]

Hi!
I will give look for sure when you pull it to your repo :)

[nicolas-san]

@Filoz I have updated the doc and pushed a feature branch to my fork
https://github.com/nicolas-san/TicketBundle/tree/feature_notification_and_ticket_from_mail

I add the notification bundle from https://github.com/flodaq/TicketNotificationBundle as a feature (with is approval :) ) and add a "ticket from mail" feature. You need to have notification feature enabled to use the ticket from mail, because I rely on is mailer (to avoid code duplication, and speed up the dev)

I will test it on my preprod today, feel free to report any trouble, I may not have thinking about everything.

@hackzilla I am not familiar with this, but can you open a feature branch, to merge this one, so we can use it with composer on packagist to beta test ?

Thanks

[hackzilla]

You can add this to your composer.json to override the repository.

    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/nicolas-san/TicketBundle"
        }
    ],

Then you will be able to put

    "require": {
        "hackzilla/ticket-bundle": "dev-feature_notification_and_ticket_from_mail"
    },

That way you still have control of the branch, without needing me to pull changes.

[Filoz]

Wow, it looks very promising!
Sure I will try!!!

I gave a fast look the the source and it looks ok!

From the doc should be pointed out that is both possible to create a new ticket and reply an existing ticket from email.

Maybe a good feature is to add 2 option:

• alowNewFromEmail
• allowReplyFromEmail

because sometime you want that only logged user can open new ticket so open a ticket by email should be disabled and must return an email like 'To create a new ticket please go to htt....'

In the email I think that would be better to add a random (and unique) code (referring to the ticket) instead the id, otherwise someone can reply to a different ticket simply changing the id in the email.

This part should be changed https://github.com/nicolas-san/TicketBundle/blob/feature_notification_and_ticket_from_mail/Command/TicketFromMailCommand.php#L63 .
Maybe we can add to the doc that an user with username ticket_system MUST exist or... add an option to specify the default username to use.

the last thing IMHO should be added is a flag that specify if the ticket/reply was added by email or not, because can be useful to know where a given ticket comes from.
Or better, instead to add a flag, if @hackzilla agree... it can be added a field in base Entity... something like

    /**
     * @ORM\Column(type="string", length=20, nullable=true)
     */
    protected $createdFrom;

(the name should be improved :) ) and it's value can be 'web' if it is created from the ticketing pages, 'email' from email, 'telephone' (can be a future extension, the admin opens a ticket and set the author)...

[nicolas-san]

Thank you for your message.
I understand your options, but, is it logical to enable the feature "ticket by mail" bun not allow new ticket by mail ?
IMHO new mail to support email address should be always manage as a new ticket.
If you really want to disallow non user to submit a new ticket by mail, perhaps an option to open a new ticket only if the sender email correspond to an user account ?
And send a generic response to others, something like "This is the client support email for registered user only, for the general support use this email instead"

?

[Filoz]

Yes, this is a very good solution!

[hackzilla]

@Filoz We shouldn't need to modify the base entity.

I added something called "Features", to describe the database changes required.
See TicketAttachment classes in Model/ and Entity/

[nicolas-san]

I push today my production ready code.
I have the minimal features I need to start with.
I really open to all suggestion if someone use it.

@hackzilla would you merge my branch into the main project ? Would you review and test it first (you should :) ) ?
I have done my best to follow your original code and architecture, and nothing is mandatory, new features are activated by an option in the config.yml, and I add new field in different entity mapping and traits

[hackzilla]

Hey @nicolas-san, thanks for doing this.

I'm of 2 minds of whether this should be in the TicketBundle, or a separate bundle.. (Like TicketNotificationBundle)

Currently I'm working on #109, my head is currently thinking through that, as I'm trying to sort out #110

In terms of following my architecture, the only thing I was would change, is the entity.
My plan is for people to have their own entities, and I was using traits to make it easier for others to add the various ticket features to their entities.

[nicolas-san]

Is it an issue for you if I fork ? (I know I can, but I prefer ask your feeling about before I do) I can understand if don't want to merge, and If you won't I will continue modifying it to suit my needs but with more liberty to change core things.
I just prefer publish my work if some can use it, it's the spirit !
Let me know :)

[hackzilla]

I wasn't saying no.

Currently I'm maintaining 2 versions of the ticket bundle, and there is likely to be another when symfony v4 is out.

So I've trying to split out the functionality of the tickets, and just leave the framework implementation.
https://github.com/hackzilla/ticket-message

I'm happy to help you after this to turn your branch into a library which uses TicketBundle.
On the other hand, if you decide to Fork, then I wish you the best of luck.

[nicolas-san]

My first goal was to add functionalities and merge :)

I can't see precisely what I have to do after your work on the library.
If it's ok with you, I do nothing more for now, and I try to not touch the core, and after your work we see if I can, with your help use your library, and why not merge my functionalities to the ticket-bundle base ?
Or anyway that suit the project, and my needs

[hackzilla]

I'm going to pull in your work, but It'll be part of #109 (which will become v4).
I'm trying to keep this flexible, and be able to use different security., and database.

[hackzilla]

I'm currently looking at this.

$mailsNotAllowed = $this->container->getParameter('hackzilla_ticket.from_mail')['mails_out_not_allowed'];

@nicolas-san Is this a email blacklist?

[nicolas-san]

Yes something like that, I use it to manage some specials emails from some users.
One good way to go is to have a method to the user abstract class to allow or not sending emails, but for now it does what I need :)