Zammad: Ein zu großer Artikelkörper schlägt beim OTRS-Import fehl

Hallo @MrDigit , welche DB soll

/opt/zammad/app/models/ticket/article.rb:301:in check_body': body if article is to large, 3702347 chars - only 1500000 allowed (Exceptions::UnprocessableEntity) from /usr/local/bundle/gems/activesupport-5.1.5/lib/active_support/callbacks.rb:413:inblock in make_lambda'

Hallo @NeverMin ,

Da das Limit in article.rb fest codiert ist, ist dieser Fehler unabhängig vom ausgewählten DB-Backend.
( Limit = 1_500_000 , siehe unten)

def check_body
    return true if body.blank?
    limit = 1_500_000
    current_length = body.length
    return true if body.length <= limit

    raise Exceptions::UnprocessableEntity, "body if article is to large, #{current_length} chars - only #{limit} allowed" if !ApplicationHandleInfo.postmaster?

    logger.warn "WARNING: cut string because of database length #{self.class}.body(#{limit} but is #{current_length})"
    self.body = body[0, limit]
end

Hallo @MrDigit , Ja, Sie können das Problem beheben (z. B. 4_000_000) und versuchen, aber welche Datenbank soll für Zammad verwendet werden? MySQL oder postgresql? Was ist die OTRS-Version?

Hallo @NeverMin ,

bereits die Grenze auf einen höheren Wert angehoben, funktionierte der Import danach. Die Frage ist, warum das Limit auf 1,5 MByte festgelegt ist. Weil zammad explodiert, wenn größere Körper gespeichert werden, oder ist dies einfach ein beliebiger Wert?

