You are currently reviewing an older revision of this page.

Sugar 10.0 (Q2 2020) Customization Guide

Purpose

The purpose of this document is to provide insight to Sugar Developers for upgrading custom Sugar code, extensions, and integrations to the Sugar Q2 2020 release. This guide focuses on changes in Sugar Q2 2020 that could cause an immediate impact on Sugar customizations and integrations built for Sugar 9.3 (Winter '20). 

 

 

Sugar Instance Upgrade Path 

The upgrade path for 10.0.0-preview.1 and 10.0.0-preview.2 (this "Preview") is from 9.3 (Winter '20). There will be no upgrade path from 10.0.0-preview.1 and 10.0.0-preview.2 to the GA version of the Sugar Q2 2020 releases.

 

Cloud and On-Premise Sugar Release

For those looking to upgrade from Sugar 9.0, you will be catching up with additional content released last Summer '19, Fall '19 and Winter '20. In addition to this guide, please review the Sugar 9.1, Sugar 9.2, and Sugar 9.3 migration guides and Sugar 9.1, Sugar 9.2, and Sugar 9.3 release notes on the Sugar Support site to get a full view of changes since Sugar 9.0.

 

Expected to Affect Few Developers

This section explains items expected to have a low impact on Sugar customizations and integrations when migrated to Sugar 10.0. It is expected that these items will affect few developers. This release addressed many smaller bug fixes and UI changes. There are not many issues that require special attention from a development standpoint. You may want to take note of the following regarding your customizations before you upgrade: 

 

REST API Endpoint Changes

Currently, records with many SugarLogic related value formulas can cause the URI to become too long using GET, causing a 414 error.  Therefore, the existing GET endpoint for the ExpressionEngine's related values API (/ExpressionEngine/:record/related) has been deprecated. It has been replaced with a POST endpoint of the same name.

 

Sample request:

{
  "id": "a915cff8-1dec-11ea-b203-7200015efab0",
  "action": "related",
  "module": "Opportunities",
  "fields": [
    {
      "type": "rollupConditionalSum",
      "link": "revenuelineitems",
      "relate": "likely_case",
      "condition_field": "sales_stage",
      "condition_expr": "forecastSalesStages(\"true\",\"false\")"
    },
    {
      "type": "maxRelatedDate",
      "link": "revenuelineitems",
      "relate": "date_closed"
    },
    {
      "type": "rollupMax",
      "link": "revenuelineitems",
      "relate": "date_closed_timestamp"
    },
    {
      "type": "rollupConditionalSum",
      "link": "revenuelineitems",
      "relate": "best_case",
      "condition_field": "sales_stage",
      "condition_expr": "forecastSalesStages(\"true\",\"false\")"
    },
    {
      "type": "rollupConditionalSum",
      "link": "revenuelineitems",
      "relate": "worst_case",
      "condition_field": "sales_stage",
      "condition_expr": "forecastSalesStages(\"true\",\"false\")"
    },
    {
      "type": "count",
      "link": "revenuelineitems"
    },
    {
      "target": "closed_revenue_line_items",
      "type": "countConditional",
      "link": "revenuelineitems",
      "condition_field": "sales_stage",
      "condition_expr": "createList(\"Closed Won\",\"Closed Lost\")"
    },
    {
      "target": "included_revenue_line_items",
      "type": "countConditional",
      "link": "revenuelineitems",
      "condition_field": "commit_stage",
      "condition_expr": "forecastIncludedCommitStages()"
    }
  ]
}

 

Module Loader API

This is exciting - new REST Endpoints have been added for working with Module Loadable Packages.

 

  • /Administration/packages/:unFile
    • DELETE endpoint.
    • Delete the specified package.
    • Package 'unFile' hash must be provided.
    • Package 'unFile' hash can be found in staging package list.
  • /Administration/packages/:id/disable/
    • GET endpoint.
    • Disable the specified package.
    • Package id hash must be provided.
    • Package id can be found in installed package list.
  • /Administration/packages/:id/enable/
    • GET endpoint.
    • Enable the specified package.
    • Package id hash must be provided.
    • Package id can be found in installed package list.
  • /Administration/packages/:file_install/install/
    • GET endpoint.
    • Installs the specified package.
    • Package 'file_install' hash must be provided.
    • file_install hash could be found in staging package list.
  • /Administration/packages/
    • GET endpoint.
    • Lists all packages in the system.
  • /Administration/packages/installed/
    • GET endpoint.
    • Lists all installed packages.
  • /Administration/packages/staged/
    • GET endpoint.
    • Lists staged packages in the system.
  • /Administration/packages/:id/uninstall/
    • GET endpoint.
    • Uninstalls the specified package.
    • Package id hash must be provided.
    • Package id can be found in installed package list.
  • /Administration/packages
    • POST endpoint.
    • Uploads a module loadable package via a multi-part form request.
    • The only parameter is 'upgrade_zip' which must contain a valid module loadable zip file.

 

Field label Placement

An option has been added to allow users to designate whether field labels in record views will appear beside the field or above the field. This could affect your customized layouts as it is per-user and therefore one user's record view may now differ from another's. Field label placement will be set to "Beside Field Value" by default for all users upon upgrade.
This setting overrides labelsOnTop viewDef which is deprecated as of this release. So, every user will see their preferred label placement regardless of ANY other settings because there is no code option to set this value. It can only be changed from the User's profile settings. If this causes any issues with your customizations, your best bet is to write css overrides in a new MLP.