thuc960,
ce que j'ai fait, c'est changer cet appel de retour sur le fichier class.export.php , à propos de la ligne 85 à l'intérieur de la fonction function dumpTickets($sql, $how='csv') :

_return self::dumpQuery($tickets,
déployer(
'numéro' => __('Numéro de ticket'),
'créé' => ('Date de création








'lastupdate' => __('Dernière mise à jour'),
'est_duedate' => __('Date d'échéance'),
'en retard' => __('en retard'),
'isanswered' => __('Répondu'),
'staff::getName' => __('Agent Assigned'),
'team::getName' => __('Team Assigned'),
'thread_count' => __('Thread Count'),
'attachment_count' => __('Attachment Count'),
) + $cdata,
$comment,
array('modify' => function(&$record, $keys) use ($fields) {
foreach ($fields as $k=>$f) {
if (($i = array_search($k, $keys)) !== false) {
$record[$i] = $f->export($f->to_php($record[$i]));
}
}
echo $record
retourner $record ;
})
);_

Avec ceci (supprimez le dernier paramètre, après $how,):

_return self::dumpQuery($tickets,
déployer(
'numéro' => __('Numéro de ticket'),
'créé' => ('Date de création








'lastupdate' => __('Dernière mise à jour'),
'est_duedate' => __('Date d'échéance'),
'en retard' => __('en retard'),
'isanswered' => __('Répondu'),
'staff::getName' => __('Agent Assigned'),
'team::getName' => __('Team Assigned'),
'thread_count' => __('Thread Count'),
'attachment_count' => __('Attachment Count'),
) + $cdata,
$comment,
nul
);_

MAIS, je ne sais pas pourquoi cela fonctionne ;-)
Salutations.

J'ai les mêmes problèmes. Seuls 2 tickets sont à l'export.
Était déjà en RC3 et RC2 et maintenant dans l'écurie ?!

@JediKev @protich
Je viens de confirmer ce rapport sur mon serveur de test v1.10 (901e5ea).

J'ai essayé le correctif ci-dessus, et cela l'exporte davantage, mais entraîne toujours une erreur PHP dans le journal :
[04-Nov-2016 14:49:25 UTC] Avertissement PHP : mysqli_result::free() : Impossible de récupérer mysqli_result dans \support.110\include\mysqli.php à la ligne 185

Je suppose que c'est là que @greezybacon a cessé de changer la source pour accéder à la base de données à partir de mysli et ORM.

J'ai corrigé le fichier en utilisant ce que @sistemasad recommande, et je suis en mesure d'exporter des rapports, mais cela ressemble à ce que mon champ déroulant "emplacement" personnalisé saisit parfois la représentation numérique et parfois l'emplacement du nombre (virgule). Des idées?

Avoir le même problème sur la version finale 1.10. Le correctif suggéré semble le résoudre.

Même problème, merci @rayfoss

J'ai essayé le correctif ci-dessus mais entraîne toujours une erreur PHP dans le journal :
Avertissement PHP : mysqli_result::free() : impossible de récupérer mysqli_result dans \\include\mysqli.php à la ligne 185

J'ai fait de l'appel de la fonction free() (mysqli.php à la ligne 185) une ligne commentée et l'export fonctionne.

+1 J'ai le même problème.

@HansLe - Pouvez-vous clarifier? Avez-vous résolu le problème ? Comment et où avez-vous fait l'appel de la fonction free() ?

@tdefrest , mon problème a été résolu. J'ai commenté cette ligne (numéro 185) :
// $__db->unbuffered_result->free();
dans le module include\mssqli.php

Le problème a été résolu pour moi conformément à la recommandation de @sistemasad .

3813

Commenter les lignes selon la solution de @sistemasad réactive l'exportation mais ne parvient pas à écrire correctement les champs personnalisés... ils apparaissent sous forme de nombres... quelqu'un a-t-il trouvé une meilleure solution ?

J'ai le même problème que @demenna. Les champs personnalisés sont désormais exportés sous forme de nombres.

pour moi aussi. Les champs personnalisés sont désormais exportés sous forme de nombres.

Le code commenté par @sistemasad est chargé de convertir les données brutes en données formatées. Il semble que l'erreur soit déclenchée par un bogue quelque part dans ce code. Ainsi, commenter ce code empêche le bogue, mais désactive également la logique de formatage - c'est pourquoi les champs personnalisés sont exportés sous forme de nombres.

Ma compréhension de l' ajout de

Ce dont nous avons encore besoin, c'est d'un véritable correctif qui préserve la logique de formatage.

L'exportation fonctionnait bien et exportait chaque ticket, puis après avoir modifié les détails du ticket de formulaire pour ajouter des champs personnalisés à partir de l'utilisation des champs de base vers les listes personnalisées en raison de l'absence de données dans l'exportation, nous avons maintenant les données dans le champ personnalisé mais n'obtenons que les 2 premiers lignes à l'export. Jusqu'à présent, nous n'avons pas réussi à annuler nos changements. Il se passe certainement quelque chose qui nécessite une résolution appropriée et je suis d'accord que ce qui précède n'est pas une résolution et a besoin d'une résolution appropriée.

BONJOUR à tous, désolé un peu perdu avec plusieurs tickets, alors quelle est la solution ?

Il n'y a pas encore de solution complète, du moins pas si vous voulez que les champs personnalisés s'exportent correctement. Si vous êtes d'accord avec le fait qu'ils n'exportent pas correctement, alors le commentaire du 26 octobre vous orientera dans la bonne direction.

Je ne sais pas si cela aide, mais j'ai le même problème et cela semble être entièrement causé par le code appelant les colonnes personnalisées autour de 54 dans le fichier class.export.php. De plus, aucune des autres solutions de ce fil n'a fonctionné, elles arrêtent simplement le chargement de la page entière (pour moi).

// Ajout de champs personnalisés à l'instruction $sql
$cdata = $fields = array();
foreach (TicketForm::getInstance()->getFields() as $f) {
// Ignorer les champs de base
if (in_array($f->get('nom'), array('priority')))
Continuez;
// Ignorer les champs non-données
elseif (!$f->hasData() || $f->isPresentationOnly())
Continuez;

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

Si la dernière section de ce code est commentée, l'exportation fonctionne comme il se doit, mais omet les champs personnalisés. J'ai essayé de changer le code sans aucun succès autre que d'appeler la colonne prioritaire deux fois (au lieu de l'endroit où la colonne de champ personnalisé devrait être).

Peut-être que cette information aidera à identifier quelque chose pour quelqu'un de plus expérimenté. Si quelqu'un peut me donner des commentaires/suggestions, n'hésitez pas.

Cette aide rassemble tous les experts mais sans les champs personnalisés, ce n'est pas bon :(

@protich @JediKev
Une chance que cela puisse être examiné? L'exportation ne récupère toujours pas correctement les données des champs personnalisés. Survenu après la mise à niveau de la v 1.9 vers la v 1.10 à l'origine : l'exportation des tickets au format csv s'arrête après l'exportation de seulement deux éléments (le fichier est toujours créé cependant). Le correctif dans ce fil empêche les champs personnalisés de s'exécuter pour récupérer la paire clé-valeur, ce qui entraîne un travail manuel pour connecter les informations. Cela se produit également sur la version la plus récente v 1.10.1. Toute aide est appréciée.

Bonjour.

J'ai le même problème ici aussi :
osVersion Ticket | v1.10.1 (9ae093d) — À jour
Logiciel de serveur Web | Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.4.16
Version MySQL | 5.5.52
Version PHP | 5.4.16

Nous avons une liste personnalisée, lorsque nous effectuons une recherche de tickets avec l'une des valeurs de listes personnalisées, ils sont tous sortis correctement dans le CSV, cependant, si nous ne recherchons pas quelque chose dans cette liste personnalisée, seules deux lignes sont sorties dans le CSV.

Le correctif pour supprimer le champ personnalisé entraîne la sortie de toutes les lignes, mais nous exigeons que la liste personnalisée soit incluse dans le fichier CSV.

J'ai essayé de comprendre ce qui se passe mais je n'ai pas pu trouver de solution, donc j'apprécierais d'autres suggestions.

James.

Nous étudions toujours cette question. Jusqu'à ce que nous le réparions définitivement, vous pouvez commenter la ligne 63 dans include/class.export.php :

->options(QuerySet::OPT_NOCACHE)

...et vous devriez tous les exporter à nouveau.

Bonjour.

Merci pour cette solution, il affiche maintenant tous les tickets, mais cela signifie que le seul premier élément de liste dans un champ de liste personnalisé s'affiche, mais pas les autres, donc s'il doit avoir "pomme" et "poire" dans la liste personnalisée pour ce billet, il ne vous montrera que "pomme".

James.

Eh bien, nous avions besoin que cela soit corrigé, alors faites une solution de contournement ... ce n'est peut-être pas aussi propre que nous l'aimons, mais cela fonctionne.

Il s'agit de la fonction de dumptickets complète (la solution de contournement commence autour de la ligne 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;
    });

J'espère que cela fonctionnera pour quelqu'un d'autre.....

La solution de Razarate a fonctionné comme un charme pour moi - avec une petite modification. Je pense que razarate a oublié d'inclure la partie essentielle suivante de la fonction de dumptickets révisée :

 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
        );

