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.
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 \
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.
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!)_
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 ----
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.
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
:...and you should get all of them exported again.