You are not seeing double.

A few days ago I got reacquainted with an issue I had previously run into, but forgotten about.  Lets talk a little bit about the issue first, and then its solution. 


From time-to-time, the need to retrieve a list of SugarCRM users via the SOAP API presents itself.  For example, my CRM SkyDialer tool allows one to schedule an activity and as part of that process, one is allowed to select the user to whom the activity is assigned.


That list of users is dynamically generated by means of a call to the get_entry_list() method.  Now, for the problem.


When calling the get_entry_list() method, one has the ability to limit the records returned by specifying a WHERE clause as a parameter.  Logic would dictate that if one wanted a complete list of all active users within the instance of SugarCRM in question, the following WHERE clause would provide the desired results:


users.status = 'Active' AND users.deleted = 0


So far, so good, but somewhere in the life cycle of SugarCRM (version 5.5.1 is my best guess), a change was made to the relevant code that is responsible for providing the results.  This change in turn causes a problem when executing the get_entry_list() method with the above clause.  


If it does not provide the proper results, what exactly happens?

As it turns out, the admin user is duplicated for as many records as would have been returned by the method.


Suppose that one is using a SugarCRM system with three active users, instead of seeing:


User1
User2
User3 


The results would be:


admin
admin
admin


Fortunately, there is a simple solution to this problem.  


Changing the WHERE clause to the following corrects the problem:


users.id != 1 AND users.status = 'Active' AND users.deleted = 0


Rather than getting all active users that are not deleted, we instead retrieve all active users that are not deleted and purposely exclude the admin user.  Since the ID value for the admin user is always the same for all SugarCRM systems, we can safely assume within our own code that if we want to allow a user to select admin for a task such as scheduling an activity, the corresponding ID will be 1, thus there is no need to actually query the database for that entry.  


Hopefully that will save you some time next time you have a need to query the users table via the SOAP API.