Salut, y a-t-il des nouvelles sur quand cela sera corrigé dans la v1.10.1 ?

1.10.1 est déjà sorti... donc il ne sera pas corrigé dans 1.10.1.
J'imagine qu'il sera probablement corrigé dans la version 1.11 lors de sa sortie.

Bonjour,
@ntozier il y a je peux trouver class.export.php avec des modifications?
Merci beaucoup!

@elma1003 hein ?

J'ai patché la 1.10 en commentant
//->options(QuerySet::OPT_NOCACHE)
L'exportation fonctionnait bien après cela

Maintenant, j'ai installé la v1.10.1 (9ae093d)
L'exportation n'est pas ok, seulement 3 lignes.
J'essaye de pach et ça ne va pas, rien ne fonctionne
J'ai téléchargé 1.10.2 depuis https://github.com/osTicket/osTicket/releases/tag/v1.10.2
mais class.export.php est le même qu'en 1.10
S'il vous plait aidez....

@ elma1003 Avez-vous essayé d'utiliser la solution de Razarate ?

@elma1003 @kclubok

Un correctif pour cela est inclus dans la prochaine version de v1.11.0rc-1 (sortie prochainement).

@elma1003

Idk ce qui se passe avec votre instance car je viens de commenter cette ligne sur mon instance v1.10.1 et elle exporte correctement tous les tickets.

