Osticket: 1.10 - Ticket list export outputs only two first lines

Created on 11 Jul 2016  ·  60Comments  ·  Source: osTicket/osTicket

When you click "export" on any ticket list (opened, closed, owned, searched), the CSV generated includes only the first TWO lines.
This also affects to any the result of a search.

The apache logs shows this:
PHP Warning: mysqli_result::close(): Couldn't fetch mysqli_result in /site_1.10.rc3/include/class.orm.php on line 3076, referer: http://------------------/scp/tickets.php

osTicket 1.10.rc3
Centos 6.8 64b
mysql 5.1
php 5.6

Thank you.

Most helpful comment

We are still looking into this issue. Until we fix it permanently, you can comment out line 63 in include/class.export.php:

->options(QuerySet::OPT_NOCACHE)

...and you should get all of them exported again.

All 60 comments

by "includes only the first two lines" @sistemasad actually means the first three (3).
Seeing same behavior on my test installations.

1.10rc3
Win2012 R2 w/ IIS8.5
PHP 5.6

Hi, I also confirms the same issue.

osTicket 1.10.rc3
Centos 6.8 64b
mysql 5.5.50-cll, libmysql - 5.1.73
php 5.6

Hi,
I've spent a few minutes on this.
On class.export.php file, function dumpTickets, the last instruccion is the return calling self::dumpQuery function.
The last parameter dumpQuery accepts is "$options=array". If you set this to null, tickets are exported correctly. (the other three params are sql,headers and "csv")

It seems the problem is in the options generated by this lines (the fourth param):

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
return $record;

Please help me, my problem is same

Warning: mysqli_result::close(): Couldn't fetch mysqli_result in ................/include/class.orm.php on line 3089

Warning: mysqli_result::close(): Couldn't fetch mysqli_result in ................/include/class.orm.php on line 3089

thuc960,
what I did was change this return call on file class.export.php, about line 85 inside function function dumpTickets($sql, $how='csv'):

_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,
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
return $record;
})
);_

With this (remove the last param, after $how,):

_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,
null
);_

BUT, not sure why this Works ;-)
Regards.

I have the same issues. Only 2 tickets are in the export.
Was already in RC3 and RC2 and now in the stable?!

@JediKev @protich
I have just confirmed this report on my v1.10 (901e5ea) test server.

I tried the fix above, and it makes it export more, but still results in a PHP error in the log:
[04-Nov-2016 14:49:25 UTC] PHP Warning: mysqli_result::free(): Couldn't fetch mysqli_result in \support.110\include\mysqli.php on line 185

My guess is that this is where @greezybacon left off changing the source to access the DB from mysli and ORM.

I have patched the file using what @sistemasad recommends, and I am able to export reports, however it looks like by doing so my custom "location" drop-down field grabs the numeric representation sometimes, and sometimes the number (comma) location. Any ideas?

Having the same issue on 1.10 final release. Suggested patch seems to fix it.

Same problem, thanks @rayfoss

I tried the fix above but still results in a PHP error in the log:
PHP Warning: mysqli_result::free(): Couldn't fetch mysqli_result in \\include\mysqli.php on line 185

I made the call of the free() function (mysqli.php on line 185) a commented line and the export works.

+1 I am having same problem.

@HansLe - Can you clarify? Did you solve the problem? How and where did you make the call of the free() function?

@tdefreest, my problem was solved. I commented this line (number 185):
// $__db->unbuffered_result->free();
in module include\mssqli.php

Issue has been resolved for me as per @sistemasad recommendation.

3813

Commenting the lines as per @sistemasad 's solution re-enables the export but fails to correctly write the custom fields... they appear as numbers... has anyone found a better solution?

I'm having the same issue as @demenna. Custom fields now export as numbers.

bei mir auch.Custom fields now export as numbers.

The code commented out by @sistemasad is responsible for converting raw data into formatted data. It appears that the error is triggered by a bug somewhere in this code. So commenting out that code prevents the bug, but also disables the formatting logic - that is why custom fields export as numbers.

My understanding of @HansLe 's addition is that the first fix didn't prevent the problem entirely for everybody, and this was needed in addition. I have not seen that behavior myself.

What we still need is a true fix that preserves the formatting logic.

Export was working fine and exported every ticket then after modifying form ticket details to add some custom fields from using Basic Fields to Custom Lists due to no data populating in the export, we now have the data in the custom field but only get the first 2 lines in export. Thus far we have not found success backing out our changes. There is certainly something going on that needs a proper resolution and I agree the above is not a resolution and needs a proper resolution.

HI everyone, sorry a bit lost with multiple tickets, so whats the solution?

