Zammad: El cuerpo del artículo demasiado grande falla en la importación de OTRS

Hola @MrDigit , ¿Cuál DB usar? Creo que limitado desde DB, vea esta línea en el registro:

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

Hola @NeverMin ,

como el límite está codificado en article.rb, este error es independiente del backend de base de datos seleccionado.
( límite = 1_500_000 , ver más abajo)

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

Hola @MrDigit , Sí, puede arreglar (por ejemplo, 4_000_000) e intentarlo, pero, ¿cuál DB usar para Zammad? ¿MySQL o postgresql? ¿Qué es la versión OTRS?

Hola @NeverMin ,

Ya elevó el límite a un valor más alto, la importación funcionó después. La pregunta es ¿por qué el límite está establecido en 1,5 MByte? ¿Porque zammad explotará si se almacenan cuerpos más grandes o es simplemente un valor arbitrario?

Con respecto a sus preguntas: La versión docker-compose de zammad que estoy usando (https://github.com/zammad/zammad-docker-compose) está usando postgresql, estoy almacenando los archivos adjuntos en el sistema de archivos. OTRS es la versión 5.

Hola @MrDigit , Buenas preguntas, tal vez déjame preguntarle a @thorsteneckel .

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

EDITADO:
¿Puedes mover este problema a la comunidad ?

Hola @MrDigit

La pregunta es ¿por qué el límite está establecido en 1,5 MByte?

Creo que este valor es de antaño y probablemente obsoleto. Gracias por investigar tanto, resolver su problema y compartirlo aquí. Veremos más de cerca cuando abordemos este problema.

Esto no se limita a la importación OTRS únicamente.
Esto afectará en varios puntos.

Al intentar reproducir esto, incluso con 15000 caracteres, seguiré recibiendo errores (nota: tuve que cambiar a API aquí porque a nuestra interfaz de usuario no le gustó):

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 respuesta de la API está vacía.

En ningún momento podría llevar la API al límite anterior, ya que Zammad no tomaría mis cargas útiles.

Probé con 1500001 caracteres (que a mi navegador ya no le gustó demasiado) y después con menos 15000 caracteres (este valor se puede utilizar dentro de Zammad). Pero nuevamente, si el artículo se vuelve demasiado grande, simplemente dejará de tomar las pastas.

1500001 sin embargo no es 1,5 MB, sino alrededor de 1,14 MB, que ni siquiera es el límite. Podría pegar alrededor de 494320 caracteres (¡texto sin formato!), Luego la escritura manual todavía funciona. Más agradecimiento donde no tuvo éxito.

Usé este generador durante mis intentos: https://www.loremipsum.de/index_e.html

Hola,
culpé al límite y este problema es la razón del límite:
https://github.com/zammad/zammad/issues/1390

Por mi parte, 1,5 MB está bien ... Normalmente, los contenidos más grandes se manejan en archivos adjuntos de todos modos donde no son un problema.

Me encontré con el mismo problema. Un cliente tuvo una importación de artículo de otrs fallida con un docx incrustado que rompió el artículo (1 de 35k tickets). No hay contenido utilizable, parecía que el servidor de correo / cliente lo rompió durante la entrega.

Cambiaré la excepción para que no ocurra en las importaciones, por lo que los artículos se importarán cortándola a 1,5 MB como en otros casos. También deberíamos fijar el límite de 1,14 MB a 1,5 MB. La importación debería realizarse sin problemas y evitar generar excepciones.

Decidimos mantener el límite de 1,5 millones de caracteres por artículo. Como señaló @MrGeneration , la interfaz de usuario no se puede usar después de una cantidad (mucho menor) de caracteres de todos modos. Nunca se trató del tamaño real en términos de MB / KB, sino del número de caracteres. Sin embargo, el problema original ahora está solucionado y estará listo para usar con Zammad 3.5 🚀