Tag search
Open Core: The worst of both worlds
by Sander MarechalA lot has been written recently about so called “Open Core” software ever since Andrew Lampitt coined the term back in August of 2008. Many analysts have been critical about it, such as Richard Hillesley from The H Open in his recent article “Open core, closed heart?”. Many are also very positive about it such as Matt Aslett from The 451 Group. However, I think that most them are missing the elephant in the room: Open core is not sustainable in the long term because it represents the worst of both worlds. Open core tries to find a middle ground between proprietary software and free software, but it reaps the benefits of neither and inherits the problems of both.
Let me show you by example. SugarCRM is one of the more popular open core software products available. The company offers the Community Edition for free under a GPLv3 license but also offers a Professional and Enterprise edition under a proprietary license. SugarCRM has been around since 2004 but it is already showing many signs of not being sustainable.
Digg this article: 
Enhance you SugarCRM edit views with filters
by Sander MarechalThe standard edit views for your custom modules are workable, but with a few additions and modifications you can make them a lot more powerful. In my last article “Add grandparent fields to your SugarCRM modules” I showed you how you can relate your modules to grandparent modules and even great-grandparent modules by following the chain of one-to-many relations upwards. This works very well to enhance your list views and detail views.
In this article we are going to use those grandparent fields on the edit view and use them to add filters to the other relate fields on your custom module. I will be building upon the invoicing module I created in the last article. It contains an Invoices module which relates to Accounts, and an InvoiceLines module which relates to Invoices. Suppose you want to edit an invoice line and move that line to another invoice. I will show you how to add functionality to the edit view so that, when you click the “Search” button on the Invoice field, the popup will only show you the invoices for the same account. This makes it much easier to find the right invoice, or any other related module.
Add grandparent fields to your SugarCRM modules
by Sander MarechalWhen you build custom modules in SugarCRM and you create one-to-many relations between them, you can put a link to the parent module the various views. But what if that parent module has a one-to-many relation to yet another module? By default SugarCRM does not support adding links to grandparent modules on your views. For example, suppose you have a custom Invoices module which relates to Accounts and you have an InvoiceLines module that relates to Invoices. When you look at an invoice it will contain a link to the account. When you look at an invoice line then you will see a link to the invoice. But you cannot add a link directly from the invoice line to the account.
In this article I will show you how you can add links and fields from grandparent modules to your own custom modules. I will build on the invoicing package I created in my article “SugarCRM many-to-one relations to standard modules”. That packages has an Invoices module that relates to Accounts, and an InvoiceLines module that relates to Invoices. I will add fields to the InvoiceLines module that directly links to the account.
SugarCRM many-to-one relations to standard modules
by Sander MarechalThe module builder in SugarCRM allows you to create one-to-many relations between one of your custom built modules and a standard module. However, it does not allow you to create many-to-one relationships. This means that it is not possible to create an Invoices module for example, where one account relates to many invoices, but each invoice only relates to one account. While you can create such a relationship by using the “Relate” field, you will not get a subpanel on the Accounts module that shows all the invoices that relate to in.
In this article I will show you how you can create a many-to-one relation between your custom module and a standard module. This relationship works the same way as the one-to-many relationship with full support for searching and subpanels, only the other way around. My setup is based on my previous two SugarCRM articles: “Keeping SugarCRM under Subversion control” and “Build custom SugarCRM modules in Subversion”. That means that I will be working inside the installable zip package that is generated by the SugarCRM module builder.
You can download the full invoicing package that I created in this article. It has been tested on SugarCRM 5.1.0b.
Build custom SugarCRM modules in Subversion
by Sander MarechalIn “Keeping SugarCRM under Subversion control” I showed you how I maintain the base SugarCRM in the face of changes to the core code. The setup described in that article allows me to make changes to the core code without running into (too much) trouble when SugarCRM ships a new version. It does have one downside: You cannot use Studio to make any changes. Instead, I keep all my customization work in a separate installable package, together with any custom modules I develop.
In this article I will show you how I develop my custom modules, how I keep them in Subversion and how they work together with the base SugarCRM from the previous article.
Keeping SugarCRM under Subversion control
by Sander MarechalI have been mulling a long time how I am going to keep track of SugarCRM, the custom modules I build and and changes to the core code that I need to make. The latter is sometimes unavoidable because some functionality cannot be built any other way. Also, sometimes you run into a bug that you need to fix, but you cannot wait for the next Sugar release. Of course, all of this needs to be done in a way that is easy for developers to work with. I think I have finally found a way that is workable and keeps everything under version control.
I will present my workflow in two articles. This article shows you how I keep SugarCRM itself under version control, how I deal with deployment and how I do upgrades in the face of changes to the core code. In “Build custom SugarCRM modules in Subversion” I will present how my custom modules—which are also under version control—fit into this system. Hat-tip to Leonid Mamchenkov for his work and insights.
Fixing one-to-many relationships in SugarCRM 5.1
by Sander MarechalUpdated 2008-12-12. With the release of SugarCRM 5.0 came the new Module Builder that allows administrators to easily create new custom modules. But it was quite buggy and there was no way to create one-to-many relationships between custom modules. Then came SugarCRM 5.1 that promised to resolve the issues. Besides the Relationship Editor in the Module Builder there are also the “Relate” and “Flex Relate” fields. Two different (and incompatible ways) to create relationships. Not to mention that the Relationship Editor in the Module Builder works differently from the same editor in Studio. The former creates relationships in code, the latter in the database. And there are still heaps of bugs*.
The biggest problem I have had is with one-to-many relationships, the most common relationship type when you’re creating modules. If you use “Relate” fields then no real relationship is created and you won’t get a subpanel in the parent module. If you use relationships created in the Module Builder then the related fields show up badly in the Edit and Detail views, and you cannot use them at all in the List view, subpanel or search panels.
After much agony, hair-pulling and cursing I have finally found a way how to resolve the latter issue: Here is how you can repair your layouts when using one-to-many relationships.
The SugarCRM cache directory demystified
by Sander MarechalUpdated 2009-01-07. One of the projects I am working on at the moment at my day job is customizing SugarCRM. We want to start managing all changes to SugarCRM using subversion, so we need to know which bits should be under version control and which bits should not. During my analysis I came across the ill‐named and infamous cache directory.
SugarCRM’s cache is anything but that. I already knew that uploaded files and e-mails were also stored in the cache directory, but I needed to know exactly what was in the cache so I can make some informed decision on what to put under version control and what bits of a production system should be backed up. I found my answer, after a whole lot of searching, reading the SugarCRM source code and asking around. It turns out that the cache directory contains a hodgepodge of user data files, configuration files and—oh yes, there are some real cache files in there as well.
If there is one thing to take away from this article it’s “Don’t mess with the cache unless you know what you’re doing”. That bears repeating:
“Don’t mess with the cache unless you know what you’re doing”
With that firmly burned into the back of your eyeballs, here’s an overview what the cache directory contains.
