New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Too large article body fails OTRS import #2107
Comments
Hi @MrDigit , Which one DB to use? I think limited from DB, see this line in log:
|
Hello @NeverMin , as the limit is hardcoded into article.rb this error independent of the selected DB backend.
|
Hello @MrDigit , Yes, you can fix(e.g. 4_000_000) and try, but, which one DB to use for Zammad ? MySQL or postgresql? What is OTRS version? |
Hello @NeverMin , already raised the limit to some higher value, import worked afterwards. Question is why is the limit set to 1,5 MByte ? Because zammad will explode if larger bodies are stored or is this simply a arbitrary value ? Regarding your questions: The docker-compose version of zammad I am using ( https://github.com/zammad/zammad-docker-compose ) is using postgresql, I am storing the attachments in the filesystem. OTRS is version 5. |
Hello @MrDigit , Good questions, maybe let me ask to @thorsteneckel . JFI: https://github.com/zammad/zammad/blob/develop/db/migrate/20120101000010_create_ticket.rb#L175 EDITED: |
Hi @MrDigit
I think this value is of yore and probably obsolete. Thanks for digging that deep, resolving your issue and sharing it here. We will have a closer look when addressing this issue. |
This is not limited to OTRS import only. When trying to reproduce this, even with 15000 characters, I'll keep receiving errors (note: I had to switch to API here because our UI didn't like it):
API response is empty. I could, at no point, push the API to the above limit, as Zammad wouldn't take my payloads. I tried with
I used this generator during my tries: https://www.loremipsum.de/index_e.html |
Hi, From my side 1.5 MB is okay... Normally bigger contents are handled in attachments anyways where they are no problem. I ran into the same issue. A customer had a failed otrs article import with a embedded docx which broke the article (1 of 35k tickets). No usable content, looked like the mailserver/client broke it while delivering. I will change the exception to not occure on imports, so the articles will be imported by cutting it to 1.5 MB like in other cases. We also should fix the limit from 1.14MB -> 1.5MB. The import should run smooth and prevent raising exceptions. |
We decided to keep the limit of 1.5 million chars per article. As @MrGeneration pointed out the UI isn't usable after (a much lower) amount of chars anyway. It was never about the actual size in terms of MB/KB but the number of chars. However, the original issue is now fixed and will be ready to use with Zammad 3.5 🚀 |
Hello,
in addition to #1467 I still not give up importing OTRS data.
(I think the older ticket can be closed)
Task:
With zammad 2.5 tried to import OTRS data (~6000 tickets.
Result:
Try 1:
Import via WebGUI was not successful, import process stopped after some time. Is it possible that there is something like a timeout ?
Try 2:
Import via console was better, but import failed at a ticket with a huge body (I assume this is an attachemend) with the following error (please see exception below). Executed the following commands:
Questions:
Best regards
MrDigit
Trace fo exception:
The text was updated successfully, but these errors were encountered: