Emails notification subscription of ticket authors does not happen when they open new tickets by sending email to support

> However, the user does not get any e-mails when one of the admins responds to their ticket.

Users will only receive emails if they are subscribed to the ticket. That is what subscription is.

> 2) E-mail customization.

Directions on how to do this are provided in the MAIL.txt document that comes with the support module.

When creating tickets, please limit them to one topic apiece -- when you cram multiple topics into one issue, it quickly becomes confusing for all involved.

> Does that indicate that the user creating the ticket should always be automatically subscribed?
> Because they're not, and that seems to be why they aren't getting any e-mail notifications.

Yes, I will see if I can duplicate that. That would be a bug. But note that when this is working correctly, they will also get a notification when the ticket is first created, not just when it is later updated.

can confirm I'm having this issue as well with support-6.x-1.x-dev.tar.gz

In support_save_message()

} else if (...newnode...){
    $node->created_by_email = TRUE;
    node_save($node);

The corresponding section in nodeapi is as follows:

// auto-subscribe ticket creator
if (variable_get('support_autosubscribe_creator', FALSE) || isset($node->created_by_email)) {
  support_subscribe_user($node->nid, $node->uid);
}

created_by_email not carrying through?

I am also having this issue. I can't even subscribe the original creator and thus unable to respond to their email.

hi, have you had much luck with the patch? Ive been trying to get this support module up and running for weeks but cant code things myself, can you let me know if it works?

The patch works - but not with current head. Manually appling works fine for me

Yes, I'll confirm that the patch works. Manually applied and it did exactly what I was hoping for.

Thanks for the patch.. I have patched support 6.x-1.3 and it works... however, i keep on getting PHP internal server errors when i run cron job or add new comments to a ticket.. However, very few times after couple of retries the error does not come... When i update the support.module with the original file (the unpatched one), these errors are gone.. Hence cannot put it in the production env.. Any one else facing the same issue.???

I have even tested the version 6.x-1.x-dev as of today and the bug is still in there.. The users who create a new request by email do not get subscribed to the ticket notification, even if we have 'Prevent user creating or updating ticket from unsubscribing' checked in the setting page. Hence they do not get an email that the request is created, or any updates..

Sorry, I can't reproduce the error. My system is live and running well.

I think you are creating a request by logging in with a user. Have to tried creating a request by sending an email.. where the support module add a new user (if he/she does not already exist) to the durpal system, and creates a new ticket. Now, at this stage, the support module should also subscribe this user to the new ticket, since he/she is the one who has created it. This is precisely what is not happening. If you are using the support module with integrated email, can you please test this above mentioned scenario and let us know the result? Many Thanks..

I am not wondering if perhaps the other people who are unable to reproduce this error are trying to reproduce it by creating the ticket from the support module itself instead of sending an email. Also, the title of this Issue does not mention that this issue is specific to the setup where email is integrated. Perhaps i should try to change the title.

I have changed the subject to clarify the issue/bug.

Apart from this bug, however, the original issue creator apparently also have another requirement of an option of making the ticket creator/author (through email) only get the update email messages (notification) and not the initial new ticket email message (notification). Thus, the original issue creator is requested to create another issue request regarding the same, which i believe will be categorized as future request (instead of a bug), as this particular issue entry is now focused to address the bug.

My request comes from an email sent from the contact form, not a user.

Dear All,

I think I found the solution..

go to /admin/user/permissions and enable 'access ' for the 'authenticated user' column. This will enable the notifications to be sent to the user email that originally created the ticket (since that user is authenticated user and needs to have the permission to access any property of the ticket (notifications in our case).

Although giving the permission to 'access client tickets' to the authenticated users does solve the problem of emails being sent to/received by the email based ticket creators, however, doing so enables the names of these users to appear in the assigned drop down list of the tickets, as if these users could be assigned the tickets to find a resolution.

Perhaps the permission entry 'access client tickets' mean:

1) Only the users with the permission entry 'access client tickets' can be subscribed to the the tickets (or any thing other access).
2) The users with the permission entry 'access client tickets' fall into the group of users that can provide support to solve the tickets.

What do you all think is the right solution to this problem? I have been thinking a lot on this and came up with the following possible solution (from the functional aspect), but I am not sure if it is practical and can be implemented from the technical perspective. I will mention it over here, and if it is not correct, at least it will give some material to think about for progress:

