Add Invitees Not Functioning

[Chaney]

Hi All,

The Add Invitees functionality for both Meetings and Calls does not seem to be working for me. When I search for either First Name, Last Name, or Email and press the Search button nothing happens. I've read through the forums and tried all the solutions I've found (site url, debug mode, JSON caps error, updating the get_meeting_users function, etc). Nothing seems to work.I've tested it on IE 7, Safari, and FireFox on both Macs and PCs, still no dice. Debug mode didn't reveal anything obvious and the JS error panel didn't reveal anything either. I did test the demo site and that worked (which makes me think it's a potential PHP config issue?).

My install is as follows:

SugarCRM OS: 4.5.1d
PHP: 4.4.4
Linux: 2.6.9
Apache: 1.3.37
MySQL: 4.1.21

If anybody has any additional suggestions or routes to investigate it would be greatly appreciated.

Thanks in advance,
CJ

[kbrill]

All of your server software is getting a bit dated but I doubt thats causing the error. What happens if you just click on the search button without typing in anything?

[kbrill]

Also check the site_url in your config.php. If it's not right then the invitees thing wont work

[mhoppes]

I am having the exact same problem, except we are running MSSQL on Windows 2003 server with Apache 2.x.
Go to invitees.. click SEARCH and nothing happens.

My sitel_url is:
'site_url' => 'http://sugar.mydomain.net:81',


On a totally un-related note.. is there a reason the forum text in the input box is so small?!?!

Also check the site_url in your config.php. If it's not right then the invitees thing wont work

[ruchida]

I've filed a similar bug before (#13084) but it happened only with PHP 5.2. Is this a fresh install of 4.5.1d or upgrade? Did it work before? What version of php-json module do you have?

[Proware]

Mine stopped working with the 4.5.1d upgrade.

I restored an older version of json.php and json.js and it is now working. So something is changed between these versions.

I will see if the 4.5.1e upgrade fixes it.

[Jacob]

We did find a security vulnerability in one of the JSON encoding modules. I believe that we disabled the use of the pre-compiled JSON encoder/decoder to protect against this vulnerability.

From the comment in the code: SECURITY: bug 12274 - CSRF attack potential via JSON

I wonder if you take the current file and uncomment that one section (look for the comment above) if it will work again. If so, it is something that we might not be consistently encoding/decoding.

Jacob

[andydreisch]

Proware, any update?

Thanks,

Andy

[matthew]

The problem is that on the client side JSON.js, we added a condition looking for "while(1);/*" except that for some reason the web server is adding whitespace \nwhile(1);/* in front of that and the condition doesn't evaluate as true. So in JSON.parse(), I trimmed out the whitespace before the condition:

/*
Parse a JSON text, producing a JavaScript value.
It returns false if there is a syntax error.
*/
parse: function (text) {
// mfh: bug 14599
text = text.replace(/^\s*|\s*$/,'');
// cn: bug 12274 - the below defend against CSRF (see desc for whitepaper)
if(text.substr) {
if(text.substr(0,11) == "while(1);/*") {
text = text.substr(11);
text = text.substr(0, (text.length - 2));
}
if(text.substr(0,13) == "\nwhile(1);/*") {
text = text.substr(13);
text = text.substr(0, (text.length - 5));
}
}

try {
return !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
eval('(' + text + ')');
} catch (e) {
return false;
}
},