Contact History?

[bbogart]

Is there a way to see the entire history for a contact in a single view.

Right now when a contact calls me, to review their case I have to open the contact and click on each history item separately.

What I am looking for is a detailed view including the notes from all of the interactions (or the past 10) so I can look at them all at once without clicking on each event.

Thanks,

[davidboris]

Hi,

With customization you can do this.
Suggestion: Put an extra button at the top of contact's detail view, on click you can open a popup showing related notes with the details, like title, description, etc.

[bbogart]

Hmm. Ok.

How does SugarCRM do with customization at the time of updates? Do the patches have to be reapplied after each update?

[davidboris]

Hi,

If, you do customizations in an upgrade safe way, it will remain safe.
And what I suggested can be done in upgrade safe way.
So you dont need to worry about that.

[datasponge]

Is there a way to see the entire history for a contact in a single view.

Right now when a contact calls me, to review their case I have to open the contact and click on each history item separately.

What I am looking for is a detailed view including the notes from all of the interactions (or the past 10) so I can look at them all at once without clicking on each event.

Thanks,

Sounds like what the 'View Summary' button does. It shows the entire history including notes in a separate window. No customization required.


Regarding customizations and upgrades, many customizations can be done in a manner called "upgrade safe" that allows them to be retained across upgrades. Sugar has special folders and techniques to allow this.

Phil

[bbogart]

Is there more info on this somewhere?

I'm brand spankin' new to SugarCRM so I don't have an idea of what would be considered an "upgrade safe" way to create a customization. I also don't know what is considered best practice for creating customizations.

[davidboris]

Hi,

Phil is right!! I wonder how I missed that button when reading this thread

Sounds like what the 'View Summary' button does. It shows the entire history including notes in a separate window. No customization required.

[bbogart]

yes it does Silly me. Thanks for pointing that out.

I would still like to know where to find more information on writing safe customizations.

Unfortunately when I go to "documentation" on sugarforge I get a message saying I am using invalid login credentials (I haven't changed anything and they are the same ones I use for other parts of the site) so if its in there I don't really know what to do. I posted this issue in the help forum.

[datasponge]

I didn't find any simple references on what is upgrade safe, but there are lots of examples in the forums.

I'll try to give a simple overview, but the devil is in the details for what you're trying to accomplish, so I always poke around the forums when I have a specific application I want to implement.


The basic idea is that you can make customizations in several fairly standard ways:

1. Use studio to add custom fields, custom labels, relationships, etc and including subpanels in 5.5 and higher. These changes are retained across upgrades, so are considered upgrade-safe.
2. Write extensions by placing new php code into the folders under <sugar_root>/custom/Extension/modules/<MODULE_NAME>/Ext in the folder for what you want to extend. Poke around and you'll see some files that sugar already places in these folders. Some examples are:

Variable definitions (Vardefs)
Language files and labels (Language)
etc.

These changes are considered upgrade-safe because Sugar does not modify the custom subtree on upgrade.
3. Add new modules using Module Builder. These changes are written to <sugar_root>, but are generally considered upgrade-safe because the name assigned to the folder has an ugly code you assign pre-pended at the beginning. The idea is that Sugar only upgrades folders whose name it knows, so it won' t modify files it doesn't recognize, so those new modules are retained.

There are other ways I am less familiar with like modifying views and controllers that are also upgrade safe.

Never modify files directly in <sugar_root> that were installed by Sugar as these can be overwritten during an upgrade. Never put folders into <sugar_root> that have simple names that Sugar might use for a new feature as these could be overwritten.

Often you can simply copy a file in <sugar_root> into the same folder structure under custom and modify it and the changes will be retained, but be careful here as this may cause you to not get new features when Sugar updates the original file. It can also sometimes cause incompatibilities if you add a dependency to a particular structure that gets changed, so proceed carefully with that technique.

Hope that helps.

Phil