- Email based ticket creators get the 'access client tickets' permission automatically assigned to them.
- Only users with the additional and new 'can be assigned tickets' permission will have their name appear in the assigned dropdown list for tickets. Of course for this to work, the users must also have the permission of 'access client tickets'. Other users with only 'access client tickets' and not the 'can be assigned tickets' permission will not be able to be assigned the tickets.

Suggestions?

Thanks..

Yep, tested further.. and I think user having permission to 'access client tickets' and being able to get assigned ticket is not correct.. There should be another permission for users that can be assigned the tickets.. In the current scenario where i have given the access client tickets permission to all authenticated users, the email based ticket creators do get the email notification, however , if i have 5 support staff, and 50 users/customers, and all of them are listed in the assign dropdown list.. when instead only 5 support staff should have been listed.

here are two screenshots. One of my permissions, the other of a comment field (those are only my employees, and there are currently 96 users in the database. Those 96 comprise of both employees and support ticket people. The ticket people fill out a webform, it's POP'd into the support module, and replied to from there.

My clients include three or four email addresses (general, reservations, accounting, marketing, tech, etc...)

That's about all I can offer, hope that it helps.

Hi,

I'd be in favor of the second option. Access tickets resulting in updates being sent to the email address that created the ticket, and the permission of 'can be assigned tickets' preventing all available Drupal users from appearing in the 'assign to' list.

Let me now present the other option which is the default and part of the original specifications. After proposing a change in functional specification (Above), and playing with the module for a while, i am now tilting back to the original specifications. The original specification seems to be simple:

- All email based ticket creators get subscribed to the notification for that new ticket (i believe this is not working at the moment, and can be fixed with the patch provided by mankind)
- 'Access client permission' is meant for the client support staff, and all users with this permission get their names in the assigned dropdown list (i think this is working fine).

So in all and all, if above is the original functional specification, perhaps only fixing this bug will solve the problem.

What do you all think?

@namalik in #23:

This could work but in this case the documentation should explain that 'Access client' permission actually means the user will access this clients tickets AND be included in the assignable users list for that client.

So has there been any progress in this automatic subscription issue?

Updating version and priority. Still needs to be resolved.

Patch from #8 no longer seems to be valid with the lates 6.x dev (from dec. 1)
I tried it and got:
patching file support.module

Hunk #1 FAILED at 667.
Hunk #2 FAILED at 745.
Hunk #3 FAILED at 756.
Hunk #4 FAILED at 1290.
4 out of 4 hunks FAILED 

Is there any advice to get the functionality working, so that ticket updates are sent to the email authors?

Thanks in advance!

subscribing ..

Was this bug never fixed? I have the same problem now in 7.x and it makes the module pretty useless when the customer who mails in the ticket never gets any notifications.

#21 how to so all active user in the assigned drop down list...Right now its showing admin only

is this going to be fixed? I am also having issues in this, I can't even subscribe the creator of the ticket...

Change to 7.x-1.x-dev due to the age of the old issues

We have the user being subscribed when the email gets fetched, but once a comment is applied the user isn't subscribed anymore

So the solution for me (or better: a workaround) was to give Authenticated User all 'Access tickets' permissions.

As our clients only communicate via e-mail, this is ok for us.

The only thing is that we should remember to grant a new permission for each new Support client added.

Thank you koosvdkolk your workaroud helped me too with Drupal 7.50.

Howerver I still have a problem with this module.
With this permission enabled, when a visitor opens a ticket he (the visitor) receives a notification.
When an operator submits the first response the visitor receives another email.
And this is good.
If the visitor replies to this email, the system captures and associates the message to the right thread.
But if an operator replies to the ticket for the second time, no emails arrive to the visitor.

So it seems that only the first response is redirected to the person that opened the ticket.

Has anybody had the same problem?

Thank you

cld

Updated version.

I'm running this on D7.67 with automatically being correctly assigned to the ticket, the user automatically being created, but NO notification emails going to the email creator of a ticket.

Update.

If I add 'Authenticated User' to the 'Access client_name Tickets' permission, notifications begin to arrive.

I'll test further to see that they continue to arrive.

I am unable to find Access client_name Tickets Do I need a patch I am at 7.x-1.0-rc2+0-dev. Notification to requester is very important