Thread Details
  • Replies 10 replies
  • Subscribers 353 subscribers
  • Views 2105 views
  • Users 0 members are here
Forum Actions
Related

Not Best Practices

John Hawkins

@  - 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

JH.

  • That is a wall of text to say you don't use a staging system to check new versions before updating the production.

    Cheers

    Björn

  • in reply to Björn Canales Pfisterer

    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.

    JH.

  • in reply to John Hawkins

    Ok I see.

    Custom layout made in studio is a core functionality and imho Sugar has announced to remove the standard fields from the standard module with its standard fuctionalities. But I agree this has room for missunderstandings.

    Regarding the update procedure I highly recommend to approach Sugar Support and sort out which instances should be upgraded first. I made this many times without any problem. Also you can ask them to copy over the prod to staging on demand ( requires a new ticket each time )

    Once this has been sorted out you will receive an email announcement one week before an instance gets updated (check the admin users for the desired email addresses ) and you are best prepared for the next updates without that kind of surprises.

    My recommendation for clients is to check at least on each module to create, edit and delete a record, also check SugarBPM processes if you have some.

    Cheers

    Björn

  • Hi ,

    I agree with your general principle that the field should not have been removed from a custom-defined layout unless there was an explicit impact to functionality by leaving the field in place. I assume this isn't the case since Sugar allows the field to be placed back on the layout after the upgrade. It seems that there is either a documentation or product bug since the documentation clearly states 'default layout'. If you haven't already, I recommend filing a support case since they may be able to address this for the upcoming 13.0 release. 

    I disagree with your assertion that files in the ./custom directory should remain untouched. There are plenty of scenarios where the upgrade must make modifications to those files in order to ensure compatibility with new features coming in an upgrade. I would never expect files to remain 'as is' on an upgrade because they are located in the ./custom directory.

    I echo 's recommendation that you should be proactive in coordinating upgrades of non-production environments with Sugar Support. For all our SugarCloud customers with non-prod environments, we ensure we have at least 1 sandbox refreshed from production, upgraded, and signed off by the customer before coordinating their production upgrade. Two resources we review for each upgrade to identify emphasized areas to test are the release notes and 'what to expect when upgrading' KB article for that release. If you're unfamiliar with the 'what to expect' articles, they are very helpful in outlining expected changes in user experience. Here is the 12.3 article for reference:

    https://support.sugarcrm.com/Knowledge_Base/Installation_Upgrade/What_to_Expect_When_Upgrading_to_12.3/

    Chris

    Co-Founder | SugarCRM's 2024 Global Outfitters Partner of the Year

  • Sugar Employee Badge

    Hi ,

    I'd like to "+1" on 's reply to your comments, he's got it right.

    Sugar can potently change your customizations to that'd prevent upgrades and/or fix syntax or templates through code as part of the customization. We don't do that behind the scenes, it will always be disclosed in our technical customization guides, webinars, and blog posts as much as we can. It's extremely important to follow those channels to keep yourself up-to-date with changes in upcoming releases.

    Now, for your particular Best/Worse Opportunity examples, we are intrigued with what happened and would like to have all the details you can provide us to troubleshoot and investigate on our side. It wasn't supposed to change anything in your 'custom' layout and should've preserved your customizations. Could you open a ticket with support (or request the customer to do so)?

    SugarCRM | Principal Developer Advocate

  • in reply to Rafael Fernandes

     and ,

    I fully support your standpoints, we are a professional Sugar partner and we do follow best practices where we can regarding testing and supporting upgrades for our customers. In this case we appear to have missed the fact a field has been removed from a layout. That doesn't change my fundamental point that customised layouts should not be overwritten (not overridden - it also appears the upgrade left no history trail of its actions, if it did it may be more excusable) if they exist. It is stated that Studio-level configuration changes are upgrade-safe (insofar as that can be a thing) and so I am pointing out that this has occurred.

    There is already a ticket open for this and the initial investigations are as Rafael says, that the upgrade was not supposed to touch the custom layout and was only meant to alter default layouts (as it says in the release notes - that is not ambiguous) but it did. Part of that ticket process has stood up a clone of the instance immediately prior to upgrade and we can see that the field was indeed still in the custom layout at that point. So it does appear to be the upgrade process that has silently removed it.

    The post here was for wider comment and to make the issue known to a wider audience as it may affect other layouts and customers. My intention here was to point out this had occurred and I had investigated and found it not to be human error on our or the customers part to remove that field. If I have found there might be a bug in the upgrade process I feel duty bound to let people know in case it affects their work as a developer / customer / partner.

    It appears that the messenger has been shot Disappointed

    Don't worry though, you haven't put me off posting to the forums where I think I can help Slight smile

    Thanks,

    JH.

  • in reply to Chris Raffle

    Chris,

    I agree with almost all of your points except to say that I didn't say that files in the ./custom directory should always be left as-is. I said that this is where you find files documented as being upgrade-safe. That means that, any specific documentation in the release notes notwithstanding, upgrades should not be removing fields from a custom layout as by definition that customer wants them there.

    I understand that there may be occasions when fields or functionality gets removed to make way for other stuff (and heaven knows, I have used Sugar long enough - since 2007 to be precise - to be aware of the complete mish-mush that is the ./custom directory) but such occasions should always be front and centre of any release announcement. This wasn't. And this does appear to be a bug.

    Thanks,

    JH.

  • in reply to John Hawkins

    Thanks for clarifying, John. I interpreted your original post as Sugar intentionally breaching guidelines of modifying files in ./custom rather than this being a defect encountered in the upgrade. Hopefully Sugar can identify the root cause quickly to mitigate the issue occurring for customers upgrading from 12.0 to 13.0.

    Chris

    Co-Founder | SugarCRM's 2024 Global Outfitters Partner of the Year

  • in reply to Chris Raffle

    No worries. My second paragraph (I thought) clarified that I was pointing out  difference between the release notes and the reality. The rest was a, probably over zealous, rant because this has materially affected our customer Disappointed

    Thanks,

    JH.

  • in reply to Björn Canales Pfisterer

    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