Go Live Issues

[eggsurplus]

Went live today and ran into a couple of issues:

1. Need to widen the cases dashlet edit display...Save button does not show in Firefox...no scroll bars like there is in IE. How do I do this?

2. Dashlets don't save when editing.

Thanks,
Jason

[clint]

What Sugar edition and version?

[eggsurplus]

CE 500e going from 4.5.1f. There may have been an upgrade php script that was missed. I assumed all the update scripts where in the sql file but I may be wrong here. I have ran a php script to convert the emails over though.

[clint]

What exactly do you mean by dashlets aren't saving when editing? All dashlets? Only some? Which ones did you try?

Try resetting the homepage and dashboard preferences for the user in their user screen. That usually solves problems like this.

You can override a dashlet by copying the entire dashlet directory from the modules directory over to the custom directory and making your changes there.

[eggsurplus]

Thanks Clint,

I tried resetting the homepage and dashboard but I still get the same issue. It is for any dashlet (tried Cases and Calls). If I edit the dashlet, add a column, then hit Save it will reload but never with the new column.

[eggsurplus]

If I run this query to reset the contents (this isn't being updated correctly by the UserPreferences->save):

update user_preferences
set contents = null
where ID = '9f3f5b7b-c7a5-e00d-0764-46e022ac4685'

It then loads the default dashlets but I'm still unable to save. When it saves to the db it saves the current contents every time instead of the updated preferences.

[eggsurplus]

If I comment out some line in this function it loads correctly (loadPreferences):

  
 
        //if(!empty($user->id) && (!isset($_SESSION[$user->user_name . '_PREFERENCES'][$category]) || (!empty($_SESSION['unique_key']) && $_SESSION['unique_key'] != $sugar_config['unique_key']))) {
            // cn: moving this to only log when valid - throwing errors on install
            $GLOBALS['log']->fatal('Loading Preferences DB ' . $user->user_name);
            //if(!isset($_SESSION[$user->user_name . '_PREFERENCES'])) 
            $_SESSION[$user->user_name . '_PREFERENCES'] = array();
            //if(!isset($user->user_preferences)) 
            $user->user_preferences = array();
            $result = $GLOBALS['db']->query("SELECT contents FROM user_preferences WHERE assigned_user_id='$user->id' AND category = '" . $category . "' AND deleted = 0", false, 'Failed to load user preferences');
            $row = $GLOBALS['db']->fetchByAssoc($result);
            if ($row) {
                $_SESSION[$user->user_name . '_PREFERENCES'][$category] = unserialize(base64_decode($row['contents']));
                $user->user_preferences[$category] = unserialize(base64_decode($row['contents']));
                return true;
            }
        //} 
  

[clint]

It sounds like an issue with your PHP sessions then. Is the session.save_path set properly in your php.ini? If you have open_basedir also set, make sure that your session.save_path is included in the open_basedir setting.

[eggsurplus]

I'll make sure to check that out soon as I get back above water here. That temp fix is working although it's causing preferences to have to be loaded continuously.

One weird thing we found today that used to happen in older versions. We had a subpanel showing all data so we did Repair Relationships which removed the cache. We then loaded the page and the relationships.cache.php page was recreated but correctly so the subpanel showed the correct data. We had to do a Quick Repair/Rebuild though for something and once we did that it overwrote the relationships.cache.php and removed the needed relationship from the file so that the subpanel was broken again. For now, we just have to remember to run Repair Relationships whenever we do a Quick Repair/Rebuild.

Thanks for your help! It's much appreciated.

[eggsurplus]

session.save_path is set just fine. openbase_dir is not being set. The environment is the same as that for 4.5.1.