thuc960,
Was ich getan habe, war, diesen Rückruf in der Datei class.export.php über Zeile 85 in der Funktion Funktion dumpTickets($sql, $how='csv') zu ändern :

_return self::dumpQuery($tickets,
Array (
'Nummer' => __('Ticketnummer'),
'erstellt' => ('Erstellungsdatum'),'cdata.Betreff' => __('Betreff'),'Benutzername' => __('Von'),'user.default_email.address' => __('Von E-Mail'),'cdata.:priority.priority_desc' => __('Priorität'),'dept::getLocalName' => __('Abteilung'),'topic::getName' => __('Hilfethema'),'Quelle' => __('Quelle'),'status::getName' => ('Aktueller Status'),
'lastupdate' => __('Letzte Aktualisierung'),
'est_duedate' => __('Fälligkeitsdatum'),
'überfällig' => __('Überfällig'),
'beantwortet' => __('Beantwortet'),
'staff::getName' => __('Agent zugewiesen'),
'team::getName' => __('Team zugewiesen'),
'thread_count' => __('Thread-Anzahl'),
'attachment_count' => __('Anhanganzahl'),
) + $cdata,
$wie,
array('modify' => function(&$record, $keys) use ($fields) {
foreach ($fields als $k=>$f) {
if (($i = array_search($k, $keys)) !== false) {
$record[$i] = $f->export($f->to_php($record[$i]));
}
}
echo $record
$record zurückgeben;
})
);_

Damit (den letzten Parameter nach $how entfernen):

_return self::dumpQuery($tickets,
Array (
'Nummer' => __('Ticketnummer'),
'erstellt' => ('Erstellungsdatum'),'cdata.Betreff' => __('Betreff'),'Benutzername' => __('Von'),'user.default_email.address' => __('Von E-Mail'),'cdata.:priority.priority_desc' => __('Priorität'),'dept::getLocalName' => __('Abteilung'),'topic::getName' => __('Hilfethema'),'Quelle' => __('Quelle'),'status::getName' => ('Aktueller Status'),
'lastupdate' => __('Letzte Aktualisierung'),
'est_duedate' => __('Fälligkeitsdatum'),
'überfällig' => __('Überfällig'),
'beantwortet' => __('Beantwortet'),
'staff::getName' => __('Agent zugewiesen'),
'team::getName' => __('Team zugewiesen'),
'thread_count' => __('Thread-Anzahl'),
'attachment_count' => __('Anhanganzahl'),
) + $cdata,
$wie,
Null
);_

ABER, nicht sicher, warum das funktioniert ;-)
Grüße.

Ich habe die gleichen Probleme. Es sind nur 2 Tickets im Export.
War schon in RC3 und RC2 und jetzt im Stall?!

@JediKev @protich
Ich habe diesen Bericht gerade auf meinem Testserver v1.10 (901e5ea) bestätigt.

Ich habe den obigen Fix ausprobiert und er exportiert mehr, führt jedoch immer noch zu einem PHP-Fehler im Protokoll:
[04-Nov-2016 14:49:25 UTC] PHP-Warnung: mysqli_result::free(): Konnte mysqli_result in \support.110\include\mysqli.php in Zeile 185 nicht abrufen

Ich vermute, dass @greezybacon hier

Ich habe die Datei mit den Empfehlungen von

Habe das gleiche Problem bei der endgültigen Version 1.10. Der vorgeschlagene Patch scheint das Problem zu beheben.

Gleiches Problem, danke @rayfoss

Ich habe den obigen Fix versucht, führt aber immer noch zu einem PHP-Fehler im Protokoll:
PHP-Warnung: mysqli_result::free(): mysqli_result konnte in \ nicht abgerufen werden\include\mysqli.php auf Zeile 185

Ich habe den Aufruf der Funktion free() (mysqli.php in Zeile 185) zu einer kommentierten Zeile gemacht und der Export funktioniert.

+1 Ich habe das gleiche Problem.

@HansLe - Kannst du das klären? Hast du das Problem gelöst? Wie und wo hast du die Funktion free() aufgerufen?

@tdefreest , mein Problem wurde gelöst. Ich kommentierte diese Zeile (Nummer 185):
// $__db->unbuffered_result->free();
im Modul include\mssqli.php

Das Problem wurde für mich @sistemasad gelöst.

3813

Das Kommentieren der Zeilen gemäß der Lösung von

