Bug with last contact for one specific user

Infos:

  • Used Zammad version: 3.1.x
  • Used Zammad installation source: apt-get
  • Operating system: Ubuntu Linux 16.04.6
  • Browser + version: Firefox 69.0.1 (64-Bit)

Explanation

On a ticket are 3 attributes for last contact:

  • last_contact_at
  • last_contact_agent_at
  • last_contact_customer_at

Expected behavior:

If the ticket is updated by someone I expect Zammad to up Update this attributes.

Actual behavior:

I have one specific agent with ID 19 where nothing happens.
The attribute “last_contact_agent_at” is always set to null when the user writes something to the ticket.
This happens only for this agent, for every one else it is working.



Does someone know a solution?
I am very grateful for any help :relaxed:

Here is the api response of user 19 and 20 for comparison:

User 19: {“id”:19,“organization_id”:4,“login”:“private”,“firstname”:“private”,“lastname”:“private”,“email”:“private”,“image”:“e5e854ac6d82ce6a5800e3b215ff441f”,“image_source”:null,“web”:"",“phone”:"",“fax”:"",“mobile”:“private”,“department”:"",“street”:"",“zip”:"",“city”:"",“country”:"",“address”:"",“vip”:false,“verified”:false,“active”:true,“note”:"",“last_login”:“2019-10-18T09:47:10.894Z”,“source”:null,“login_failed”:0,“out_of_office”:false,“out_of_office_start_at”:null,“out_of_office_end_at”:null,“out_of_office_replacement_id”:null,“preferences”:{“notification_config”:{“matrix”:{“create”:{“criteria”:{“owned_by_me”:true},“channel”:{“email”:true,“online”:true}},“update”:{“criteria”:{“owned_by_me”:true},“channel”:{“email”:true,“online”:true}},“reminder_reached”:{“criteria”:{},“channel”:{“email”:false,“online”:true}},“escalation”:{“criteria”:{},“channel”:{“email”:false,“online”:true}}},“group_ids”:[“1”]},“locale”:“de-de”,“intro”:true,“tickets_closed”:1,“tickets_open”:1,“notification_sound”:{“file”:“Xylo.mp3”,“enabled”:true}},“updated_by_id”:1,“created_by_id”:14,“created_at”:“2019-03-25T11:16:15.833Z”,“updated_at”:“2019-10-18T13:05:17.309Z”,“sappersonnelnumber”:“1”,“role_ids”:[2],“organization_ids”:[],“authorization_ids”:[],“group_ids”:{“1”:[“full”]}}

User 20:
{“id”:20,“organization_id”:4,“login”:“private”,“firstname”:“private”,“lastname”:“private”,“email”:“private”,“image”:“7416c293c3ed929d6170a564e7f79920”,“image_source”:null,“web”:"",“phone”:"",“fax”:"",“mobile”:“private”,“department”:"",“street”:"",“zip”:"",“city”:"",“country”:"",“address”:"",“vip”:false,“verified”:false,“active”:true,“note”:"",“last_login”:“2019-10-16T12:01:58.433Z”,“source”:null,“login_failed”:0,“out_of_office”:false,“out_of_office_start_at”:null,“out_of_office_end_at”:null,“out_of_office_replacement_id”:null,“preferences”:{“locale”:“de-de”,“notification_config”:{“matrix”:{“create”:{“criteria”:{“owned_by_me”:true},“channel”:{“email”:true,“online”:true}},“update”:{“criteria”:{“owned_by_me”:true},“channel”:{“email”:true,“online”:true}},“reminder_reached”:{“criteria”:{“owned_by_me”:true},“channel”:{“email”:true,“online”:true}},“escalation”:{“criteria”:{“owned_by_me”:true},“channel”:{“email”:true,“online”:true}}},“group_ids”:[“1”]},“intro”:true,“notification_sound”:{“file”:“Xylo.mp3”,“enabled”:true}},“updated_by_id”:1,“created_by_id”:14,“created_at”:“2019-03-25T11:20:04.702Z”,“updated_at”:“2019-10-18T13:05:49.113Z”,“sappersonnelnumber”:“24”,“role_ids”:[2],“organization_ids”:[],“authorization_ids”:[],“group_ids”:{“1”:[“full”]}}

Json Viewer: https://jsonformatter.org/json-viewer

Steps to reproduce the behavior:

It happens always for this user and just for this user.

Please provide your logfile during the time you’re reproducing this.
Also, please provide the affected agents permissions (assigned roles and the settings of the roles assigned), just to be sure.

While you’re at it, please also ensure you don’t have any Triggers, Schedulers or API scripts that do this.
You could also try another browser and / or PC to ensure this is not a local issue that could be caused by browser or addon.

A History-Screenshot of an affected ticket might help as well.

Hi Marcel,

I checked the log files, did some additional testing and found the reason.
To answer a Ticket we are writing public comments and there is a trigger which is sending mails like you described it in this comment: Answer via mail per default

It looks like Zammad does not count public notes as a interaction with the customer.
Which fells quite wrong to me. Zammad should always update this variables on public comments.
Is it possible to fix this?

Right now I would prefer to use mails as the default channel. This there any way to set this up?

I see. That’s default behavior from Zammad and, as far as I’m aware, not going to change in the future.
However, the following pull request for extension of our documentation gives hints on how to change the way Zammad handles public notes.

Please note:
This documentation part currently is undergoing QA and thus might have wrong or misleading texts.
Also, this does affect your SLA calculation, if the note if public. This change is update safe.

Yes and no.
At this very moment you can’t tell Zammad to always have a default article type to answer. Personally I don’t think it’s too good of an idea, because especially in E-Mail-Context this will lead to issues (e.g. do we prefill the to field and if yes with what mail address (as it might be possible that we communicate with more than one person in a ticket)).

I suggest using the “Reply”-Button below the article you’re answering on, that will create an mail article automatically and should do the trick.

Now for ticket creation, you actually can enforce a default article type for the ticket creation. This enforces e.g. a outgoing mail on the first article (only). See: https://docs.zammad.org/en/latest/console/hidden-settings.html#default-ticket-type-on-creation

1 Like

This looks perfect to me :heart_eyes::grinning:

But for some reason it is not working.
I did the following:

But the variable is still not updated:
2019-10-22_11h27_27
2019-10-22_11h27_50

I also rebooted the server.

Is there something else I need to do? :slight_smile:

Thank you very much, for your help (:

Beautiful fix. I can confirm that

Ticket::Article::Type.find_by(name:‘note’).update!(communication: true)

worked and updated the necessary Ticket metadata including the state from new to open.

image

1 Like

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.