À votre santé.

Est-ce que quelqu'un a réussi à faire fonctionner l'exportation, y compris les champs personnalisés ? Je n'arrive pas à comprendre.

J'ai essayé la solution de razarate, y compris les commentaires de kclubok, et j'ai essayé la

Peut-être qu'une âme charitable qui a réussi pourrait poster le fichier class.export.php modifié ici ?

Ce correctif fonctionnait pour moi. Du coup, ça ne marche plus. Vous ne savez pas ce qui s'est passé ?

@JediKev

Pourriez-vous nous indiquer le commit pour la v.11.0rc-1 qui corrige ce problème ? Ce serait bien utile !

J'espère que le correctif ne consiste pas simplement à commenter cette ligne. Comme mentionné précédemment, cela ne produit pas le comportement correct s'il existe des champs de liste personnalisés.

Toujours avec ce problème en utilisant le fichier class.export.php situé par evertvh.

J'ai essayé divers correctifs répertoriés sur ce problème, mais aucune joie.

J'ai un format csv modifié avec une colonne supplémentaire ajoutée pour montrer "l'organisation" à laquelle appartient chaque utilisateur, comme détaillé sur le forum osticket - http://osticket.com/forum/discussion/92606/customising-ticket-csv- export-correct#latest

@Zixt

