Dear all,
We have an OsTicket v1.10.4 (035fd0a) installation with Apache/2.4.7 (Ubuntu), MySQL Version 5.5.62 and PHP Version 5.6.39-1+ubuntu14.04.1+deb.sury.org+1 that always had 0s in Statistics table, while at the same time proper numbers are shown in the Ticket Activity Diagram!

This is the System information page:

and the screenshot of the Statistics table showing the problem (Topics and Agent tabs also have 0s only):

Time and Date formats are as follows:

FYI, this server has been upgraded several times (from 1.9.4-6-12-15 and then to 1.10.x versions), so I fear (if nothing more obvious comes to mind) that /maybe/ I missed a DB upgrade in the meantime (or was not applied properly) or that a time/date/locale setting messes things up?
Also, I should note that i get no PHP errors when accessing the statistics page and that all date-related queries in advanced ticket search page, show the proper results.

I know that the statistics component is old, and may not be very accurate (and also that it will be revamped in newer versions). What I fear the most is that the 0s might not be an issue of the reports code (class.report.php is verified to be the current version) but an issue of the DB, or something that has to do with time/date formatting, and hence, it will remain even in the new version.

Any ideas would be welcome!

ps. I also read the forum about other issues in Service and Respond time of the reports page. I applied as a test the patch from the #3738 pull request in GitHub and numbers in Service and Respond time changed from 0s to actual numbers! (all the other columns kept showing 0s). Then I reverted the patch because it is of minor importance to us (and because it has no value if the general problem with 0s is not solved first)

I imagine that it is either a problem with the dashboard not reading departments correctly because of the language pack, or the fact that the Dashboard has always been meh when it comes to statistics.

Personally I do not have the same problem in my installation but I am not using a language pack and am running under IIS. I have a second site running under Apache (CentOS) & php7 and it also works. Again no language pack installed. If you change the default language [to English] do the number populate?

Out of curiosity are you running cron.php on a schedule?

    @bujam1

    The dashboard statistics have been revamped and fixed in 1.11-rc1. You can either wait for the stable release or you can try a test upgrade to see how it goes with the release candidate. If you do a test upgrade use the latest pull from 1.11.x or develop-next from GitHub as these include the latest bug fixes for the 1.11.x series. (Don’t forget to backup database and site files just in case.)

    Cheers.

      Thank you both for your time!

      ntozier What puzzles me is that I have not seen a single user reporting this kind of behavior (although many complain about statistics being 'meh' as you say).
      I have changed the default locale and default language to 'English' and still get 0s...
      I am a bit unwilling to remove the language pack because I'm using multilingual forms in production and this will probably(?) mess things up!
      Also, no I'm not running cron.php in a crontab. I'm using "Fetch Emails using Auto-cron" (with 1min refresh period for all the agents)

      KevinTheJedi I've read about the revamp of the statistics page, but I'm almost certain that even with the new code, I'll be getting 0s. It's true that a test upgrade (in a dummy system) will solve all my questions (I'm not upgrading the production system before 1.11.1+ is released!). I'll give it a try and update the thread.

      (In the meantime, if anyone has another idea/suggestion, I'll be happy to test it and see if it fixes things)

      If your fetching emails you should really setup and run cron.php. "Fetch Emails using Auto-cron" only triggers on staff activity so if no staff are logged in then it will not fetch emails. If you have a bunch of agents and they are logged in 24/7 and actually doing things in osTicket then you probably dont have to worry about it, but again emails wouldn't be fetched on holidays when your "closed".

      I think that Kevin was suggesting that you clone your site, and upgrade the clone so as to not affect your production site. That would at least tell you if the new version [when released] will fix your issue.

      18 days later

      Hooray! Indeed upgrading a copy of my instance to the latest 1.11.x branch and running the upgrade scripts fixed the 0s in the Statistics table.
      So all I have to do is wait for the official 1.11 release, cross my fingers and upgrade the production system.

      Thank you both for your time.

      Write a Reply...