Not Best Practices

 - and whomsoever wants to comment Slight smile

We have become aware of an issue with the upgrade to 12.3 reported by a customer. In this case not P1 but pretty close in terms of what was actually done.

The release notes state that in 12.3 the Opportunity fields "Best and Worst fields have been removed from the Opportunities' default layouts in Admin > Studio but can be added back to the layout, if desired.". Our experience is that the "Best" field (actually in use by the customer) has been removed but from a custom layout not just the core one. In this case, in addition, some other (custom) fields also reappeared in the opportunity layout as well, this is being looked at.

It is an exceptionally poor customer experience to be changing a custom layout without warning. This also seems to go completely against SugarCRM's published "upgrade-safe" guidelines. I agree that the field may not be used in core Sugar layouts in a new version but this was a custom layout which means it is there deliberately at the customer's request. Effectively SugarCRM have ignored their own rules and changed a file in the ./custom path when these are documented as being where customers (or partners) make upgrade-safe changes. The release notes do state that the "Best" field is removed from Opportunity layouts but it is perfectly reasonable for customers, partners, developers et al to assume this means from core files only, not from upgrade-safe custom files.

In this instance, the customer was using that field for data collection and display. What happened was that a field they use for key data disappeared and they had to wait until an admin-role person was able to rebuild the layout to restore the field. Until then they were not able to perform their normal duties.

Just to hammer home the point about how poor a customer experience this is: if you were having your car serviced, would you be OK with the mechanic removing the steering wheel as part of the service and then saying "We can put it back for you if you were actually using it - at a cost of course!"?

Whilst on the face of it this may seem a minor gripe, in this case (as with many others) we as partners manage the admin roles in the instance and so it is down to us to make these repair changes. What this means is that we have either a) to charge the customer for the work done to repair SugarCRM's mistake (not acceptable to the customer) or b) do that repair work for free (not acceptable to us).

I'd like to know what others think of this as I see it as a serious breach of the published "upgrade-safe" guidelines.

Rant over (for now!) Wink


Parents Reply Children
  • Whilst I totally agree with your statement in pure terms, in this case we are talking about a cloud instance suite (3 instances - as it should be) where the Staging was upgraded after the Live one !! (and, btw, the Dev instance still has not been upgraded to 12.3). Customisations are tested for upgrades, however that should not need to include those parts which have been guaranteed and for which we may not have control (it is an admin user-level function).

    I am not able (allowed) to fully replicate SugarCRM's cloud upgrade functions in an On-Premise instance, so we do have to partly rely on documented practices and guidelines.

    However, you have missed my point which is that what happened violates documented policy whereby custom layouts (which may be generated by the Studio tool which is apparently guaranteed to be upgrade-safe ) have been modified by the upgrade process without authority. That should not happen.

    Just to be clear, I did not upgrade production. That was done by SugarCRM.


  • I agree with you before any upgrade you should be  able to understand what will be the impact that will cause to you system. A list item needs to be tested.
    such as: stock modules, check your data consistency , understand  if the new changes are with your current data structure, customisations etc.  

    Rodrigo Manara

    Sr. Developer