Merci, mais nous avons en fait résolu ces problèmes dans v1.11.0rc-1 (sortie _très_ bientôt ; j'espère d'ici lundi). En plus de résoudre le problème d'origine, il ajoute la possibilité de personnaliser les champs que vous souhaitez exporter.

À votre santé.

EdiJediKev

Ah d'accord - gentil.

À votre santé.

Salut @JediKev

J'ai mis à jour la dernière version de notre installation, mais j'ai du mal à personnaliser la file d'attente en fonction de mes spécifications ?

Désolé si ce n'est pas le bon endroit pour demander!

J'ai réussi à ajouter correctement "Organisation" à la page File d'attente à l'aide d'un champ personnalisé avec la source de données principale définie sur "Utilisateur / Organisation / Nom"

Cependant, je n'ai pas la possibilité d'ajouter un champ personnalisé à l'onglet Exporter et je ne peux choisir qu'à partir d'un ensemble d'en-têtes de champs prédéfinis.

Y a-t-il quelque chose qui me manque ?

@Zixt

Ce n'est pas l'endroit pour signaler votre problème. Vous ouvrez votre propre problème et remplissez le modèle de nouveau problème. Cela étant dit, je vais poster ma réponse ci-dessous afin que vous ayez au moins une réponse rapide. ??

_ Clause de non-responsabilité : ce qui suit s'applique uniquement à v1.11.0rc-1 _

Actuellement, vous ne pouvez pas ajouter de champs d'utilisateur, de champs d'organisation, etc. aux exportations de file d'attente personnalisées car cette fonctionnalité n'est qu'en phase 1 (ou version 1) et est limitée. Je crois qu'il sera de plus en plus étendu au fil du temps pour permettre toutes sortes de domaines. Vous pouvez voir tous les champs que vous pouvez ajouter/réorganiser maintenant sous Panneau d'administration > Paramètres > Tickets > Files d'attente > cliquez sur le nom de la file d'attente > Exporter > Ajouter un autre champ .

_(Je suis désolé de vous avoir mal répondu précédemment ; je pensais que le nouvel exportateur avait la possibilité d'ajouter ces types de champs, mais il s'avère que ce n'est pas le cas. Au moins, les exportations sont personnalisables maintenant !)_

** Note latérale

Vous pouvez toujours exporter le nom de l'organisation d'un utilisateur en accédant à Panneau de l'agent > Utilisateurs > Annuaire des utilisateurs et en cliquant sur Exporter en bas.


À votre santé.

même " 1.10 - L'exportation de la liste des tickets ne sort que deux premières lignes" dans 1.10.4 après la mise à jour de 1.10.1

c'est peut-être à ce sujet :
[SÉLECTIONNER 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 COMME number , A4. subject COMME cdata__subject , A6. address AS user__default_email__address , A1. source COMME source , A7. priority_color COMME cdata__:priority__priority_color , A7. priority_desc AS cdata__:priority__priority_desc , A1. status_id COMME status_id , A8. name COMME status__name , A8. state AS status__state , A1. dept_id AS dept_id , B0. name COMME 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 PARTIR DE ost_thread Q7 REJOIGNEZ ost_ticket Q8 ON (Q7. object_type = 'T' ET Q7. object_id = Q8. ticket_id ) LEFT JOIN ost_thread_collaborator R0 ON (Q7. id = R0. thread_id ) O Q8. ticket_id = A1. ticket_id ) AS collab_count, (SELECT COUNT(R1. id ) AS count PARTIR DE ost_thread Q7 INSCRIPTION ost_ticket Q8 ON (Q7. object_type = 'T' ET 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' ET R0. id = R1. object_id ) O Q8. ticket_id = A1. ticket_id ET 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' ET Q7. object_id = Q8. ticket_id ) JOINTURE À GAUCHE ost_thread_entry R0 ON (Q7. id = R0. thread_id ) O Q8. ticket_id = A1. ticket_id ET PAS R0. flags & 4 != 0) AS thread_count FROM ost_ticket A1 JOIN (SÉLECTIONNEZ Q7. ticket_id DE ost_ticket Q7 REJOIGNEZ ost_ticket_status Q8 ON (Q7. status_id = Q8. id ) O Q8. state state = 'ouvert' ET (Q7. staff_id = 2 OU Q7. team_id EN (1))) OU Q7. dept_id IN ('1', '2', '3')) ORDRE PAR 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]

