thuc960,
lo que hice fue cambiar esta llamada de retorno en el archivo class.export.php , sobre la línea 85 dentro de la función de función dumpTickets ($ sql, $ how = 'csv') :

_return self :: dumpQuery ($ tickets,
formación(
'número' => __ ('Número de ticket'),
'created' => ('Fecha de creación'),'cdata.subject' => __ ('Asunto'),'user.name' => __ ('Desde'),'user.default_email.address' => __ ('De correo electrónico'),'cdata.:priority.priority_desc' => __ ('Prioridad'),'dept :: getLocalName' => __ ('Departamento'),'topic :: getName' => __ ('Tema de ayuda'),'fuente' => __ ('Fuente'),'status :: getName' => ('Estado actual'),
'lastupdate' => __ ('Última actualización'),
'est_duedate' => __ ('Fecha de vencimiento'),
'isoverdue' => __ ('Atrasado'),
'isanswered' => __ ('Respondido'),
'staff :: getName' => __ ('Agente asignado'),
'team :: getName' => __ ('Equipo asignado'),
'thread_count' => __ ('Número de subprocesos'),
'attach_count' => __ ('Recuento de adjuntos'),
) + $ cdata,
$ cómo,
array ('modificar' => función (& $ registro, $ claves) use ($ campos) {
foreach ($ campos como $ k => $ f) {
if (($ i = array_search ($ k, $ claves))! == falso) {
$ registro [$ i] = $ f-> exportar ($ f-> to_php ($ registro [$ i]));
}
}
echo $ record
return $ record;
})
); _

Con esto (elimine el último parámetro, después de $ cómo,):

_return self :: dumpQuery ($ tickets,
formación(
'número' => __ ('Número de ticket'),
'created' => ('Fecha de creación'),'cdata.subject' => __ ('Asunto'),'user.name' => __ ('Desde'),'user.default_email.address' => __ ('De correo electrónico'),'cdata.:priority.priority_desc' => __ ('Prioridad'),'dept :: getLocalName' => __ ('Departamento'),'topic :: getName' => __ ('Tema de ayuda'),'fuente' => __ ('Fuente'),'status :: getName' => ('Estado actual'),
'lastupdate' => __ ('Última actualización'),
'est_duedate' => __ ('Fecha de vencimiento'),
'isoverdue' => __ ('Atrasado'),
'isanswered' => __ ('Respondido'),
'staff :: getName' => __ ('Agente asignado'),
'team :: getName' => __ ('Equipo asignado'),
'thread_count' => __ ('Número de subprocesos'),
'attach_count' => __ ('Recuento de adjuntos'),
) + $ cdata,
$ cómo,
nulo
); _

PERO, no estoy seguro de por qué esto funciona ;-)
Saludos.

Tengo los mismos problemas. Solo hay 2 boletos en la exportación.
¡¿Ya estaba en RC3 y RC2 y ahora en el establo ?!

@JediKev @protich
Acabo de confirmar este informe en mi servidor de prueba v1.10 (901e5ea).

Probé la solución anterior y hace que exporte más, pero aún así da como resultado un error de PHP en el registro:
[04-Nov-2016 14:49:25 UTC] Advertencia de PHP: mysqli_result :: free (): No se pudo recuperar mysqli_result en \ support.110 \ include \ mysqli.php en la línea 185

Supongo que aquí es donde @greezybacon dejó de cambiar la fuente para acceder a la base de datos desde mysli y ORM.

He parcheado el archivo usando lo que recomienda @sistemasad , y puedo exportar informes, sin embargo, al hacerlo, mi campo desplegable personalizado de "ubicación" toma la representación numérica a veces y, a veces, la ubicación del número (coma). ¿Algunas ideas?

Tener el mismo problema en la versión 1.10 final. El parche sugerido parece solucionarlo.

Mismo problema, gracias @rayfoss

