Zammad: Un corps d'article trop volumineux échoue à l'importation OTRS

Salut @MrDigit , Quelle base de données utiliser? Je pense que limité à partir de DB, voir cette ligne dans le journal:

/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'

Bonjour @NeverMin ,

comme la limite est codée en dur dans article.rb, cette erreur est indépendante du backend DB sélectionné.
( limite = 1_500_000 , voir ci-dessous)

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

Bonjour @MrDigit , Oui, vous pouvez corriger (par exemple 4_000_000) et essayer, mais quelle base de données utiliser pour Zammad? MySQL ou postgresql? Qu'est-ce que la version OTRS?

Bonjour @NeverMin ,

déjà élevé la limite à une valeur plus élevée, l'importation a fonctionné par la suite. La question est pourquoi la limite est-elle fixée à 1,5 Mo? Parce que zammad explosera si des corps plus grands sont stockés ou est-ce simplement une valeur arbitraire?

Concernant vos questions: La version docker-compose de zammad que j'utilise (https://github.com/zammad/zammad-docker-compose) utilise postgresql, je stocke les pièces jointes dans le système de fichiers. OTRS est la version 5.

Bonjour @MrDigit , Bonnes questions, laissez-moi peut-être demander à @thorsteneckel .

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

ÉDITÉ:
Pouvez-vous déplacer ce problème vers Communauté ?

Salut @MrDigit

La question est pourquoi la limite est-elle fixée à 1,5 Mo?

Je pense que cette valeur est d'autrefois et probablement obsolète. Merci de creuser cette profondeur, de résoudre votre problème et de le partager ici. Nous examinerons de plus près cette question.

Cela ne se limite pas à l'importation OTRS uniquement.
Cela frappera à plusieurs points.

En essayant de reproduire cela, même avec 15000 caractères, je continuerai à recevoir des erreurs (note: j'ai dû passer à l'API ici car notre interface utilisateur ne l'aimait pas):

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'

La réponse de l'API est vide.

Je ne pourrais à aucun moment pousser l'API à la limite ci-dessus, car Zammad ne prendrait pas mes charges utiles.

J'ai essayé avec des caractères 1500001 (que mon navigateur n'aimait déjà pas trop) et ensuite avec moins de 15000 chracters (cette valeur peut être collée dans Zammad). Mais encore une fois, si l'article devient trop gros, il arrêtera simplement de prendre les pâtes.

Cependant, 1500001 n'est pas 1,5 Mo, mais plutôt environ 1,14 Mo, ce qui n'est même pas la limite. Je pourrais coller environ 494320 caractères (texte brut!), Après quoi la saisie manuelle fonctionne toujours. Un grand merci là où il n'a pas réussi.

J'ai utilisé ce générateur lors de mes essais: https://www.loremipsum.de/index_e.html

Salut,
J'ai blâmé la limite et ce problème est la raison de la limite:
https://github.com/zammad/zammad/issues/1390

De mon côté, 1,5 Mo, c'est bien ... Normalement, les plus gros contenus sont traités dans les pièces jointes de toute façon là où ils ne posent aucun problème.

J'ai rencontré le même problème. Un client a eu un échec de l'importation d'article d'otrs avec un docx intégré qui a cassé l'article (1 des 35k tickets). Aucun contenu utilisable, on aurait dit que le serveur de messagerie / client l'avait cassé lors de la livraison.

Je changerai l'exception pour qu'elle ne se produise pas sur les importations, donc les articles seront importés en le coupant à 1,5 Mo comme dans d'autres cas. Nous devrions également fixer la limite de 1,14 Mo -> 1,5 Mo. L'importation doit se dérouler sans heurts et empêcher le déclenchement d'exceptions.

Nous avons décidé de conserver la limite de 1,5 million de caractères par article. Comme @MrGeneration l'a souligné, l'interface utilisateur n'est de toute façon pas utilisable après une quantité (beaucoup plus faible) de caractères. Il n'a jamais été question de la taille réelle en termes de Mo / Ko mais du nombre de caractères. Cependant, le problème d'origine est maintenant résolu et sera prêt à être utilisé avec Zammad 3.5 🚀