Ich habe das gleiche Problem wie @demenna. Benutzerdefinierte Felder werden jetzt als Zahlen exportiert.

bei mir auch.Custom fields now export as numbers.

Der von @sistemasad auskommentierte Code ist für die Konvertierung von Rohdaten in formatierte Daten verantwortlich. Es scheint, dass der Fehler durch einen Fehler irgendwo in diesem Code ausgelöst wird. Das Auskommentieren dieses Codes verhindert den Fehler, deaktiviert aber auch die Formatierungslogik - deshalb werden benutzerdefinierte Felder als Zahlen exportiert.

Mein Verständnis des Zusatzes von

Was wir noch brauchen, ist eine echte Korrektur, die die Formatierungslogik beibehält.

Der Export hat gut funktioniert und jedes Ticket exportiert. Nachdem wir die Formularticketdetails geändert haben, um einige benutzerdefinierte Felder aus der Verwendung von Basisfeldern zu benutzerdefinierten Listen hinzuzufügen, da keine Daten im Export vorhanden sind, haben wir jetzt die Daten im benutzerdefinierten Feld, erhalten aber nur die ersten 2 Zeilen im Export. Bisher haben wir keinen Erfolg damit gehabt, unsere Änderungen rückgängig zu machen. Es passiert sicherlich etwas, das eine ordnungsgemäße Lösung erfordert, und ich stimme zu, dass das oben Gesagte keine Lösung ist und eine ordnungsgemäße Lösung erfordert.

HI allerseits, sorry ein bisschen verloren mit mehreren Tickets, also was ist die Lösung?

Es gibt noch keine vollständige Lösung, zumindest nicht, wenn benutzerdefinierte Felder korrekt exportiert werden sollen. Wenn Sie damit einverstanden sind, dass sie nicht richtig exportiert werden, weist Sie der Kommentar vom 26. Oktober in die richtige Richtung.

Ich bin mir nicht sicher, ob dies hilft, aber ich habe das gleiche Problem und es scheint vollständig durch den Code verursacht zu werden, der die benutzerdefinierten Spalten um 54 in der Datei class.export.php aufruft. Auch keine der anderen Lösungen in diesem Thread hat funktioniert, sie stoppen nur das Laden der gesamten Seite (für mich).