Intenté la solución anterior, pero aún así aparece un error de PHP en el registro:
Advertencia de PHP: mysqli_result :: free (): No se pudo recuperar mysqli_result en \\ include \ mysqli.php en la línea 185

Hice la llamada de la función free () (mysqli.php en la línea 185) una línea comentada y la exportación funciona.

+1 Tengo el mismo problema.

@HansLe - ¿Puedes aclarar? ¿Resolviste el problema? ¿Cómo y dónde hizo la llamada de la función free ()?

@tdefreest , mi problema fue resuelto. Comenté esta línea (número 185):
// $ __ db-> unbuffered_result-> free ();
en el módulo incluyen \ mssqli.php

El problema se ha resuelto para mí según la recomendación de @sistemasad .

3813

Comentar las líneas según la solución de @sistemasad vuelve a habilitar la exportación pero no escribe correctamente los campos personalizados ... aparecen como números ... ¿alguien ha encontrado una solución mejor?

Tengo el mismo problema que @demenna. Los campos personalizados ahora se exportan como números.

para mí también. Los campos personalizados ahora se exportan como números.

El código comentado por @sistemasad es responsable de convertir los datos sin procesar en datos formateados. Parece que el error se debe a un error en algún lugar de este código. Entonces, comentar ese código evita el error, pero también deshabilita la lógica de formato; es por eso que los campos personalizados se exportan como números.

Mi comprensión de la adición de

Lo que todavía necesitamos es una verdadera solución que conserve la lógica de formato.

La exportación funcionaba bien y exportaba cada ticket, luego de modificar los detalles del ticket del formulario para agregar algunos campos personalizados desde el uso de Campos básicos hasta Listas personalizadas debido a que no hay datos en la exportación, ahora tenemos los datos en el campo personalizado pero solo obtenemos los primeros 2 líneas en exportación. Hasta ahora no hemos tenido éxito en revertir nuestros cambios. Ciertamente, está sucediendo algo que necesita una resolución adecuada y estoy de acuerdo en que lo anterior no es una resolución y necesita una resolución adecuada.

Hola a todos, lo siento un poco perdido con múltiples boletos, entonces, ¿cuál es la solución?

No existe una solución completa hasta el momento, al menos no si desea que los campos personalizados se exporten correctamente. Si está de acuerdo con que no se exporten correctamente, el comentario del 26 de octubre le indicará la dirección correcta.

No estoy seguro de si esto ayuda, pero estoy teniendo el mismo problema y parece ser causado completamente por el código que llama a las columnas personalizadas alrededor de 54 en el archivo class.export.php. Además, ninguna de las otras soluciones en este hilo ha funcionado, simplemente impiden que se cargue toda la página (para mí).

