thuc960,
o que fiz foi mudar esta chamada de retorno no arquivo class.export.php , sobre a linha 85 dentro da função function dumpTickets ($ sql, $ how = 'csv') :

_return self :: dumpQuery ($ tickets,
variedade(
'número' => __ ('Número do bilhete'),
'criado' => ('Data de criação








'lastupdate' => __ ('Última atualização'),
'est_duedate' => __ ('Data de vencimento'),
'isoverdue' => __ ('Overdue'),
'isanswered' => __ ('Respondido'),
'staff :: getName' => __ ('Agente atribuído'),
'equipe :: getName' => __ ('Equipe atribuída'),
'thread_count' => __ ('Thread Count'),
'contagem de anexos' => __ ('Contagem de anexos'),
) + $ cdata,
$ como,
array ('modificar' => função (& $ registro, $ chaves) uso ($ campos) {
foreach ($ campos como $ k => $ f) {
if (($ i = array_search ($ k, $ keys))! == false) {
$ record [$ i] = $ f-> export ($ f-> to_php ($ record [$ i]));
}
}
echo $ record
return $ record;
})
); _

Com isso (remova o último parâmetro, após $ how,):

_return self :: dumpQuery ($ tickets,
variedade(
'número' => __ ('Número do bilhete'),
'criado' => ('Data de criação








'lastupdate' => __ ('Última atualização'),
'est_duedate' => __ ('Data de vencimento'),
'isoverdue' => __ ('Overdue'),
'isanswered' => __ ('Respondido'),
'staff :: getName' => __ ('Agente atribuído'),
'equipe :: getName' => __ ('Equipe atribuída'),
'thread_count' => __ ('Thread Count'),
'contagem de anexos' => __ ('Contagem de anexos'),
) + $ cdata,
$ como,
nulo
); _

MAS, não sei por que isso funciona ;-)
Cumprimentos.

Eu tenho os mesmos problemas. Apenas 2 tickets estão na exportação.
Já estava no RC3 e RC2 e agora no estável ?!

@JediKev @protich
Acabei de confirmar este relatório em meu servidor de teste v1.10 (901e5ea).

Tentei a correção acima e ela faz com que seja mais exportado, mas ainda resulta em um erro de PHP no log:
[04-Nov-2016 14:49:25 UTC] Aviso do PHP: mysqli_result :: free (): Não foi possível buscar mysqli_result em \ support.110 \ include \ mysqli.php na linha 185

Meu palpite é que foi aqui que @greezybacon parou de alterar a fonte para acessar o banco de dados de mysli e ORM.

Corrigi o arquivo usando o que

Tendo o mesmo problema na versão final 1.10. O patch sugerido parece corrigir isso.

Mesmo problema, obrigado @rayfoss

Tentei a correção acima, mas ainda resulta em um erro de PHP no log:
Aviso de PHP: mysqli_result :: free (): Não foi possível buscar mysqli_result em \\ include \ mysqli.php na linha 185

Fiz a chamada da função free () (mysqli.php na linha 185) uma linha comentada e a exportação funciona.

1 Estou tendo o mesmo problema.

@HansLe - Você pode esclarecer? Você resolveu o problema? Como e onde você fez a chamada da função free ()?

@tdefreest , meu problema foi resolvido. Comentei esta linha (número 185):
// $ __ db-> unbuffered_result-> free ();
no módulo include \ mssqli.php

O problema foi resolvido para mim de acordo com a recomendação

3813

Comentar as linhas de acordo com a solução de

Estou tendo o mesmo problema que @demenna. Os campos personalizados agora são exportados como números.

para mim também. Os campos personalizados agora são exportados como números.

O código comentado por @sistemasad é responsável por converter dados brutos em dados formatados. Parece que o erro foi disparado por um bug em algum lugar deste código. Portanto, comentar esse código evita o bug, mas também desativa a lógica de formatação - é por isso que os campos personalizados são exportados como números.

Meu entendimento da adição de

O que ainda precisamos é de uma correção verdadeira que preserve a lógica de formatação.

A exportação estava funcionando bem e todos os tíquetes foram exportados, depois de modificar os detalhes do tíquete do formulário para adicionar alguns campos personalizados usando campos básicos para listas personalizadas, devido à falta de preenchimento de dados na exportação, agora temos os dados no campo personalizado, mas obtemos apenas os 2 primeiros linhas na exportação. Até agora, não encontramos sucesso em nossas mudanças. Certamente há algo acontecendo que precisa de uma resolução adequada e concordo que o que foi dito acima não é uma resolução e precisa de uma resolução adequada.

Olá a todos, desculpe um pouco perdido com vários tickets, então qual é a solução?

Ainda não há uma solução completa, pelo menos não se você deseja que os campos personalizados sejam exportados corretamente. Se você concordar com eles não exportando corretamente, o comentário de 26 de outubro indicará a direção certa.

Não tenho certeza se isso ajuda, mas estou tendo o mesmo problema e parece ser causado inteiramente pelo código chamando as colunas personalizadas em torno de 54 no arquivo class.export.php. Além disso, nenhuma das outras soluções neste tópico funcionou, elas apenas impedem o carregamento da página inteira (para mim).

// Adicionar campos personalizados à instrução $ sql
$ cdata = $ campos = array ();
foreach (TicketForm :: getInstance () -> getFields () as $ f) {
// Ignore os campos principais
if (in_array ($ f-> get ('nome'), array ('prioridade')))
Prosseguir;
// Ignorar campos sem dados
elseif (! $ f-> hasData () || $ f-> isPresentationOnly ())
Prosseguir;

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

Se a última seção deste código for comentada, a exportação funciona da maneira que deveria, mas deixa de fora quaisquer campos personalizados. Tentei alterar o código sem absolutamente nenhum sucesso, exceto fazer com que a coluna de prioridade fosse chamada duas vezes (no lugar de onde deveria estar a coluna do campo personalizado).

Talvez esta informação ajude a apontar algo para alguém mais experiente. Se alguém puder me dar algum feedback / sugestões, fique à vontade.

Essa ajuda coleta todos os especialistas, mas sem os campos personalizados, não é bom :(

@protich @JediKev
Alguma chance disso ser investigado? A exportação ainda não está buscando os dados do campo personalizado corretamente. Ocorreu após a atualização de v 1.9 para v 1.10 originalmente: a exportação de tickets para csv para após a exportação de apenas dois itens (embora o arquivo ainda seja criado). A correção neste encadeamento evita que os campos personalizados sejam executados para buscar o par de valores-chave, causando algum trabalho manual conectando as informações. Isso também está ocorrendo na versão mais recente v 1.10.1. Qualquer ajuda é apreciada.

Olá.

Estou tendo o mesmo problema aqui também:
osTicket Version | v1.10.1 (9ae093d) - atualizado
Software de servidor web | Apache / 2.4.6 (CentOS) OpenSSL / 1.0.1e-fips PHP / 5.4.16
Versão MySQL | 5.5.52
Versão PHP | 5.4.16

Temos uma lista personalizada, quando fazemos uma pesquisa por tickets com um dos valores da lista personalizada, todos eles são colocados no CSV corretamente; no entanto, se não pesquisarmos por algo nesta lista personalizada, apenas duas linhas serão geradas no CSV.

A correção para remover o campo personalizado resulta na saída de todas as linhas, mas exigimos que a lista personalizada seja incluída no CSV.

Tentei descobrir o que está acontecendo, mas não consegui encontrar uma solução para isso, então agradeceria mais sugestões.

James.

Ainda estamos investigando esse problema. Até que o consertemos permanentemente, você pode comentar a linha 63 em include/class.export.php :

->options(QuerySet::OPT_NOCACHE)

... e você deve exportá-los novamente.

Olá.

Obrigado por esta solução, agora mostra todos os tickets, mas significa que apenas o primeiro item da lista em um campo de lista personalizado é exibido, mas qualquer outro não, portanto, se deveria ter 'apple' e 'pear' na lista personalizada para esse bilhete só vai mostrar 'maçã'.

James.

Bem, precisávamos que isso fosse corrigido, então dê uma solução alternativa ... talvez não esteja tão limpo quanto gostaríamos, mas funciona.

Esta é a função de dumptickets completa (a solução começa na linha 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 funcione para outra pessoa ...

A solução de Razarate funcionou perfeitamente para mim - com uma pequena modificação. Acho que razarate esqueceu de incluir a seguinte parte essencial da função 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
        );

Olá, há alguma notícia de quando isso será corrigido na v1.10.1?

1.10.1 já está disponível ... então não será corrigido em 1.10.1.
Eu imagino que provavelmente será corrigido no 1.11 quando for lançado.

Olá,
@ntozier , posso encontrar class.export.php com modificações?
Muito Obrigado!

@ elma1003 hein?

Eu corrigi 1.10 comentando
// -> opções (QuerySet :: OPT_NOCACHE)
A exportação estava funcionando bem depois disso

Agora instalei a v1.10.1 (9ae093d)
Exportar não está ok, apenas 3 linhas.
Estou tentando pach e não está ok nada funciona
Baixei 1.10.2 de https://github.com/osTicket/osTicket/releases/tag/v1.10.2
mas class.export.php é o mesmo que em 1.10
Por favor ajude....

@ elma1003 Você já tentou usar a solução do Razarate?

@ elma1003 @kclubok

Uma correção para isso está incluída na próxima versão da v1.11.0rc-1 (lançada em breve).

@ elma1003

Veja o que está acontecendo com sua instância, já que acabei de comentar essa linha na minha instância v1.10.1 e ela está exportando todos os tickets corretamente.

Saúde.

Alguém conseguiu que a exportação - incluindo campos personalizados - funcionasse? Não consigo entender.

Eu tentei a solução do razarate incluindo o feedback do kclubok e tentei a versão 1.11.x do arquivo class.export.php, mas não inclui os campos personalizados.

Talvez uma alma gentil que conseguiu, pudesse postar o arquivo class.export.php modificado aqui?

Este conserto costumava funcionar para mim. De repente, ele não está mais funcionando. Não tem certeza do que aconteceu?

@JediKev

Você poderia nos indicar o commit para v.11.0rc-1 que corrige isso? Seria muito útil!

Espero que a correção não seja simplesmente comentar essa linha. Como mencionado antes, isso não produz o comportamento correto se houver campos de lista personalizados.

Ainda tendo esse problema usando o arquivo class.export.php localizado por evertvh.

Eu tentei várias correções listadas neste problema, mas não foi nada agradável.

Eu tenho um formato csv modificado com uma coluna adicional adicionada para mostrar a "organização" à qual cada usuário pertence, conforme detalhado no fórum do osticket - http://osticket.com/forum/discussion/92606/customising-ticket-csv- export-correct # mais recente

@Zixt

Obrigado, mas, na verdade, resolvemos esses problemas em v1.11.0rc-1 (lançando _muito_ em breve; espero que até segunda-feira). Além de abordar o problema original, ele adiciona a capacidade de personalizar quais campos você deseja exportar.

Saúde.

EdiJediKev

Ah ok - bom.

Saúde.

Oi @JediKev

Atualizei para a versão mais recente em nossa instalação, mas estou tendo problemas para personalizar a fila de acordo com minhas especificações?

Pedimos desculpas se este não for o lugar correto para perguntar!

Consegui adicionar "Organização" à página Fila corretamente usando um campo personalizado com fonte de dados primária definida como "Usuário / Organização / Nome"

No entanto, não tenho a opção de adicionar um campo personalizado à guia Exportar e só posso selecionar a partir de um conjunto de cabeçalhos de campo predefinidos.

Há algo que estou perdendo?

@Zixt

Este não é o lugar para relatar seu problema. Você abriria seu próprio problema e preencheria o novo modelo de problema. Com isso dito, irei postar minha resposta abaixo para que você pelo menos tenha uma resposta rápida. 👍

_ Isenção de responsabilidade: o seguinte se aplica apenas a v1.11.0rc-1 _

Atualmente, você não pode adicionar campos de usuário, campos de organização, etc. às Exportações de fila personalizadas, pois esse recurso está apenas na fase 1 (ou versão 1) e é limitado. Eu _acredito_ que será expandido mais e mais com o tempo para permitir todos os tipos de campos. Você pode ver todos os campos que pode adicionar / reorganizar agora em Painel do administrador> Configurações> Tickets> Filas> clique no nome da fila> Exportar> Adicionar outro campo .

_ (Lamento ter respondido errado anteriormente; pensei que o novo exportador tinha a opção de adicionar esses tipos de campos, mas não tem. No entanto, pelo menos as exportações são personalizáveis ​​agora!) _

** Nota

Você sempre pode exportar o nome da organização de um usuário acessando Painel do agente> Usuários> Diretório do usuário e clicando em Exportar na parte inferior.


Saúde.

mesmo "1.10 - A exportação da lista de tickets produz apenas duas primeiras linhas" em 1.10.4 após a atualização de 1.10.1

isso pode ser sobre isso:
[SELECIONE 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 , (SELECT COUNT (R0. id ) AS count FROM ost_thread Q7 JUNTE-SE ost_ticket Q8 ON (Q7. object_type = 'T' AND Q7. object_id = Q8. ticket_id ) LEFT JOIN ost_thread_collaborator R0 ON (Q7. id = R0. thread_id ) ONDE Q8. ticket_id = A1. ticket_id ) AS collab_count, (SELECT COUNT (R1. id ) AS count FROM ost_thread Q7 JOIN ost_ticket Q8 ON (Q7. object_type = 'T' E Q7. object_id = Q8. ticket_id ) LEFT JOIN ost_thread_entry R0 ON (Q7. id = R0. thread_id ) LEFT JOIN ost_attachment R1 ON (R1. type = 'H' AND R0. id = R1. object_id ) ONDE Q8. ticket_id = A1. ticket_id AND R1. inline = 0) AS attachment_count, (SELECT COUNT (R0. id ) AS count FROM ost_thread Q7 JOIN ost_ticket Q8 ON (Q7. object_type = 'T' E Q7. object_id = Q8. ticket_id ) LEFT JOIN ost_thread_entry R0 ON (Q7. id = R0. thread_id ) ONDE Q8. ticket_id = A1. ticket_id E NÃO R0. flags & 4! = 0) AS thread_count FROM ost_ticket A1 PARTICIPAR (SELECIONE Q7. ticket_id FROM ost_ticket Q7 PARTICIPE DE ost_ticket_status Q8 ON (Q7. status_id = Q8. id ) ONDE Q8. state state = 'aberto' E (Q7. staff_id = 2 OU Q7. team_id IN (1))) OU Q7. dept_id IN ('1', '2', '3')) ORDENAR 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]

Coluna desconhecida 'Q7.' na 'cláusula de pedido'



---- Backtrace ----

0 (root) /include/mysqli.php (204): osTicket-> logDBError ('Erro do banco de dados # 1054', '[SELECIONE A3.`sta ...')

1 (root) /include/class.orm.php (3136): db_query ('SELECT A3.`staf ...', true, true)

2 (root) /include/class.orm.php (3183): MySqlExecutor-> execute ()

3 (root) /include/class.orm.php (1868): MySqlExecutor-> getArray ()

4 (root) /include/class.orm.php (1818): HashArrayIterator -> {closure} ()

5 (root) /include/class.orm.php (1797): CallbackSimpleIterator-> next ()

6 (root) /include/class.orm.php (1806): CallbackSimpleIterator-> rewind ()

7 (root) /include/class.orm.php (1463): CallbackSimpleIterator-> válido ()

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

9 (root) /include/class.orm.php (1489): CachedResultSet-> asArray ()

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

11 (root) /scp/tickets.php (495): require_once ('(root) / in ...')

12 {main}

Exportação v1.11.0-rc1 apenas com cabeçalho.

1.10 atualizado para 1.11rc1

a exportação do painel funciona, exportação de tíquete: não é possível encontrar o arquivo em http://xxxxxxxx.xxxxxxx.com/helpdesk/scp/tickets.php?a=export&queue=adhoc , ikDr5jdnAc.

1.10.4 já tem essas linhas, mesmo problema - apenas duas linhas no cabeçalho csv e um tíquete

osTicket Version | v1.10.4
Versão PHP | 5.6.37

Reveja suas recomendações porém continuo com o mesmo problema, ao exportar o relatório de tickets com status "fechado", o arquivo me mostra apenas 1 ticket.

Estava trabalhando em 1.10.1
verdadeiro bloqueador
Eu sei que todo mundo está em 1.11, mas a menos que 1.11 estável seja lançado no próximo mês, nos dê a pista para consertar este.

@lavdnone A correção postada por @JediKev neste tópico funciona para mim em 1.10.0 e 1.10.4.
https://github.com/osTicket/osTicket/issues/3264#issuecomment -330262555

Obrigado, não sei como perdi, # 3264 funcionou

@lavdnone muito bem-vindo. Tenha um ótimo resto de dia! :)

Eu também tenho o problema de que nem todos os tickets são exibidos.
o uso das soluções acima no arquivo não funciona para mim. Quando uso, sempre recebo erro de php

Alguém pode postar um trabalho completo class.export.php?

@Orkanson

Você comenta essa linha e dá um erro de php? Parece que você fez errado. Tudo que você precisa fazer é comentar uma linha e funciona.
# 3264 (comentário)

Saúde.

Comentei a linha 58 em _include / class.export.php_, conforme recomendado neste tópico, e agora posso exportar todos os tickets para o formato .csv.
//->options(QuerySet::OPT_NOCACHE)

OSTicket v1.10.4 no Ubuntu 16

Comentei a linha 58 em _include / class.export.php_, conforme recomendado neste tópico,
e agora posso exportar todos os tíquetes para o formato .csv.
//->options(QuerySet::OPT_NOCACHE)

Sim,
também parece funcionar no meu arquivo que parte do código é uma linha 63, mas consome a memória ... Posso exportar pequenas listas de tickets, mas se eu pegar uma lista com centenas de milhares de tickets inevitavelmente terminará com um erro :-(

_PHP Erro fatal: tamanho de memória permitido de 536870912 bytes esgotados (tentativa de alocar 32 bytes) em include / class.orm.php na linha 3146_

Mudei os limites para 512 MB, mas parei e restaurei o limite antigo, para evitar alguns problemas mais críticos.

NB: Eu também tentei outra correção postada por @JediKev, mas em qualquer caso, requer muita

73s,
Arturo.

@ iw0der

Em breve, temos uma correção para a série 1.12.x que aborda os tempos limite de exportação de tíquetes para grandes conjuntos de dados. Por favor fique atento.

Saúde.