Unable to answer with mail

Infos:

  • Used Zammad version: 3.3.x
  • Used Zammad installation source: (source, package, …) package
  • Operating system: Ubuntu 18.4 LTS
  • Browser + version: Firefox 68.4

Hi there,

I have successfully migrated my ticket inventory from OTRS 6, configured Zammad, configured the mail and LDAP connection.
Unfortunately I can not reply to tickets by email. The necessary icons are missing.
What can be missing?

Steffen

1st you need to to configure your system email 2nd make sure all groups have configured email…

reply via email is you need to click the reply under the message/note of customer and click update to send

Thanks for the hint. I forgot to allow mail to the group. Now it works with new tickets. However, the mail tickets imported from OTRS still do not have this function. Is there a switch for this too?

i think sir @MrGeneration will help you on this
thank you

I guess you just need to reload your application because of evil caching.
If we’re talking about the exact group that is.

Ensure your group as an outgoing mail address set.

After ensuring you don’t have any caching striking you, it should work without any issues.

We do technically not handle imported tickets in a different way.

Thank you for your answer.
I emptied the browser cache, I used a completely new computer: the result remains unchanged. Imported tickets do not offer the possibility of mail replying:

New ticks but already:


Both tickets are in the same group.

Is there also a cache on the server? I have rebooted the server, the result is the same.

Is it possible that it is because two different mail addresses are used? The import tickets have the mail under it-support@… received, zamad now uses it-support2@… , because we are in the test phase and are not allowed to mix anything.

No no, the first screenshot is proberbly a note article.
Note articles do not provide information / possibilities to answer.

You can check that by clicking on the articles content.
On the bottom you’ll see the type of the article e.g. “phone”.

Yes, the tickets imported from OTRS are all entered as “note”. Did the import fail there? Can this be corrected?

You could update all of the existing articles that are notes to phone articles.
But that’s very sketchy and might lead to other issues I can’t forecast at this moment.

In my opinion Zammad would and should use the actual article types - so my guess is that the articles are already “notes” within OTRS. However, @thorsteneckel might correct me on this if he finds spare time.

Hey @Steffen :wave: What kind of article were they in OTRS? The Zammad OTRS import maps the OTRS ArticleTypes to Zammad. In case an ArticleType can’t be mapped it falls back to an internal Note – for security reasons. Do you have custom ArticleTypes in your OTRS setup our import can’t handle?

I have only the type “default”, no other. Can I map “default” to “mail” in zammad?

I’m confused. There is no such ArticleType called default in a vanilla OTRS installation. Have you changed that? Just double checking before I can provide a matching answer.

We have not changed the type, it is the default since the installation of OTRS 3.x.
We have not activated the ticket types:


So we have only one type:

Is it possilbe to change the source code of the OTRS import module for this import?

Ah! I see. This is the Type but not the ArticleType. I’ll have a look tomorrow to find the root cause of this.

Hey @Steffen - we need to run some SQL statements on your OTRS and Zammad database tables to see where things diverge. This will give us more insights on finding the root cause.

First of all we need the ID of an Article that differs from OTRS to Zammad. You can find that out by using the Chrome/Firefox developer tools (right click inspect) on the Article. You’ll find something that looks like this:

Take this ID (e.g. 141712) and replace the *ARTICLE_ID* in the following statements with it.

Please provide the results of the statements:

OTRS

SELECT * FROM article_type;
SELECT article_type_id FROM article WHERE id = *ARTICLE_ID*;

Zammad

SELECT * FROM ticket_article_types;
SELECT * FROM ticket_article_senders;
SELECT type_id, sender_id FROM ticket_articles WHERE id = *ARTICLE_ID*;

Looking forward to read your response.

1 Like

Hallo Thorsten,

here are the outputs from the queries:

MariaDB [otrs]> SELECT * FROM article_type;
ERROR 1146 (42S02): Table ‘otrs.article_type’ doesn’t exist
MariaDB [otrs]> SELECT article_type_id FROM article WHERE id = 31194;
ERROR 1054 (42S22): Unknown column ‘article_type_id’ in ‘field list’
MariaDB [otrs]>
MariaDB [otrs]> show fields from article;
±---------------------------±------------±-----±----±--------±---------------+
| Field | Type | Null | Key | Default | Extra |
±---------------------------±------------±-----±----±--------±---------------+
| id | bigint(20) | NO | PRI | NULL | auto_increment |
| ticket_id | bigint(20) | NO | MUL | NULL | |
| article_sender_type_id | smallint(6) | NO | MUL | NULL | |
| communication_channel_id | bigint(20) | NO | MUL | NULL | |
| is_visible_for_customer | smallint(6) | NO | | NULL | |
| search_index_needs_rebuild | smallint(6) | NO | MUL | 1 | |
| insert_fingerprint | varchar(64) | YES | | NULL | |
| create_time | datetime | NO | | NULL | |
| create_by | int(11) | NO | MUL | NULL | |
| change_time | datetime | NO | | NULL | |
| change_by | int(11) | NO | MUL | NULL | |
±---------------------------±------------±-----±----±--------±---------------+
11 rows in set (0.02 sec)

