Suspected AJAX issue on cases, edit view, assigned to field

[lowJack01]

Hello,

I just upgraded PHP and MySQL, but have already been on SugarCE 5.2.a for a couple months.

This morning I discovered that several, but not all, of my users are having problems creating cases. The assigned to list (generated by AJAX I think?), that pops up once you start typing in the field, is only displaying users whose names begin with L. How strange! Why L?

It doesn't seem to have anything to do with the user - different types with vastly different settings. More over, this does not happen when I try to put in an issue. Nor is it isolated to the client machine - when I log in as one of the affected users from my computer, I get the same problem.
have directed my users to use the select button, but they will start becoming unruly about it after a couple days.

I've tried rebuilding the database, doing a quick repair and rebuild on the cases module, and rebuilding the java script files. I also did a view source on both an affected and an unaffected user and could not see any discrepancies.

Has anyone seen this before?
Does anyone have any other suggestions as to things I should try? I would really appreciate any, even off-handed clues as to what I might try. I have some experience with JavaScript and CSS, but AJAX is new to me. Is this even AJAX?
Can someone point me in any direction? I'm going to look at the javascript files, now. Am I looking in the right place?

I'm now running:
PHP version 5.2.5
MySQL 5.0.45

[andopes]

Hi Jackie

Did you customize anything in the SugarCRM or just upgraded the MySQL and PHP?

I have never faced this issue before so be patient!
Let's try some initial debugging tasks:
Edit the file modules/Home/quickSearchQuery.php, go to the function query($ags) and add this code just after the begin.

 $fh = fopen('cases.log.txt', 'w');
fwrite($fh, print_r($args, true));
fclose($fh); 
  

Then try to create a new Case, type something into assigned user autocomplete field.
Then open the file cases.log.txt, attach it into your next post.

Cheers

[lowJack01]

cases.log.txt: filesize = 0.

I created the case in the full blown case edit view and nothing. Still a zero byte file. (I created the file myself and added wrtie to all, just to make sure there wasn't a file permission issue).

Thank you for the help!

[lowJack01]

Restarting the httpd server did not help.

I no longer think it is an AJAX issue, since it is also occuring in the shared calendar edit, which is html. It has to be a php version problem, b/c it first occured when we upgraded php.

[lowJack01]

Still having issue. Anybody want to venture a guess.

I've restored from back up onto my development environment - both files and db - and it works like a charm - on development. I have the same OS, php and mysql versions on both environs.

Help!

[McMichaeli]

Hi Jackie (and anyone else reading),

Did you ever get to the bottom of this? One of my customers has just reported a very similar problem. In all the Assigned To boxes only entries beginning with a lowercase "g" are returned.

They were running CE v5.2.0e but I've now upgraded to v5.2.0f with no success. I've also run all the repair options you tried. They're running PHP 5.2.5 and MySQL 5.0.45 on CentOS 5.3.

I've turned MySQL query logging on to try and get an idea of what's going wrong. Logged on as the original administrator (ID = 1), if I go to Create Opportunity and then type a single letter "a" into the Assigned To box, here are the queries that are run:

090722 16:57:05	    973 Connect     root@localhost on sugarcrm
		    973 Init DB     sugarcrm
		    973 Query       SET CHARACTER SET utf8
		    973 Query       SET NAMES 'utf8'
		    973 Query       SELECT id, name, symbol, conversion_rate FROM currencies WHERE status = 'Active' and deleted = 0
		    973 Query       SELECT category, name, value FROM config
		    973 Query       SELECT id FROM outbound_email WHERE type = 'system'
		    973 Query       SELECT * FROM outbound_email WHERE id = '30740165-116f-8f01-d2ba-47d59be119aa'
		    973 Query       SELECT users.* FROM users  WHERE users.id = '1'  AND users.deleted=0 LIMIT 0,1
		    973 Query       SELECT u1.first_name, u1.last_name from users  u1, users  u2 where u1.id = u2.reports_to_id AND u2.id = '1' and u1.deleted=0
		    973 Query       SELECT ea.*, ear.* FROM email_addresses ea
				LEFT JOIN email_addr_bean_rel ear ON ea.id = ear.email_address_id
				WHERE ear.bean_module = 'Users'
				AND ear.bean_id = '1'
				AND ear.deleted = 0
				ORDER BY ear.reply_to_address, ear.primary_address DESC
		    973 Query       SELECT distinct item_id AS item_id, id, item_summary, module_name, monitor_id, date_modified FROM tracker WHERE user_id = '1' AND visible = 1  ORDER BY date_modified DESC LIMIT 0,10
		    973 Query       SELECT count(*) as the_count FROM config WHERE category='info' AND name='sugar_version' AND value = '5.2.0'
		    973 Query       SELECT category, name, value FROM config
		    973 Query       SELECT id FROM outbound_email WHERE type = 'system'
		    973 Query       SELECT * FROM outbound_email WHERE id = '30740165-116f-8f01-d2ba-47d59be119aa'
		    973 Query       INSERT INTO tracker (monitor_id,user_id,module_name,date_modified,action,session_id ) VALUES ( '73e65c63-fb93-4e3f-cfe8-4a67364e7d75','1','Home','2009-07-22 15:57:05','quicksearchquery','d1av84gj6bca03tde6pbotesk4')
		    973 Quit

If I run the the large left-handed join against the database I get no rows returned. Is this normal? Do others see the same thing? If no rows are returned, why is the only user beginning with a lowercase "g" returned to the text box?

Any assistance or suggestions of other things to look at would be much appreciated.


Ian.

[McMichaeli]

After some extensive research, I'm answering my own question. Basically, I needed to add the following line to tne end of config_override.php:

$sugar_config['external_cache_disabled_memcache'] = true;

The version of CentOS my customer has installed is running memcached v1.2.2 with PHP configured to load the memcache module and store its session information using it. The session information doesn't seem to be an issue but if Sugar uses it to store user lists and the like they are not getting refreshed correctly once they become stale.

Further details of the PHP caching SugarCRM can use can be found here for those that want to read some more.

I hope this helps someone save the time I've spent on it...


Ian.