// Agrega campos personalizados a la declaración $ sql
$ cdata = $ campos = matriz ();
foreach (TicketForm :: getInstance () -> getFields () as $ f) {
// Ignorar los campos principales
if (in_array ($ f-> get ('nombre'), array ('prioridad')))
Seguir;
// Ignorar campos que no sean de datos
elseif (! $ f-> hasData () || $ f-> isPresentationOnly ())
Seguir;

        $name = $f->get('name') ?: 'field_'.$f->get('id');
        $key = 'cdata.'.$name;
        $fields[$key] = $f;
        $cdata[$key] = $f->getLocal('label');

Si se comenta la última sección de este código, la exportación funciona como debería, pero omite los campos personalizados. Intenté cambiar el código sin ningún éxito más que conseguir que se llame dos veces a la columna de prioridad (en lugar de donde debería estar la columna de campo personalizado).

Quizás esta información ayude a señalar algo para alguien más experimentado. Si alguien puede darme algún comentario o sugerencia, no dude en hacerlo.

Esta ayuda recopila a todos los expertos, pero sin los campos personalizados, no es bueno :(

@protich @JediKev
¿Alguna posibilidad de que esto se pueda investigar? La exportación sigue sin recuperar los datos de campo personalizados correctamente. Ocurrió después de la actualización de v 1.9 a v 1.10 originalmente: la exportación de tickets a csv se detiene después de exportar solo dos elementos (aunque el archivo aún se crea). La corrección en este hilo evita que los campos personalizados se ejecuten para obtener el par clave-valor, lo que provoca un trabajo manual que conecta la información. Esto también está ocurriendo en la versión más reciente de la versión 1.10.1. Se agradece cualquier ayuda.

Hola.

También tengo el mismo problema aquí:
osTicket Version | v1.10.1 (9ae093d): actualizado
Software de servidor web | Apache / 2.4.6 (CentOS) OpenSSL / 1.0.1e-fips PHP / 5.4.16
Versión de MySQL | 5.5.52
Versión PHP | 5.4.16

Tenemos una lista personalizada, cuando hacemos una búsqueda de tickets con uno de los valores de las listas personalizadas, todos se muestran correctamente en el CSV; sin embargo, si no buscamos algo en esta lista personalizada, solo se obtienen dos filas en la lista. CSV.

La solución para eliminar el campo personalizado da como resultado la salida de todas las filas, pero requerimos que la lista personalizada se incluya en el CSV.

Intenté averiguar qué está pasando, pero no he podido encontrar una solución, por lo que agradecería cualquier otra sugerencia.

Jaime.

Todavía estamos investigando este problema. Hasta que lo solucionemos de forma permanente, puede comentar la línea 63 en include/class.export.php :

->options(QuerySet::OPT_NOCACHE)

... y debería exportarlos todos de nuevo.

Hola.

Gracias por esta solución, ahora muestra todos los tickets, pero significa que solo se muestra el primer elemento de la lista en un campo de lista personalizado, pero los demás no, así que si debería tener 'manzana' y 'pera' en la lista personalizada para ese boleto solo te mostrará 'manzana'.

Jaime.

Bueno, necesitábamos que esto se arreglara, así que haga una solución ... tal vez no sea tan limpio como nos gusta, pero funciona.

Esta es la función completa de dumptickets (la solución comienza alrededor de la línea 83)

static function dumpTickets($sql, $how='csv') {
    // Add custom fields to the $sql statement
    $cdata = $fields = array();
    foreach (TicketForm::getInstance()->getFields() as $f) {
        // Ignore core fields
        if (in_array($f->get('name'), array('priority')))
            continue;
        // Ignore non-data fields
        elseif (!$f->hasData() || $f->isPresentationOnly())
            continue;

        $name = $f->get('name') ?: 'field_'.$f->get('id');
        $key = 'cdata.'.$name;
        $fields[$key] = $f;
        $cdata[$key] = $f->getLocal('label');
    }
    // Reset the $sql query
    $tickets = $sql->models()
        ->select_related('user', 'user__default_email', 'dept', 'staff',
            'team', 'staff', 'cdata', 'topic', 'status', 'cdata__:priority')
        ->options(QuerySet::OPT_NOCACHE)
        ->annotate(array(
            'collab_count' => TicketThread::objects()
                ->filter(array('ticket__ticket_id' => new SqlField('ticket_id', 1)))
                ->aggregate(array('count' => SqlAggregate::COUNT('collaborators__id'))),
            'attachment_count' => TicketThread::objects()
                ->filter(array('ticket__ticket_id' => new SqlField('ticket_id', 1)))
                ->filter(array('entries__attachments__inline' => 0))
                ->aggregate(array('count' => SqlAggregate::COUNT('entries__attachments__id'))),
            'thread_count' => TicketThread::objects()
                ->filter(array('ticket__ticket_id' => new SqlField('ticket_id', 1)))
                ->exclude(array('entries__flags__hasbit' => ThreadEntry::FLAG_HIDDEN))
                ->aggregate(array('count' => SqlAggregate::COUNT('entries__id'))),
        ));

    // Fetch staff information
    // FIXME: Adjust Staff model so it doesn't do extra queries
    foreach (Staff::objects() as $S)
        $S->get('junk');

    //custom list
    $sql = 'SELECT type, name FROM ost_form_field WHERE type like "list%" ';  //fields
    $query = db_query($sql);
    $type_lists = array();
    while($row = mysqli_fetch_assoc($query)){
      $type_lists[] = $row;
    }

    $list = array();
    foreach($type_lists as $type_list){
      $list_id = intval(substr($type_list['type'], 5));

      $sql = 'SELECT id, value FROM ost_list_items WHERE list_id = '.$list_id; //list elements
      $query = db_query($sql);
      while($row = mysqli_fetch_assoc($query)){
        $list[$type_list['name']][$row['id']] = $row['value'];
      }
    }

    $cambio = array('modify' => function(&$record, $keys) use ($fields, $list) {
      $fields_array = array();
      foreach($keys as $key => $row){
        if(strpos($row, 'cdata.') === 0){ 
          $fields_array[$key] = substr($row, 6);
          if(isset($list[$fields_array[$key]]))
            $fields_list[] = $key;
        }
      }
      foreach ($fields as $k=>$f) {
        if (($i = array_search($k, $keys)) !== false) {
          if(in_array($i, $fields_list)){
            $record[$i] = $list[$fields_array[$i]][intval($record[$i])];
          }else{
            $record[$i] = $f->export($f->to_php($record[$i]));
          }
        }
      }
      return $record;
    });

Espero que esto funcione para otra persona ...

La solución de Razarate funcionó de maravilla para mí, con una pequeña modificación. Creo que razarate se olvidó de incluir la siguiente parte esencial de la función de dumptickets revisada:

 return self::dumpQuery($tickets,
        array(
            'number' =>         __('Ticket Number'),
            'created' =>        __('Date Created'),
            'cdata.subject' =>  __('Subject'),
            'user.name' =>      __('From'),
            'user.default_email.address' => __('From Email'),
            'cdata.:priority.priority_desc' => __('Priority'),
            'dept::getLocalName' => __('Department'),
            'topic::getName' => __('Help Topic'),
            'source' =>         __('Source'),
            'status::getName' =>__('Current Status'),
            'lastupdate' =>     __('Last Updated'),
            'est_duedate' =>    __('Due Date'),
            'isoverdue' =>      __('Overdue'),
            'isanswered' =>     __('Answered'),
            'staff::getName' => __('Agent Assigned'),
            'team::getName' =>  __('Team Assigned'),
            'thread_count' =>   __('Thread Count'),
            'attachment_count' => __('Attachment Count'),
        ) + $cdata,
        $how,
        $cambio
        );

Hola, ¿hay alguna noticia sobre cuándo se solucionará esto en v1.10.1?

1.10.1 ya está disponible ... por lo que no se solucionará en 1.10.1.
Me imagino que probablemente se solucionará en 1.11 cuando se lance.

Hola,
@ntozier , ¿puedo encontrar class.export.php con modificaciones?
¡Muchas gracias!

@ elma1003 ¿eh?

He parcheado 1.10 comentando
// -> opciones (QuerySet :: OPT_NOCACHE)
La exportación funcionó bien después de esto.

Ahora he instalado v1.10.1 (9ae093d)
La exportación no está bien, solo 3 líneas.
Estoy intentando pach y no está bien, nada funciona
Descargué 1.10.2 de https://github.com/osTicket/osTicket/releases/tag/v1.10.2
pero class.export.php es el mismo que en 1.10
Por favor ayuda....

@ elma1003 ¿Ha intentado utilizar la solución de Razarate?

@ elma1003 @kclubok

Se incluye una solución para esto en la próxima versión de v1.11.0rc-1 (próximamente disponible).

@ elma1003

Idk qué está sucediendo con su instancia, ya que acabo de comentar esa línea en mi instancia v1.10.1 y está exportando todos los tickets correctamente.

Salud.

¿Alguien consiguió que la exportación, incluidos los campos personalizados, funcionara? Parece que no puedo entenderlo.

Probé la solución de razarate, incluidos los comentarios de kclubok, y probé la versión 1.11.x del archivo class.export.php pero no incluye los campos personalizados.

¿Quizás un alma amable que se las arregló podría publicar el archivo class.export.php modificado aquí?

Este arreglo solía funcionar para mí. De repente, ya no funciona. ¿No estás seguro de lo que pasó?

@JediKev

¿Podría indicarnos la confirmación de la versión 11.0rc-1 que corrige esto? ¡Sería muy útil!

Espero que la solución no sea simplemente comentar esa línea. Como se mencionó anteriormente, eso no produce el comportamiento correcto si hay campos de lista personalizados.

Aún tengo este problema usando el archivo class.export.php ubicado por evertvh.

Probé varias correcciones enumeradas en este problema, pero no me gustó.

Tengo un formato csv modificado con una columna adicional agregada para mostrar la "organización" a la que pertenece cada usuario, como se detalla en el foro de osticket: http://osticket.com/forum/discussion/92606/customising-ticket-csv- export-correct # latest

@Zixt

Gracias, pero hemos abordado estos problemas en v1.11.0rc-1 (lanzando _muy_pronto; con suerte para el lunes). Además de abordar el problema original, agrega la capacidad de personalizar los campos que desea exportar.

Salud.

EdiJediKev

Ah, está bien, bonito.

Salud.

Hola @JediKev

He actualizado a la última versión de nuestra instalación, pero tengo problemas para personalizar la cola según mis especificaciones.

¡Disculpas si este no es el lugar correcto para preguntar!

Logré agregar "Organización" a la página de cola correctamente utilizando un campo personalizado con la fuente de datos principal configurada como "Usuario / Organización / Nombre"

Sin embargo, no tengo la opción de agregar un campo personalizado a la pestaña Exportar y solo puedo seleccionar de un conjunto de encabezados de campo predefinidos.

¿Hay algo que este olvidando?

@Zixt

Este no es el lugar para informar su problema. Abriría su propio problema y completaría la Plantilla de nuevo problema. Habiendo dicho eso, seguiré adelante y publicaré mi respuesta a continuación para que al menos tenga una respuesta rápida. 👍

_ Descargo de responsabilidad: lo siguiente solo se aplica a v1.11.0rc-1 _

Actualmente, no puede agregar campos de usuario, campos de organización, etc. a las exportaciones de cola personalizada, ya que esta función solo se encuentra en la fase 1 (o versión 1) y es limitada. Creo que se ampliará cada vez más con el tiempo para permitir todo tipo de campos. Puede ver todos los campos que puede agregar / reorganizar ahora en Panel de administración> Configuración> Tickets> Colas> haga clic en el nombre de la cola> Exportar> Agregar otro campo .

_ (Lamento haberle respondido mal anteriormente; pensé que el nuevo exportador tenía la opción de agregar ese tipo de campos, pero resulta que no es así. ¡Al menos las exportaciones ahora son personalizables!) _

** Nota al margen

Siempre puede exportar el nombre de la organización de un usuario yendo a Panel de agentes> Usuarios> Directorio de usuarios y haciendo clic en Exportar en la parte inferior.


Salud.

mismo "1.10 - La exportación de la lista de tickets genera solo dos primeras líneas" en 1.10.4 después de la actualización desde 1.10.1

esto podría ser sobre eso:
[SELECCIONAR A3. staff_id AS lock__staff_id , A1. staff_id AS staff_id , A1. isoverdue AS isoverdue , A1. team_id AS team_id , A1. ticket_id AS ticket_id , A1. number AS number , A4. subject AS cdata__subject , A6. address AS user__default_email__address , A1. source AS source , A7. priority_color AS cdata__:priority__priority_color , A7. priority_desc AS cdata__:priority__priority_desc , A1. status_id AS status_id , A8. name AS status__name , A8. state AS status__state , A1. dept_id AS dept_id , B0. name AS dept__name , A5. name AS user__name , A1. lastupdate AS lastupdate , A1. isanswered AS isanswered , B1. firstname AS staff__firstname , B1. lastname AS staff__lastname , B2. name AS team__name , (SELECCIONAR CONTEO (R0. id ) AS count DESDE ost_thread Q7 ÚNETE ost_ticket Q8 ENCENDIDO (Q7. object_type = 'T' Y Q7. object_id = Q8. ticket_id ) IZQUIERDA UNIRSE ost_thread_collaborator R0 ENCENDIDO (Q7. id = R0. thread_id ) DONDE Q8. ticket_id = A1. ticket_id ) AS collab_count, (SELECT COUNT (R1. id ) AS count DESDE ost_thread Q7 ÚNETE ost_ticket Q8 ENCENDIDO (Q7. object_type = 'T' Y Q7. object_id = Q8. ticket_id ) IZQUIERDA UNIRSE ost_thread_entry R0 ENCENDIDO (Q7. id = R0. thread_id ) IZQUIERDA UNIRSE ost_attachment R1 ENCENDIDO (R1. type = 'H' Y R0. id = R1. object_id ) DONDE Q8. ticket_id = A1. ticket_id Y R1. inline = 0) AS adjunto_count, (SELECT COUNT (R0. id ) AS count FROM ost_thread Q7 UNIRSE ost_ticket Q8 ON (Q7. object_type = 'T' Y Q7. object_id = Q8. ticket_id ) LEFT JOIN ost_thread_entry R0 ON (Q7. id = R0. thread_id ) DONDE Q8. ticket_id = A1. ticket_id Y NO R0. flags & 4! = 0) AS thread_count FROM ost_ticket A1 UNIR (SELECCIONE Q7. ticket_id DESDE ost_ticket Q7 ÚNETE ost_ticket_status Q8 ON (Q7. status_id = Q8. id ) DONDE Q8. state state = 'abrir' Y (Q7. staff_id = 2 O Q7. team_id IN (1))) O Q7. dept_id IN ('1', '2', '3')) PEDIR POR Q7. ASC LIMIT 25) A2 LEFT JOIN `ost_lock` A3 ON (A1.`lock_id` = A3.`lock_id` AND A3.`expire` > NOW()) LEFT JOIN `ost_ticket__cdata` A4 ON (A1.`ticket_id` = A4.`ticket_id`) JOIN `ost_user` A5 ON (A1.`user_id` = A5.`id`) LEFT JOIN `ost_user_email` A6 ON (A5.`default_email_id` = A6.`id`) LEFT JOIN `ost_ticket_priority` A7 ON (A4.`priority` = A7.`priority_id`) JOIN `ost_ticket_status` A8 ON (A1.`status_id` = A8.`id`) JOIN `ost_department` B0 ON (A1.`dept_id` = B0.`id`) LEFT JOIN `ost_staff` B1 ON (A1.`staff_id` = B1.`staff_id`) LEFT JOIN `ost_team` B2 ON (A1.`team_id` = B2.`team_id`) WHERE A1.`ticket_id` = A2.`ticket_id` GROUP BY A3.`staff_id`, A1.`staff_id`, A1.`isoverdue`, A1.`team_id`, A1.`ticket_id`, A1.`number`, A4.`subject`, A6.`address`, A1.`source`, A7.`priority_color`, A7.`priority_desc`, A1.`status_id`, A8.`name`, A8.`state`, A1.`dept_id`, B0.`name`, A5.`name`, A1.`lastupdate`, A1.`isanswered`, B1.`firstname`, B1.`lastname`, B2.`name` ORDER BY A1. ASC]

Columna desconocida 'Q7'. en 'cláusula de orden'



---- Traza atrás ----

0 (root) /include/mysqli.php (204): osTicket-> logDBError ('Error DB # 1054', '[SELECT A3`sta ...')

1 (raíz) /include/class.orm.php (3136): db_query ('SELECCIONAR A3`staf ...', verdadero, verdadero)

2 (raíz) /include/class.orm.php (3183): MySqlExecutor-> execute ()

3 (raíz) /include/class.orm.php (1868): MySqlExecutor-> getArray ()

4 (raíz) /include/class.orm.php (1818): HashArrayIterator -> {cierre} ()

5 (raíz) /include/class.orm.php (1797): CallbackSimpleIterator-> next ()

6 (raíz) /include/class.orm.php (1806): CallbackSimpleIterator-> rewind ()

7 (raíz) /include/class.orm.php (1463): CallbackSimpleIterator-> valid ()

8 (raíz) /include/class.orm.php (1480): CachedResultSet-> fillTo (9223372036854775807)

9 (raíz) /include/class.orm.php (1489): CachedResultSet-> asArray ()

10 (raíz) /include/staff/tickets.inc.php (570): CachedResultSet-> getIterator ()

11 (raíz) /scp/tickets.php (495): require_once ('(raíz) / en ...')

12 {principal}

Exportación v1.11.0-rc1 solo con encabezado.

1.10 actualizado a 1.11rc1

La exportación del tablero funciona, la exportación de tickets: no se puede encontrar el archivo en http://xxxxxxxx.xxxxxxx.com/helpdesk/scp/tickets.php?a=export&queue=adhoc , ikDr5jdnAc.

1.10.4 ya tiene estas líneas, el mismo problema: solo dos líneas en el encabezado csv y un ticket

osTicket Version | v1.10.4
Versión PHP | 5.6.37

Revisa tus recomendaciones sin embargo sigo con el mismo problema, al exportar el reporte de tickets con estado "cerrado", el archivo solo me muestra 1 ticket.

Estaba trabajando en 1.10.1
bloqueador real
Sé que todos están en 1.11, pero a menos que 1.11 estable salga el próximo mes, danos la pista para solucionar este problema.

@lavdnone La corrección publicada por @JediKev en este hilo me funciona tanto en 1.10.0 como en 1.10.4.
https://github.com/osTicket/osTicket/issues/3264#issuecomment -330262555

Gracias, no sé cómo me lo perdí, # 3264 funcionó

@lavdnone muy bienvenido. ¡Que tengas un buen descanso del día! :)

