Data disappearance issue

I’m dealing with a painful snafu with my company’s Suite project. After experiencing an issue with re-deployment of modules, we restored from a backup made the day before (both the SuiteCRM files and the underlying database were deleted and restored from the backup). Since the backup restore, we’ve had this problem:

We have a module called Subjects that’s related to several other modules via one-to-many relationships. When the Subject’s name should be appearing (as a field) in a List view or a subpanel, the field instead shows up as blank (see screen shot; the “Subjects” field should be populated in all three records). The Subject’s name does show up in those other records’ Edit and Detail views, so the records are properly related; only List view and subpanels are affected. We’ve tried many repair and rebuilds, rebuilt relationships and checked permissions.

The problem happens only with the last Subject created before the backup restore and with any new Subject created since the restore. It persisted when we restored another backup from four days earlier. It had never happened before this first backup restore.

We’re at our collective wits’ end here, so any help will be greatly appreciated. Thanks!

Hi bgndy,

Firstly: never deploy modules directly from the Module Builder. Always first export them and then install them using the Module Loader

Debugging this is very difficult, I’d suggest you

  • Set Log Level to “Debug” in Admin / System Settings, open the specific module and look at the created queries in sugarcrm.log and see if any queries failed
    [li]Take a look at
data/SugarBean.php

in function create_new_list_query
Here all fields are passed and the query is created around line 3249

foreach($fields as $field=>$value)

Add debug code to see if the necessary field is passed. (it helpes to disable other subpanels)
[/li]
[li]
Take a look in

custom/Extension/modules/[relatedmodule]/Ext/Vardefs

and check if there are any old references to the related field
[/li]- Finally you can try to rebuild your system by taking clean source code, reinstalling the modules and trying to match the previous custom directory.

1 Like

Thanks much for replying. I’m trying your checks and haven’t found anything definite yet. The closest thing to a problem in the log was this:

Wed Apr 29 21:03:34 2015 [3634][1][INFO] Query:SELECT * FROM outbound_email WHERE id = ‘e4e53603-6dca-4cd2-31c1-552bd3254254’
Wed Apr 29 21:03:34 2015 [3634][1][INFO] Query Execution Time:0.00014591217041016
Wed Apr 29 21:03:34 2015 [3634][1][DEBUG] metadatafile=custom/modules/edu_Education/metadata/listviewdefs.php
Wed Apr 29 21:03:34 2015 [3634][1][INFO] Query:SELECT id, name FROM saved_search
WHERE
deleted = ‘0’ AND
assigned_user_id = ‘1’ AND
search_module = ‘edu_Education’
ORDER BY name
Wed Apr 29 21:03:34 2015 [3634][1][INFO] Query Execution Time:0.00047802925109863
Wed Apr 29 21:03:34 2015 [3634][1][DEPRECATED] Using row number in fetchByAssoc is not portable and no longer supported. Please fix your code.
Wed Apr 29 21:03:34 2015 [3634][1][DEBUG] Sprites: alt attribute detected for jscalendar.gif
Wed Apr 29 21:03:34 2015 [3634][1][DEBUG] Sprites: alt attribute detected for jscalendar.gif
Wed Apr 29 21:03:34 2015 [3634][1][DEBUG] SugarBean[edu_Education].load_relationships, Loading relationship (subj_subjects_edu_education_1).
Wed Apr 29 21:03:34 2015 [3634][1][DEBUG] SugarBean[edu_Education].load_relationships, Loading relationship (cont_schools_edu_education_1).

I know these deprecated warnings are considered largely irrelevant, but is it possible that this would case the field to not appear?

Oh, thank heavens. We figured it out. This is an issue in the SugarBean.php file. It probably won’t happen to many others, but if anybody else down the road creates a custom module with first_name and last_name fields and has trouble with it, here’s the problem:

In SugarBean.php, starting on line 3414, there’s a section that deals with concatenating fields in related modules. These lines in particular caused the issue:

//if bean has first and last name fields, then name should be concatenated
if(isset($rel_mod ->field_name_map[‘first_name’]) && isset($rel_mod ->field_name_map['last_name])){
$data[‘db_concat_fields’] = array(0=>‘first_name’, 1=>‘last_name’);
}

Our module, which was built using the “Basic” template, has fields called first_name and last_name, along with the main Name field. We had some records in which people had not entered first and last names, instead only entering a full name. When the related modules went to pull those records, they concatenated two blank fields instead of using the name field. This probably doesn’t happen when you use the “Person” template instead of “Basic,” since there’s also a full_name field.

This might be a minor bug, since it requires that you 1) create a custom module, 2) use the “Basic” template instead of “Person,” and 3) create first_name and last_name fields. But it sure set us back a few days.

Big thanks to jansiero for pointing us in the right direction.

Hi bgndy,

You’re probably on a very early version of SuiteCRM.

The issue has already been resolved in I believe v 7.1
Have a look in the fix in SugarBean.php in the following pull request:

https://github.com/salesagility/SuiteCRM/commit/78d717f158c77ac98cc455d28de8aec63b258eb7

Hm, we’re actually on 7.2.1. Odd.

OK, sorry, I read your post too fast. I suppose that conflicts are to be expected when you manually create first_name and last_name.

I suppose you’d need to rebuild the module using the Persons module as starting point.

Take a look at

custom/modulebuilder/packages/<packagename>/modules/<modulename>

You might be able to recreate the module, and then add metadata, language, relationships.php and vardefs.php manually, so you don’t need to click it all together again using the Module Builder.

OK, we’re figuring this out and we’ll be fine. Thanks again.

Going back to something you said earlier, why is it better to add modules through module loader instead of deploying from module builder?