There is no complete solution as of yet, at least not if you want custom fields to export correctly. If you're OK with them not exporting correctly, then the comment on October 26 will point you in the right direction.

Not sure if this helps but i'm having the same issue and it seems to be caused entirely by the code calling the custom columns around 54 in the class.export.php file. Also none of the other solutions in this thread have worked, they just stop the entire page from loading (for me).

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

If the last section of this code is commented out the export works the way it should but leaves out any custom fields. I've tried changing the code with absolutely no success other than getting the priority column to be called twice (in place of where the custom field column should be).

Maybe this information will help pin point something for someone more experienced. If anyone can give me any feedback/suggestions please feel free.

This help collects all the experts but without the custom fields, it not good :(

@protich @JediKev
Any chance this could be looked into? Export still isn't fetching custom field data correctly. Occurred after upgrade from v 1.9 to v 1.10 originally: export of tickets to csv stops after exporting only two items (file is still created though). The fix in this thread prevents the custom fields from running to fetch the key-value pair causing some manual labor connecting the information up. This is occurring on most recent v 1.10.1 release as well. Any help is appreciated.

Hello.

I'm having the same issue here too:
osTicket Version | v1.10.1 (9ae093d) —  Up to date
Web Server 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

We have a custom list, when we make a search for tickets with one of the custom lists values they all ouptut in the CSV correctly, however, if we don't search for something in this custom list then only two rows are outputed in the CSV.

The fix to remove the custom field results in all rows being output but we require the custom list to be included in the CSV.

I've tried to work out what's going on but I've been unable to find a fix for it, so I'd appreciate any more suggestions.

James.

We are still looking into this issue. Until we fix it permanently, you can comment out line 63 in include/class.export.php:

->options(QuerySet::OPT_NOCACHE)

...and you should get all of them exported again.

Hello.

Thanks for this solution, it now shows all tickets, but means that the only the first list item in a custom list field displays, but any others do not, so if it should have 'apple' and 'pear' in the custom list for that ticket it'll only show you 'apple'.

James.

Well we needed this fixed so make a workaround ... maybe is not as clean as we like it but it works.

This is the full dumptickets function (workaround starts around line 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;
    });

I hope this works for someone else .....

Razarate's solution worked like a charm for me - with a small modification. I think that razarate forgot to include the following essential part of the revised dumptickets function:

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

Hi, is there any news on when this will be fixed in v1.10.1?

1.10.1 is already out... so it wont e fixed in 1.10.1.
I imagine that it will likely be fixed in 1.11 when it is released.

Hello,
@ntozier there are I can find class.export.php with modifications?
Many thanks!

@elma1003 huh?

I've patched 1.10 by commenting
//->options(QuerySet::OPT_NOCACHE)
The export was working fine after this

Now I've installed v1.10.1 (9ae093d)
Export is not ok, only 3 lines.
I am trying to pach and it is not ok, nothing works
I've downloaded 1.10.2 from https://github.com/osTicket/osTicket/releases/tag/v1.10.2
but class.export.php is the same as in 1.10
Please help....

@elma1003 Have you tried using Razarate's solution?

@elma1003 @kclubok

A fix for this is included in the upcoming version of v1.11.0rc-1 (releasing soon).

@elma1003

Idk what's happening with your instance as I just commented out that line on my v1.10.1 instance an it's exporting all tickets properly.

Cheers.

Did anyone get the export - including custom fields - to work? I can't seem to figure it out.

I tried razarate's solution including kclubok's feedback, and tried the 1.11.x-version of the class.export.php file but it doesn't incluse the custom fields.

Perhaps a kind soul who did manage could post the modified class.export.php file here?

This fixed used to work for me. Suddenly, it is no longer working. Not sure what happened?

@JediKev

Could you point us toward the commit for v.11.0rc-1 that fixes this? It would be quite helpful!

I hope that the fix is not simply commenting out that line. As mentioned before, that doesn't produce the correct behavior if there are custom list fields.

Still having this issue using the class.export.php file located by evertvh.

I have tried various fixes listed on this issue but no joy.

I have a modified csv format with an additional column added to show the "organisation" that each user belongs to, as detailed on the osticket forum - http://osticket.com/forum/discussion/92606/customising-ticket-csv-export-correct#latest

@Zixt

Thank you but we have actually addressed these issues in v1.11.0rc-1 (releasing _very_ soon; hopefully by Monday). Along with addressing the original issue it adds the ability to customize what fields you want to export.

Cheers.

@JediKev

Ah okay - nice one.

Cheers.

Hi @JediKev

I've updated to the latest release on our installation, but I'm having some trouble customising the queue to my spec?

Apologies if this is not the correct place to ask!