También tengo el problema de que no se muestran todas las entradas.
el uso de las soluciones anteriores en el archivo no me funciona. Cuando lo uso, siempre obtengo un error de php

¿Alguien puede publicar un class.export.php completo de trabajo?

@Orkanson

¿Comentas esa línea y te da un error de php? Parece que lo hiciste mal. Todo lo que tienes que hacer es comentar una línea y funciona.
# 3264 (comentario)

Salud.

Comenté la línea 58 en _include / class.export.php_, como se recomienda en este hilo, y ahora puedo exportar todos los boletos a formato .csv.
//->options(QuerySet::OPT_NOCACHE)

OSTicket v1.10.4 en Ubuntu 16

Comenté la línea 58 en _include / class.export.php_, como se recomienda en este hilo,
y ahora puedo exportar todos los tickets a formato .csv.
//->options(QuerySet::OPT_NOCACHE)

Sí,
también parece funcionar en mi archivo que parte del código es una línea 63 pero se come la memoria ... Puedo exportar pequeñas listas de boletos, pero si tomo una lista con cientos de miles de boletos, inevitablemente termina con un error :-(

_PHP Error fatal: se agotó el tamaño de memoria permitido de 536870912 bytes (se intentó asignar 32 bytes) en include / class.orm.php en la línea 3146_

Cambié los límites hasta 512 MB, pero me detuve y restauré el límite anterior, para evitar algunos problemas más críticos.

NB: También probé la otra solución publicada por @JediKev pero, en cualquier caso, requiere demasiada memoria RAM si la lista es grande.

73s,
Arturo.

@ iw0der

Tenemos una solución para la serie 1.12.x próximamente que aborda los tiempos de espera de exportación de tickets para grandes conjuntos de datos. Por favor manténgase al tanto.

Salud.