Zu Ihren Fragen: Die Docker-Compose-Version von zammad, die ich verwende (https://github.com/zammad/zammad-docker-compose), verwendet postgresql. Ich speichere die Anhänge im Dateisystem. OTRS ist Version 5.

Hallo @MrDigit , gute Fragen, vielleicht lass mich @thorsteneckel fragen.

JFI: https://github.com/zammad/zammad/blob/develop/db/migrate/20120101000010_create_ticket.rb#L175

EDITIERT:
Können Sie dieses Problem in die Community verschieben ?

Hallo @ MrDigit

Die Frage ist, warum das Limit auf 1,5 MByte festgelegt ist.

Ich denke, dieser Wert ist von früher und wahrscheinlich veraltet. Vielen Dank, dass Sie so tief gegraben, Ihr Problem gelöst und hier geteilt haben. Wir werden uns dieses Problem genauer ansehen.

Dies ist nicht nur auf den OTRS-Import beschränkt.
Dies wird an mehreren Stellen zuschlagen.

Wenn ich versuche, dies zu reproduzieren, erhalte ich auch mit 15000 Zeichen weiterhin Fehler (Hinweis: Ich musste hier zur API wechseln, weil es unserer Benutzeroberfläche nicht gefallen hat):

F, [2019-07-03T16:36:15.330582 #18433-86302140] FATAL -- :
F, [2019-07-03T16:36:15.330620 #18433-86302140] FATAL -- : actionpack (5.1.7) lib/action_dispatch/http/parameters.rb:115:in `rescue in parse_formatted_parameters'
actionpack (5.1.7) lib/action_dispatch/http/parameters.rb:109:in `parse_formatted_parameters'
actionpack (5.1.7) lib/action_dispatch/http/request.rb:361:in `block in POST'
rack (2.0.7) lib/rack/request.rb:59:in `fetch'
rack (2.0.7) lib/rack/request.rb:59:in `fetch_header'
actionpack (5.1.7) lib/action_dispatch/http/request.rb:360:in `POST'
actionpack (5.1.7) lib/action_dispatch/http/parameters.rb:53:in `parameters'
actionpack (5.1.7) lib/action_dispatch/http/filter_parameters.rb:41:in `filtered_parameters'
actionpack (5.1.7) lib/action_controller/metal/instrumentation.rb:21:in `process_action'
actionpack (5.1.7) lib/action_controller/metal/params_wrapper.rb:252:in `process_action'
activerecord (5.1.7) lib/active_record/railties/controller_runtime.rb:22:in `process_action'
actionpack (5.1.7) lib/abstract_controller/base.rb:124:in `process'
actionview (5.1.7) lib/action_view/rendering.rb:30:in `process'
actionpack (5.1.7) lib/action_controller/metal.rb:189:in `dispatch'
actionpack (5.1.7) lib/action_controller/metal.rb:253:in `dispatch'
actionpack (5.1.7) lib/action_dispatch/routing/route_set.rb:49:in `dispatch'
actionpack (5.1.7) lib/action_dispatch/routing/route_set.rb:31:in `serve'
actionpack (5.1.7) lib/action_dispatch/journey/router.rb:50:in `block in serve'
actionpack (5.1.7) lib/action_dispatch/journey/router.rb:33:in `each'
actionpack (5.1.7) lib/action_dispatch/journey/router.rb:33:in `serve'
actionpack (5.1.7) lib/action_dispatch/routing/route_set.rb:844:in `call'
omniauth (1.9.0) lib/omniauth/strategy.rb:192:in `call!'
omniauth (1.9.0) lib/omniauth/strategy.rb:169:in `call'
omniauth (1.9.0) lib/omniauth/strategy.rb:192:in `call!'
omniauth (1.9.0) lib/omniauth/strategy.rb:169:in `call'
omniauth (1.9.0) lib/omniauth/strategy.rb:192:in `call!'
omniauth (1.9.0) lib/omniauth/strategy.rb:169:in `call'
omniauth (1.9.0) lib/omniauth/strategy.rb:192:in `call!'
omniauth (1.9.0) lib/omniauth/strategy.rb:169:in `call'
omniauth (1.9.0) lib/omniauth/strategy.rb:192:in `call!'
omniauth (1.9.0) lib/omniauth/strategy.rb:169:in `call'
omniauth (1.9.0) lib/omniauth/strategy.rb:192:in `call!'
omniauth (1.9.0) lib/omniauth/strategy.rb:169:in `call'
omniauth (1.9.0) lib/omniauth/strategy.rb:192:in `call!'
omniauth (1.9.0) lib/omniauth/strategy.rb:169:in `call'
omniauth (1.9.0) lib/omniauth/strategy.rb:192:in `call!'
omniauth (1.9.0) lib/omniauth/strategy.rb:169:in `call'
omniauth (1.9.0) lib/omniauth/strategy.rb:192:in `call!'
omniauth (1.9.0) lib/omniauth/strategy.rb:169:in `call'
omniauth (1.9.0) lib/omniauth/builder.rb:64:in `call'
rack (2.0.7) lib/rack/etag.rb:25:in `call'
rack (2.0.7) lib/rack/conditional_get.rb:38:in `call'
rack (2.0.7) lib/rack/head.rb:12:in `call'
rack (2.0.7) lib/rack/session/abstract/id.rb:232:in `context'
rack (2.0.7) lib/rack/session/abstract/id.rb:226:in `call'
actionpack (5.1.7) lib/action_dispatch/middleware/cookies.rb:613:in `call'
actionpack (5.1.7) lib/action_dispatch/middleware/callbacks.rb:26:in `block in call'
activesupport (5.1.7) lib/active_support/callbacks.rb:97:in `run_callbacks'
actionpack (5.1.7) lib/action_dispatch/middleware/callbacks.rb:24:in `call'
actionpack (5.1.7) lib/action_dispatch/middleware/debug_exceptions.rb:59:in `call'
actionpack (5.1.7) lib/action_dispatch/middleware/show_exceptions.rb:31:in `call'
railties (5.1.7) lib/rails/rack/logger.rb:36:in `call_app'
railties (5.1.7) lib/rails/rack/logger.rb:24:in `block in call'
activesupport (5.1.7) lib/active_support/tagged_logging.rb:69:in `block in tagged'
activesupport (5.1.7) lib/active_support/tagged_logging.rb:26:in `tagged'
activesupport (5.1.7) lib/active_support/tagged_logging.rb:69:in `tagged'
railties (5.1.7) lib/rails/rack/logger.rb:24:in `call'
actionpack (5.1.7) lib/action_dispatch/middleware/remote_ip.rb:79:in `call'
actionpack (5.1.7) lib/action_dispatch/middleware/request_id.rb:25:in `call'
rack (2.0.7) lib/rack/method_override.rb:22:in `call'
rack (2.0.7) lib/rack/runtime.rb:22:in `call'
activesupport (5.1.7) lib/active_support/cache/strategy/local_cache_middleware.rb:27:in `call'
actionpack (5.1.7) lib/action_dispatch/middleware/executor.rb:12:in `call'
actionpack (5.1.7) lib/action_dispatch/middleware/static.rb:125:in `call'
rack (2.0.7) lib/rack/sendfile.rb:111:in `call'
railties (5.1.7) lib/rails/engine.rb:522:in `call'
railties (5.1.7) lib/rails/railtie.rb:185:in `public_send'
railties (5.1.7) lib/rails/railtie.rb:185:in `method_missing'
puma (3.12.1) lib/puma/configuration.rb:227:in `call'
puma (3.12.1) lib/puma/server.rb:660:in `handle_request'
puma (3.12.1) lib/puma/server.rb:474:in `process_client'
puma (3.12.1) lib/puma/server.rb:334:in `block in run'
puma (3.12.1) lib/puma/thread_pool.rb:135:in `block in spawn_thread'
logging (2.2.2) lib/logging/diagnostic_context.rb:474:in `block in create_with_logging_context'

Die API-Antwort ist leer.

Ich konnte die API zu keinem Zeitpunkt an die oben genannte Grenze bringen, da Zammad meine Nutzdaten nicht übernehmen würde.

Ich habe es mit 1500001 Zeichen versucht (was meinem Browser bereits nicht so gut gefallen hat) und danach mit weniger 15000 Zeichen (dieser Wert kann in Zammad eingefügt werden). Aber wenn der Artikel zu groß wird, hört er einfach auf, die Pasten zu nehmen.

1500001 jedoch nicht 1,5 MB groß, sondern ungefähr 1,14 MB, was nicht einmal das Limit ist. Ich könnte ungefähr 494320 Zeichen einfügen (Klartext!), Danach funktioniert die manuelle Eingabe immer noch. Größerer Dank war nicht erfolgreich.

Ich habe diesen Generator während meiner Versuche verwendet: https://www.loremipsum.de/index_e.html

Hallo,
Ich beschuldigte das Limit und dieses Problem ist der Grund für das Limit:
https://github.com/zammad/zammad/issues/1390

Von meiner Seite sind 1,5 MB in Ordnung ... Normalerweise werden größere Inhalte sowieso in Anhängen behandelt, wo sie kein Problem darstellen.

Ich bin auf das gleiche Problem gestoßen. Ein Kunde hatte einen fehlgeschlagenen otrs-Artikelimport mit einem eingebetteten Dokument, das den Artikel beschädigte (1 von 35.000 Tickets). Kein verwendbarer Inhalt, es sah so aus, als hätte der Mailserver / Client ihn während der Zustellung beschädigt.

Ich werde die Ausnahme so ändern, dass sie beim Import nicht auftritt. Daher werden die Artikel importiert, indem sie wie in anderen Fällen auf 1,5 MB gekürzt werden. Wir sollten auch das Limit von 1,14 MB -> 1,5 MB festlegen. Der Import sollte reibungslos verlaufen und Ausnahmen verhindern.

Wir haben beschlossen, das Limit von 1,5 Millionen Zeichen pro Artikel beizubehalten. Wie @MrGeneration hervorhob , kann die Benutzeroberfläche nach (einer viel geringeren) Anzahl von Zeichen ohnehin nicht verwendet werden. Es ging nie um die tatsächliche Größe in MB / KB, sondern um die Anzahl der Zeichen. Das ursprüngliche Problem ist jedoch behoben und kann mit Zammad 3.5 use verwendet werden