Restore DetailView Manually

[sieberta]

I added some custom fields to the editview of my employees module. I then synchronized these to detailview. This lost the nice little “grouped address” display. I tried to restore, but alas, the default doesn’t seem to be saved and is the same as what I have on the screen now.

I’m sure there is a manual way to fix this… I’m hoping someone can tell me how. I don’t see any tables in the database that are likely to be the cause or place where this is stored… and when I looked at the file structure, based on date modified, I didn’t find the file that I need to replace with the default installation file.

Under public_html/custom/modules/Employees/metadata there is a file that was edited in the right time frame, but alas, there is no corresponding file in the source files from SuiteCRM-7.1.3 MAX… furthermore, if I rename that file (editviewdefs.php) to (editviewdefs.php.old) it has zero effect.

Any help is appreciated. This was easy enough to screw up, I can’t imagine I’m the first to do this.

Thanks,
Drew

[andy]

Just delete the custom editviewdefs file and it will restore back to the default layout for that module. There is no way to get back custom layout changes that have been lost.

[sieberta]

Awesome Andy! It was actually detailviewdefs.php in my case, but this worked great. In case future folks are reading this trying to do the same thing, in my case the applicable file was located at…

/public_html/custom/modules/Employees/metadata

I simply renamed detailviewdefs.php to OLD9_16_2014detailviewdefs.php and then did a “Quick Repair and Rebuild” and the edit view was unchanged but the detail view (on refresh) was back to its old definition!!!

I did lose a couple of changes in the detail view, but they are easy enough to restore.

[andy]

No probs, also if you turn on developer mode in the admin settings then you wont have to do a repair and rebuild for the changes to take place.

[sieberta]

Interestingly… when I added my two fields to Employees->DetailView, the “Address” field shows up in detailview as “Address Country” (and only shows the country) instead of showing the entire concatenated address.

To be clear, I’m trying to leave “Address” alone/default… and trying to add Employee Start Date and End Date as new fields. What the fields are isn’t relevant, but I wanted to be clear it wasn’t having anything to do with the address.

In Studio it still shows up as “Address”, so it seems to me this is a bug. Not sure if anyone has ideas.

[sieberta]

This is getting to be outside the domain of the subject line “Restore Detailview Manually”… but since it is a continuation…

1. When I add items to contacts or accounts modules in studio, the address is not broken.
2. When I look at the detailviewdefs.php file for each of those, I can see how it works there, but the difference is, in both of those cases there is a ‘key’ associated with the address in questions (primary, alt, billing, shipping)… and when I try and steal the code from their detailviewdefs.php, I haven’t been able to find anything to put in the ‘key’ for the ‘displayParams’ to make the correct data show up in the view state.

Here is the relevant information from the viewdefs for the contact:

            array (
              'name' => 'primary_address_street',
              'label' => 'LBL_PRIMARY_ADDRESS',
              'type' => 'address',
              'displayParams' => 
              array (
                'key' => 'primary',
              ),
            ),

Here is my attempt for the employee (because the fields are just ‘address_[whatever]’ rather than ‘primary_address_[whatever]’.

          array (
          	'name' => 'address_street',
          	'label' => 'LBL_ADDRESS',
          	'type' => 'address',
          	'displayParams' =>
          	array (
          		'key' => '',
          	),

[sieberta]

OK, I found this code in /public_html/modules/Employees/metadata/detailviewdefs.php… and copied and pasted it into detailviewdefs.php in /custom/modules/Employees/metadata/detailviewdefs.php and it worked!

    array (
      'name' => 'address_country',
      'customCode' => '{$fields.address_street.value}<br>{$fields.address_city.value} {$fields.address_state.value}&nbsp;&nbsp;{$fields.address_postalcode.value}<br>{$fields.address_country.value}',
      'label' => 'LBL_ADDRESS',
    ),

Although I did have to do a “Quick Repair and Rebuild”… and I’m certain this change will be lost whenever I make additional changes in studio to the employees module.

[andy]

It shouldn’t be lost if you make changes in studio as long as the changes are in the custom folder for that module.

[sieberta]

Where can I find documentation on editing detailviewdefs.php and editviewdefs.php?

sieberta

[andy]

Try SugarCRM’s site. Although there isn’t really that much documentation available from Sugar either in terms of development.

[eitrix]

If you ever remove a field from view that has customCode and save the layout, it will not be put back by itself if you re-add the field to view definition.

[andy]

Yep that is correct. Why would it?

When you remove a field from the view you are removing the field from the defs file, if you re-add the field to the view the code for the field is added to the file its not going to magically re-add customisations to that code.

[amariussi]

You can find some info in the SugarCRM Manual here:

http://support.sugarcrm.com/02_Documentation/04_Sugar_Developer/Sugar_Developer_Guide_6.5/03_Module_Framework/01_MVC/02_View/

Then, you can browse the previous and following pages of the same chapter and get some more information,

Unfortumately it’s not well documented at all!

There is a book by John Mertic (.“The Definitive Guide to SugarCRM” ), which you can download for free at: http://it-ebooks.info/book/2473/

It may have some more examples and explanations. But again not structured at all.

[andy]

I have that book by John Mertic, I found it almost useless. Its well out of date now anyway.

[amariussi]

I agree with you Andy. I suggested it just because it MAY contain something useful.

I want to emphasize that it is not structured in any way and, as you say, rather old. But if you have time to browse it rapidly, given the lack of documentation, one could find some useful examples.

[kaylakaze]

I’ve found that the best way to make custom changes to your viewdef files outside of studio is to do it in the view class itself before parent::display()

Here’s some custom code I use in my CustomContactsViewDetail to put an image into my detail view (the findPhoto function just finds a file in the /upload/photo that has the file name _$params[2] and returns a thumbnail image inside an anchor tag to the full image ) and magnific-popup is a LightBox module. This way, no matter what I do in the studio, the photo still loads in the view. The only issue is if you need to change the index of the entry but that’s just changing [0][1] to something else.

$headshot=findPhoto($this->bean->id,'hs');
        echo "<style type='text/css'>@import url('custom/include/javascript/magnific-popup/magnific-popup.css');</style>";
        $this->dv->defs['templateMeta']['includes'][]=['file'=>'/custom/include/javascript/magnific-popup/jquery.magnific-popup.min.js'];
        $this->dv->defs["panels"]["lbl_contact_information"][0][1]=array (
              'label'=>'Photo',
              'customCode'=>$headshot,
            );
        parent::display();
        //echo javascript that attaches magnific-popup