Colonne inconnue 'Q7.' dans 'clause de commande'



---- Retour arrière ----

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

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

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

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

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

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

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

7 (racine)/include/class.orm.php(1463) : CallbackSimpleIterator->valid()

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

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

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

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

12 {principal}

Exportation v1.11.0-rc1 avec en-tête uniquement.

1.10 mis à niveau vers 1.11rc1

l'exportation du tableau de bord fonctionne, l'exportation des tickets : impossible de trouver le fichier sur http://xxxxxxxx.xxxxxxx.com/helpdesk/scp/tickets.php?a=export&queue=adhoc ,ikDr5jdnAc.

1.10.4 a déjà ces lignes, même problème - juste deux lignes dans l'en-tête csv et un ticket

osVersion Ticket | v1.10.4
Version PHP | 5.6.37

Revoyez vos recommandations mais je continue avec le même problème, lors de l'export du rapport des tickets avec le statut "fermé", le fichier ne m'affiche qu'1 ticket.

Fonctionnait en 1.10.1
vrai bloqueur
Je sais que tout le monde est sur 1.11 mais à moins que 1.11 stable ne sorte le mois prochain, donnez-nous l'indice pour réparer celui-ci

@lavdnone Le correctif publié par @JediKev dans ce fil fonctionne pour moi à la fois dans 1.10.0 et 1.10.4.
https://github.com/osTicket/osTicket/issues/3264#issuecomment -330262555

Merci, je ne sais pas comment je l'ai raté, #3264 a fonctionné

@lavdnone très bienvenu. Bonne fin de journée ! :)

J'ai aussi le problème que tous les billets ne sont pas affichés.
l'utilisation des solutions ci-dessus dans le fichier ne fonctionne pas pour moi. Lors de l'utilisation, j'obtiens toujours une erreur php

Quelqu'un peut-il poster un fichier class.export.php complet et fonctionnel ?

@Orkanson

Vous commentez cette ligne et cela vous donne une erreur php ? On dirait que tu l'as mal fait. Tout ce que vous avez à faire est de commenter une ligne et cela fonctionne.
#3264 (commentaire)

À votre santé.

J'ai commenté la ligne 58 dans _include/class.export.php_, comme recommandé sur ce fil, et je peux maintenant exporter tous les tickets au format .csv.
//->options(QuerySet::OPT_NOCACHE)

OSTicket v1.10.4 sur Ubuntu 16

J'ai commenté la ligne 58 dans _include/class.export.php_, comme recommandé sur ce fil,
et je peux maintenant exporter tous les tickets au format .csv.
//->options(QuerySet::OPT_NOCACHE)

Oui,
cela semble aussi fonctionner dans mon fichier qu'une partie du code est une ligne 63 mais mange la mémoire... Je peux exporter des petites listes de tickets, mais si je prends une liste avec des centaines de milliers de tickets ça se termine inévitablement par une erreur :-(

_PHP Erreur fatale : taille de mémoire autorisée de 536870912 octets épuisée (tentative d'allouer 32 octets) dans include/class.orm.php à la ligne 3146_

J'ai changé les limites jusqu'à 512 Mo, mais j'ai arrêté et j'ai restauré l'ancienne limite, pour éviter des problèmes plus critiques.

NB : j'ai aussi essayé l'autre correctif posté par @JediKev mais dans tous les cas cela demande trop de ram si la liste est

73s,
Arturo.

@iw0der

Nous avons bientôt un correctif pour la série 1.12.x qui corrige les délais d'exportation des tickets pour les grands ensembles de données. S'il vous plaît restez à l'écoute.

À votre santé.