MariaDB [otrs]>

zammad=>
zammad=> SELECT * FROM ticket_article_types;
id | name | note | communication | active | updated_by_id | created_by_id | created_at | updated_at
----±--------------------------±-----±--------------±-------±--------------±--------------±------------------------±------------------------
1 | email | | t | t | 1 | 1 | 2020-01-02 18:09:55.819 | 2020-01-02 18:09:55.819
2 | sms | | t | t | 1 | 1 | 2020-01-02 18:09:55.824 | 2020-01-02 18:09:55.824
3 | chat | | t | t | 1 | 1 | 2020-01-02 18:09:55.829 | 2020-01-02 18:09:55.829
4 | fax | | t | t | 1 | 1 | 2020-01-02 18:09:55.841 | 2020-01-02 18:09:55.841
5 | phone | | t | t | 1 | 1 | 2020-01-02 18:09:55.846 | 2020-01-02 18:09:55.846
6 | twitter status | | t | t | 1 | 1 | 2020-01-02 18:09:55.86 | 2020-01-02 18:09:55.86
7 | twitter direct-message | | t | t | 1 | 1 | 2020-01-02 18:09:55.865 | 2020-01-02 18:09:55.865
8 | facebook feed post | | t | t | 1 | 1 | 2020-01-02 18:09:55.878 | 2020-01-02 18:09:55.878
9 | facebook feed comment | | t | t | 1 | 1 | 2020-01-02 18:09:55.883 | 2020-01-02 18:09:55.883
10 | note | | f | t | 1 | 1 | 2020-01-02 18:09:55.889 | 2020-01-02 18:09:55.889
11 | web | | t | t | 1 | 1 | 2020-01-02 18:09:55.902 | 2020-01-02 18:09:55.902
12 | telegram personal-message | | t | t | 1 | 1 | 2020-01-02 18:09:55.907 | 2020-01-02 18:09:55.907
(12 rows)

zammad=> SELECT * FROM ticket_article_senders;
id | name | note | updated_by_id | created_by_id | created_at | updated_at
----±---------±-----±--------------±--------------±------------------------±------------------------
1 | Agent | | 1 | 1 | 2020-01-02 18:09:55.924 | 2020-01-02 18:09:55.924
2 | Customer | | 1 | 1 | 2020-01-02 18:09:55.93 | 2020-01-02 18:09:55.93
3 | System | | 1 | 1 | 2020-01-02 18:09:55.934 | 2020-01-02 18:09:55.934
(3 rows)

zammad=> SELECT type_id, sender_id FROM ticket_articles WHERE id = 31194;
type_id | sender_id
---------±----------
10 | 2
(1 row)

zammad=>

As you can see: we have no article types in OTRS.

Hi @Steffen - I looked at the source code of the wrong OTRS version. Could you please run the following SQL queries on your OTRS DB:

SELECT * FROM article_sender_type;
SELECT is_visible_for_customer, is_visible_for_customer FROM article WHERE id = *ARTICLE_ID*;

Thanks!

Here we are:

MariaDB [otrs]> SELECT * FROM article_sender_type;
±—±---------±---------±---------±--------------------±----------±--------------------±----------+
| id | name | comments | valid_id | create_time | create_by | change_time | change_by |
±—±---------±---------±---------±--------------------±----------±--------------------±----------+
| 1 | agent | NULL | 1 | 2011-05-31 09:29:27 | 1 | 2011-05-31 09:29:27 | 1 |
| 2 | system | NULL | 1 | 2011-05-31 09:29:27 | 1 | 2011-05-31 09:29:27 | 1 |
| 3 | customer | NULL | 1 | 2011-05-31 09:29:27 | 1 | 2011-05-31 09:29:27 | 1 |
±—±---------±---------±---------±--------------------±----------±--------------------±----------+
3 rows in set (0.01 sec)

MariaDB [otrs]> SELECT is_visible_for_customer, is_visible_for_customer FROM article WHERE id = 31194;
±------------------------±------------------------+
| is_visible_for_customer | is_visible_for_customer |
±------------------------±------------------------+
| 1 | 1 |
±------------------------±------------------------+
1 row in set (0.00 sec)

Well… I have good and bad news: The good news is that I found the cause for the error thanks to your provided data. The bad news is that this is a bug in the export Package Znuny4OTRS-ZammadMigrator. OTRS 6 introduced a change in the table structure of articles. That’s why I send you the wrong SQL statements first. However, these changes are not completely reflected in the export functionality of Znuny4OTRS-ZammadMigrator. Therefore Zammad can’t find the right ArticleType and falls back to an internal note :frowning:
@MrGeneration can you please create in issue for this?
@Steffen I can’t give you an estimation on how long this will take us to fix it. I’ll give you a heads up over the next days. Thanks for reporting it!