I've managed to add "Organisation" to the Queue page correctly using a custom field with primary data source set to "User / Organisation / Name"

However - I have no option to add a custom field to the Export tab, and can only select from a set of predefined field headers.

Is there something I am missing?

@Zixt

This is not the place to report your issue. You would open your own issue and fill out the New Issue Template. With that being said, I will go ahead and post my response below so you at least have a quick answer. 👍

_Disclaimer: The following only applies to v1.11.0rc-1_

Currently, you cannot add User fields, Org fields, etc. to Custom Queue Exports as this feature is only in phase 1 (or version 1) and is limited. I _believe_ it will be expanded more and more over time to allow all kinds of fields. You can see all the fields you can add/rearrange now under Admin Panel > Settings > Tickets > Queues > click queue name > Export > Add Other Field.

_(I'm sorry I answered you wrong previously; I thought the new Exporter had the option to add those types of fields but it turns out it doesn't. At least Exports are customizable now though!)_

** Side Note

You can always export a User's Organization Name by going to Agent Panel > Users > User Directory and clicking Export at the bottom.


Cheers.

same " 1.10 - Ticket list export outputs only two first lines" in 1.10.4 after update from 1.10.1

this might be about it:
[SELECT 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 JOIN 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) WHERE 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' AND 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) WHERE 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' AND Q7.object_id = Q8.ticket_id) LEFT JOIN ost_thread_entry R0 ON (Q7.id = R0.thread_id) WHERE Q8.ticket_id = A1.ticket_id AND NOT R0.flags & 4 != 0) AS thread_count FROM ost_ticket A1 JOIN (SELECT Q7.ticket_id FROM ost_ticket Q7 JOIN ost_ticket_status Q8 ON (Q7.status_id = Q8.id) WHERE Q8.state = 'closed' AND ((Q8.state = 'open' AND (Q7.staff_id = 2 OR Q7.team_id IN (1))) OR Q7.dept_id IN ('1', '2', '3')) ORDER BY 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]

Unknown column 'Q7.' in 'order clause'



---- Backtrace ----

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

v1.11.0-rc1 export with header only.

1.10 upgraded to 1.11rc1

dashboard export works, ticket export: can’t find the file at http://xxxxxxxx.xxxxxxx.com/helpdesk/scp/tickets.php?a=export&queue=adhoc,ikDr5jdnAc.

1.10.4 already has this lines, same issue - just two lines in csv header and one ticket

osTicket Version | v1.10.4
PHP Version | 5.6.37

Review your recommendations however I continue with the same problem, when exporting the report of tickets with "closed" status, the file only shows me 1 ticket.

Was working in 1.10.1
real blocker
I know everyone is on 1.11 but unless 1.11 stable is coming out next month give us the clue to fix this one

@lavdnone The fix posted by @JediKev in this thread works for me for in both 1.10.0 and 1.10.4.
https://github.com/osTicket/osTicket/issues/3264#issuecomment-330262555

Thanks, don't know how I missed it, #3264 worked

@lavdnone very welcome. Have a great rest of your day! :)

I also have the problem that not all tickets are displayed.
the use of the above solutions in the file does not work for me. When using I always get php error

Can someone please post a working complete class.export.php?

@Orkanson

You comment-out that one line and it gives you a php error? Sounds like ya' did it wrong. All you have to do is comment-out one line and it works.
#3264 (comment)

Cheers.

I commented out line 58 in _include/class.export.php_, as recommended on this thread, and I may now export all tickets to .csv format.
//->options(QuerySet::OPT_NOCACHE)

OSTicket v1.10.4 on Ubuntu 16

I commented out line 58 in _include/class.export.php_, as recommended on this thread,
and I may now export all tickets to .csv format.
//->options(QuerySet::OPT_NOCACHE)

Yes,
it also seems to work in my file that part of the code is a line 63 but eats the memory... I can export small lists of tickets, but if I take a list with hundreds of thousands of tickets it inevitably ends with an error :-(

_PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 32 bytes) in include/class.orm.php on line 3146_

I changed the limits up to 512MB, but I stopped and I restored the old limit, to avoid some more critical problems.

NB: I also tried the other fix posted by @JediKev but in any case it requires too much ram if the list is large.

73s,
Arturo.

@iw0der

We have a fix for the 1.12.x series coming soon that addresses ticket export timeouts for large datasets. Please stay tuned.

Cheers.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

F3000 picture F3000  ·  5Comments

markus4000 picture markus4000  ·  3Comments

roman-1983 picture roman-1983  ·  5Comments

mlipok picture mlipok  ·  5Comments

ghost picture ghost  ·  6Comments