Topics

1

Older versions / FengOffice 1.6.1 Error 500: Internal Server Error

« on: January 07, 2010, 12:58:02 am »

After helping a user upgrade to FengOffice 1.6.1 from OpenGoo 1.5.3 the following error message was received after debugging was turned on in the config file:

Fatal error: Call to a member function getTimestamp() on a non-object in /usr/local/apache2/htdocs/pm/opengoo/application/helpers/calendar.php on line 105

This prevents the Overview tab from being displayed.

When clicking on the Calendar tab the following pop-up error is shown:

Error: og.eventSelected is not a function

Everything appears to be in good working order except the Calendar functions.  We can disable the calendar module and the Overview tab will display properly.

The function this error refers to is:

function forwardRepDate(ProjectTask $task, $min_date) {
   if ($task->isRepetitive()) {
      if (($task->getRepeatBy() == 'start_date' && !$task->getStartDate() instanceof DateTimeValue) ||
         ($task->getRepeatBy() == 'due_date' && !$task->getDueDate() instanceof DateTimeValue)) {
            return array('date' => $min_date, 'count' => 0); //This should not happen...
      }
      
      $date = new DateTimeValue($task->getRepeatBy() == 'start_date' ? $task->getStartDate()->getTimestamp() : $task->getDueDate()->getTimestamp());
      $count = 0;
      if($date->getTimestamp() >= $min_date->getTimestamp()) {
         return array('date' => $date, 'count' => $count);
      }
      
      while ($date->getTimestamp() < $min_date->getTimestamp()) {
         if ($task->getRepeatD() > 0) {
            $date = $date->add('d', $task->getRepeatD());
         } else if ($task->getRepeatM() > 0) {
            $date = $date->add('M', $task->getRepeatM());
         } else if ($task->getRepeatY() > 0) {
            $date = $date->add('y', $task->getRepeatY());
         }
         $count++;
      }
      return array('date' => $date, 'count' => $count);
   } else return array('date' => $min_date, 'count' => 0);
}

Hope that helps troubleshoot the issue.

2

Older versions / Table 'og_template_parameters' already exists

« on: October 05, 2009, 08:53:11 pm »

Currently stuck at OpenGoo version 1.4.2.

Tried upgrading to 1.5, 1.5.1, 1.5.2, 1.5.3, each failing, was hoping 1.5.3 would break the trend.

Kept mysqldump and backup files (learned from previous OpenGoo updates) and was able to delete the database and recreate it, re-insert data, and re-upload older files.

Database script fails on each attempt to upgrade.  Searched forums but could not find solution.  Seems to be a common issue with no solution.  Attempted to go through the 1_5_figazza.php file and manually fix lines creating error.  Too many errors to debug and be cost-effective.

Messages seen on opengoo/public/upgrade/ page:
    * Config file found and loaded.
    * File '/config/config.php' exists and is writable
    * Folder '/config' exists and is writable
    * Folder '/cache' exists and is writable
    * Folder '/tmp' exists and is writable
    * Folder '/upload' exists and is writable
    * Extension 'mysql' is loaded
    * Extension 'gd' is loaded
    * Extension 'simplexml' is loaded
    * Upgrade script has connected to the database.
    * Test query has been executed. Its safe to proceed with database migration.
    * Upgrade script has connected to the database.
    * Test query has been executed. Its safe to proceed with database migration.
    *
    * Failed to execute DB schema transformations. MySQL said: Table 'og_template_parameters' already exists
    * Error upgrading to version 1.5.3

Would like to keep using OpenGoo but in-house bug-fixes are becoming too costly to maintain, or recommend, as a solution.

Solution would be great.  Thanks.

3

1.4 final / After 1.4.2: IE7 / Tasks Glitch When Scrolling

« on: June 17, 2009, 12:18:21 pm »

I upgraded to 1.4.2 yesterday morning and I hadn't noticed this issue until this morning. 

On the Tasks tab when you scroll down to see more tasks, the Milestones above the tasks scroll but the corresponding tasks remain stationary.  The problem somewhat is alleviated, though still a sluggish response, by switching to IE8 but can be recreated by putting IE8 in compatibility mode.  The users who brought this to my attention use IE7 (have not upgraded to IE8).

I am going to try and downgrade to 1.4.1 since this issue was not present then.  Has anyone else seen this issue or know of a resolution, other than upgrading to IE8?

Thanks!