// Benutzerdefinierte Felder zur $sql-Anweisung hinzufügen
$cdata = $fields = array();
foreach (TicketForm::getInstance()->getFields() als $f) {
// Kernfelder ignorieren
if (in_array($f->get('name'), array('priority')))
fortsetzen;
// Nicht-Datenfelder ignorieren
elseif (!$f->hasData() || $f->isPresentationOnly())
fortsetzen;

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

Wenn der letzte Abschnitt dieses Codes auskommentiert ist, funktioniert der Export wie gewünscht, lässt jedoch alle benutzerdefinierten Felder aus. Ich habe versucht, den Code ohne Erfolg zu ändern, außer dass die Prioritätsspalte zweimal aufgerufen wird (anstelle der benutzerdefinierten Feldspalte).

Vielleicht helfen diese Informationen, etwas für jemanden mit mehr Erfahrung zu finden. Wenn mir jemand Feedback/Anregungen geben kann, bitte zögern Sie nicht.

Diese Hilfe sammelt alle Experten, aber ohne die benutzerdefinierten Felder ist es nicht gut :(

@protich @JediKev
Gibt es eine Chance, dass das untersucht werden könnte? Beim Export werden die benutzerdefinierten Felddaten immer noch nicht korrekt abgerufen. Ursprünglich nach dem Upgrade von v 1.9 auf v 1.10 aufgetreten: Der Export von Tickets in csv stoppt, nachdem nur zwei Elemente exportiert wurden (die Datei wird jedoch immer noch erstellt). Der Fix in diesem Thread verhindert, dass die benutzerdefinierten Felder ausgeführt werden, um das Schlüssel-Wert-Paar abzurufen, was zu manueller Arbeit beim Verbinden der Informationen führt. Dies ist auch bei der neuesten Version 1.10.1 der Fall. Jede Hilfe wird geschätzt.

Hallo.

Das gleiche Problem habe ich auch hier:
osTicket-Version | v1.10.1 (9ae093d) — Aktuell
Webserver-Software | Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.4.16
MySQL-Version | 5.5.52
PHP-Version | 5.4.16

Wir haben eine benutzerdefinierte Liste, wenn wir nach Tickets mit einem der benutzerdefinierten Listenwerte suchen, werden alle korrekt in der CSV ausgegeben. Wenn wir jedoch in dieser benutzerdefinierten Liste nicht nach etwas suchen, werden nur zwei Zeilen im ausgegeben CSV-Datei.

Der Fix zum Entfernen des benutzerdefinierten Felds führt dazu, dass alle Zeilen ausgegeben werden, aber die benutzerdefinierte Liste muss in die CSV-Datei aufgenommen werden.

Ich habe versucht herauszufinden, was los ist, aber ich konnte keine Lösung dafür finden, daher würde ich mich über weitere Vorschläge freuen.

James.

Wir prüfen dieses Problem noch. Bis wir das Problem dauerhaft beheben, können Sie Zeile 63 in include/class.export.php :

->options(QuerySet::OPT_NOCACHE)

...und Sie sollten alle wieder exportieren.

Hallo.

Danke für diese Lösung, sie zeigt jetzt alle Tickets an, bedeutet aber, dass nur das erste Listenelement in einem benutzerdefinierten Listenfeld angezeigt wird, alle anderen jedoch nicht, also wenn es in der benutzerdefinierten Liste für 'Apfel' und 'Birne' stehen sollte Dieses Ticket zeigt Ihnen nur "Apfel".

James.

Nun, wir brauchten dies behoben, also machen Sie einen Workaround ... vielleicht ist es nicht so sauber, wie wir es mögen, aber es funktioniert.

Dies ist die vollständige Dumptickets-Funktion (Workaround beginnt um Zeile 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;
    });

Ich hoffe das funktioniert bei jemand anderem.....

Die Lösung von Razarate hat für mich wie ein Zauber funktioniert - mit einer kleinen Modifikation. Ich denke, dass Razarate vergessen hat, den folgenden wesentlichen Teil der überarbeiteten Dumptickets-Funktion aufzunehmen:

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

Hallo, gibt es Neuigkeiten, wann dies in v1.10.1 behoben wird?

1.10.1 ist bereits draußen... also wird es in 1.10.1 nicht behoben.
Ich kann mir vorstellen, dass es wahrscheinlich in 1.11 behoben wird, wenn es veröffentlicht wird.

Hallo,
@ntozier gibt es die class.export.php mit Modifikationen?
Vielen Dank!

@elma1003 oder ?

Ich habe 1.10 gepatcht, indem ich kommentiert habe
//->Optionen(QuerySet::OPT_NOCACHE)
Der Export funktionierte danach einwandfrei

Jetzt habe ich v1.10.1 (9ae093d) installiert
Export ist nicht ok, nur 3 Zeilen.
Ich versuche zu pachen und es ist nicht in Ordnung, nichts funktioniert
Ich habe 1.10.2 von https://github.com/osTicket/osTicket/releases/tag/v1.10.2 heruntergeladen
aber class.export.php ist die gleiche wie in 1.10
Bitte helft....

@elma1003 Haben Sie versucht, die Lösung von Razarate zu verwenden?

@elma1003 @kclubok

Ein Fix dafür ist in der kommenden Version von v1.11.0rc-1 (bald veröffentlicht) enthalten.

@elma1003

Finden Sie heraus, was mit Ihrer Instanz passiert, da ich gerade diese Zeile in meiner v1.10.1-Instanz auskommentiert habe und alle Tickets ordnungsgemäß exportiert werden.

Danke schön.

Hat jemand den Export - einschließlich benutzerdefinierter Felder - zum Laufen gebracht? Ich kann es anscheinend nicht herausfinden.

Ich habe die Lösung von razarate einschließlich des Feedbacks von kclubok ausprobiert und die Version 1.11.x der Datei class.export.php ausprobiert, aber sie enthält keine benutzerdefinierten Felder.

Vielleicht könnte eine nette Seele, die es geschafft hat, die modifizierte Datei class.export.php hier posten?

Bei mir hat dieser Fix früher funktioniert. Plötzlich funktioniert es nicht mehr. Nicht sicher, was passiert ist?

@JediKev

Könnten Sie uns auf den Commit für v.11.0rc-1 hinweisen, der dies behebt? Es wäre sehr hilfreich!

Ich hoffe, dass der Fix diese Zeile nicht einfach auskommentiert. Wie bereits erwähnt, führt dies nicht zum richtigen Verhalten, wenn benutzerdefinierte Listenfelder vorhanden sind.

Dieses Problem tritt immer noch auf, wenn die Datei class.export.php von evertvh verwendet wird.

Ich habe verschiedene Fixes ausprobiert, die zu diesem Problem aufgeführt sind, aber keine Freude.

Ich habe ein modifiziertes CSV-Format mit einer zusätzlichen Spalte hinzugefügt, um die "Organisation" anzuzeigen, zu der jeder Benutzer gehört, wie im osticket-Forum beschrieben - http://osticket.com/forum/discussion/92606/customising-ticket-csv- export-korrekt#neuest

@Zixt

Vielen Dank, aber wir haben diese Probleme tatsächlich in v1.11.0rc-1 angesprochen (wird _sehr_ bald veröffentlicht; hoffentlich bis Montag). Neben der Behebung des ursprünglichen Problems bietet es die Möglichkeit, die zu exportierenden Felder anzupassen.

Danke schön.

EdiJediKev

Ah okay - nett.

Danke schön.

Hallo @JediKev

Ich habe auf die neueste Version unserer Installation aktualisiert, habe aber Probleme beim Anpassen der Warteschlange an meine Spezifikation?

Entschuldigung, wenn dies nicht der richtige Ort ist, um nachzufragen!

Ich habe es geschafft, "Organisation" korrekt zur Seite "Warteschlange" hinzuzufügen, indem ich ein benutzerdefiniertes Feld verwendet habe, bei dem die primäre Datenquelle auf "Benutzer / Organisation / Name" festgelegt ist.

Ich habe jedoch keine Möglichkeit, der Registerkarte Export ein benutzerdefiniertes Feld hinzuzufügen, und kann nur aus einer Reihe vordefinierter Feldüberschriften auswählen.

Fehlt mir etwas?

@Zixt

Dies ist nicht der richtige Ort, um Ihr Problem zu melden. Sie würden Ihre eigene Ausgabe eröffnen und die Vorlage für eine neue Ausgabe ausfüllen. Nachdem dies gesagt wurde, werde ich meine Antwort unten posten, damit Sie zumindest eine schnelle Antwort haben. 👍

_ Haftungsausschluss: Folgendes gilt nur für v1.11.0rc-1 _

Derzeit können Sie benutzerdefinierten Warteschlangen-Exporten keine Benutzerfelder, Organisationsfelder usw. hinzufügen, da sich diese Funktion nur in Phase 1 (oder Version 1) befindet und eingeschränkt ist. Ich _glaube_, dass es im Laufe der Zeit immer mehr erweitert wird, um alle möglichen Felder zu ermöglichen. Sie können alle Felder, die Sie jetzt hinzufügen/anordnen können, unter Admin-Panel > Einstellungen > Tickets > Warteschlangen > klicken Sie auf den Namen der Warteschlange > Exportieren > Anderes Feld hinzufügen .

_(Es tut mir leid, dass ich Ihnen zuvor falsch geantwortet habe. Ich dachte, der neue Exporter hätte die Möglichkeit, diese Arten von Feldern hinzuzufügen, aber es stellte sich heraus, dass dies nicht der Fall ist. Zumindest sind Exporte jetzt jedoch anpassbar!)_

** Randnotiz

Sie können den Organisationsnamen eines Benutzers jederzeit exportieren, indem Sie zu Agentenbereich > Benutzer > Benutzerverzeichnis gehen und unten auf Exportieren klicken.


Danke schön.

gleich " 1.10 - Ticketlistenexport gibt nur zwei erste Zeilen aus" in 1.10.4 nach Update von 1.10.1

das könnte daran liegen:
[WÄHLEN SIE 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 ALS status_id , A8. name ALS 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 VON ost_thread Q7 BEITRETEN ost_ticket Q8 ON (Q7. object_type = 'T' UND Q7. object_id = Q8. ticket_id ) LEFT JOIN ost_thread_collaborator R0 ON (Q7. id = R0. thread_id ) WO Q8. ticket_id = A1. ticket_id ) AS collab_count, (SELECT COUNT(R1. id ) AS count VON ost_thread Q7 JOIN ost_ticket Q8 ON (Q7. object_type = 'T' UND Q7. object_id = Q8. ticket_id ) LEFT JOIN ost_thread_entry R0 EIN (Q7. id = R0. thread_id ) LEFT JOIN ost_attachment R1 EIN (R1. type = 'H' UND R0. id = R1. object_id ) WO Q8. ticket_id = A1. ticket_id UND 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' UND Q7. object_id = Q8. ticket_id ) LEFT JOIN ost_thread_entry R0 EIN (Q7. id = R0. thread_id ) WO Q8. ticket_id = A1. ticket_id UND NICHT R0. flags & 4 != 0) AS thread_count FROM ost_ticket A1 JOIN (SELECT Q7. ticket_id VON ost_ticket Q7 JOIN ost_ticket_status Q8 ON (Q7. status_id = Q8. id ) WO Q8. state state = 'offen' UND (Q7. staff_id = 2 ODER Q7. team_id IN (1))) ODER Q7. dept_id IN ('1', '2', '3')) BESTELLEN VON 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]

Unbekannte Spalte 'Q7'. in 'Orderklausel'



---- Rückverfolgung ----

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 (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->{close}()

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->valid()

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 {Haupt}

v1.11.0-rc1-Export nur mit Header.

1.10 aktualisiert auf 1.11rc1

Dashboard-Export funktioniert, Ticket-Export: kann die Datei unter http://xxxxxxxx.xxxxxxx.com/helpdesk/scp/tickets.php?a=export&queue=adhoc ,ikDr5jdnAc nicht finden.

1.10.4 hat diese Zeilen bereits, gleiches Problem - nur zwei Zeilen im CSV-Header und ein Ticket

osTicket-Version | v1.10.4
PHP-Version | 5.6.37

Überprüfen Sie Ihre Empfehlungen, aber ich fahre mit dem gleichen Problem fort. Beim Exportieren des Berichts von Tickets mit dem Status "geschlossen" zeigt mir die Datei nur 1 Ticket an.

Hat in 1.10.1 gearbeitet
echter blocker
Ich weiß, dass alle auf 1.11 sind, aber wenn nicht nächsten Monat 1.11 stable herauskommt, geben Sie uns den Hinweis, dieses Problem zu beheben

@lavdnone Der von @JediKev in diesem Thread gepostete
https://github.com/osTicket/osTicket/issues/3264#issuecomment -330262555

Danke, weiß nicht wie ich es verpasst habe, #3264 hat funktioniert

@lavdnone sehr willkommen. Habt einen schönen Rest des Tages! :)

Ich habe auch das Problem, dass nicht alle Tickets angezeigt werden.
die Verwendung der obigen Lösungen in der Datei funktioniert bei mir nicht. Bei der Verwendung erhalte ich immer einen PHP-Fehler

Kann jemand bitte eine funktionierende komplette class.export.php posten?

@Orkanson

Kommentieren Sie diese eine Zeile aus und Sie erhalten einen PHP-Fehler? Klingt, als hättest du es falsch gemacht. Alles, was Sie tun müssen, ist eine Zeile auskommentieren und es funktioniert.
#3264 (Kommentar)

Danke schön.

Ich habe Zeile 58 in _include/class.export.php_ auskommentiert, wie in diesem Thread empfohlen, und kann jetzt alle Tickets in das .csv-Format exportieren.
//->options(QuerySet::OPT_NOCACHE)

OSTicket v1.10.4 auf Ubuntu 16

Ich habe Zeile 58 in _include/class.export.php_ auskommentiert, wie in diesem Thread empfohlen,
und ich kann jetzt alle Tickets in das .csv-Format exportieren.
//->options(QuerySet::OPT_NOCACHE)

Jawohl,
es scheint auch in meiner Datei zu funktionieren, dass ein Teil des Codes eine Zeile 63 ist, aber den Speicher frisst... Ich kann kleine Listen von Tickets exportieren, aber wenn ich eine Liste mit Hunderttausenden von Tickets nehme, endet es unweigerlich mit einem Fehler :-(

_PHP Fatal error: Zulässige Speichergröße von 536870912 Bytes erschöpft (versucht, 32 Bytes zuzuweisen) in include/class.orm.php in Zeile 3146_

Ich habe die Grenzen auf 512 MB geändert, aber ich habe aufgehört und die alte Grenze wiederhergestellt, um einige kritische Probleme zu vermeiden.

NB: Ich habe auch den anderen Fix ausprobiert, der von @JediKev gepostet wurde, aber auf jeden Fall erfordert es zu viel RAM, wenn die Liste groß ist.

73er,
Arturo.

@iw0der

Wir haben in Kürze einen Fix für die 1.12.x Serie, der Zeitüberschreitungen beim Ticketexport für große Datasets behebt. Bitte bleiben Sie dran.

Danke schön.