Change module level search to not use wildcards

sugarcrmdevelopers —  January 9, 2013 — 4 Comments

If you remember this post from quite some time back, it talked about how you can use wildcards to do searches in a module. All searches by default do the equivalent of a SQL LIKE search, meaning it also searches for partial matches as well even if you don’t add wildcards ( so for example, searching for ‘John’ will return ‘Johnny’ and ‘John’ in the results ).

What if you want an exact result? Community member Francescas came up with a nice solution to this problem, changing the SearchFields.php entry for that searched field as follows…

The key is to change the ‘operator’ parameter to ‘=’, where by default it is ‘like’, which changes it from a wildcard search to an exact one. It also should speed up the search some as well.

4 responses to Change module level search to not use wildcards


    This post quite some time back => link is missing : ?


    Okay this seems like the best place to ask this question. In the latest version of sugar can I assign a unique leads layout view to a group? I have two sales teams and I would like the leads layout and fields to be unique to each group. Can that be done?


      You can’t do that yet without a code level customization. Depending upon how different the views are, you may be able to hide and show fields based upon the ACL permissions however.


      I did department dependent views for Cases. We have Customer Service and Tech Support groups, I added a support_group_c field to the Users module to determine which group people belonged to and used that to dynamically choose the Cases view for each. It’s a bit of a high-maintenance solution and working in Studio becomes a bit tricky but it works.
      For me, the CS view is the default for those that don’t have a support group.

      In custom/modules/Cases/views/view.edit.php

      class CasesViewEdit extends ViewEdit {
      public function preDisplay(){
      global $current_user;
      // support group dependent views
      $metadataFile = ‘custom/modules/’ . $this->module . ‘/metadata/editviewdefs_CS.php’;
      if ($current_user->support_group_c == ‘TS’){
      $metadataFile = ‘custom/modules/’ . $this->module . ‘/metadata/editviewdefs_TS.php’;
      $this->ev = new EditView();
      $this->ev->ss =& $this->ss;
      $this->ev->setup($this->module, $this->bean, $metadataFile, get_custom_file_if_exists(‘include/EditView/EditView.tpl’));

      Similarly in custom/modules/Cases/views/view.detail.php

      class CustomCasesViewDetail extends ViewDetail
      public function preDisplay(){
      global $current_user;
      $metadataFile = ‘custom/modules/’ . $this->module . ‘/metadata/detailviewdefs_CS.php’;
      if ($current_user->support_group_c == ‘TS’){
      $metadataFile = ‘custom/modules/’ . $this->module . ‘/metadata/detailviewdefs_TS.php’;
      $this->dv = new DetailView2();
      $this->dv->ss =& $this->ss;
      $this->dv->setup($this->module, $this->bean, $metadataFile, get_custom_file_if_exists(‘include/DetailView/DetailView.tpl’));

      then in custom/modules/Cases/metadata/
      I have the different versions of detail and edit views:



      Now, because I’m lazy and want to use studio for layouts, I copy the view that I want to modify to the standard detailviewdefs.php or editviewdefs.php, change what I need to change, save and deploy, then copy that file back to the _CS or _TS version.
      You just need to be careful about copying back and forth of course.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s