Live publish

Author: buck1ey

powerapps-docs/developer/model-driven-apps/clientapi/client-scripting-best-practices.md

@@ -17,7 +17,7 @@ search.app:
 ---
 # Best practices: Client scripting in model-driven apps
 
-These are some of the best practice tips you could consider while writing your JavaScript code for model-driven apps.
+The following are some of the tips you could consider while writing your JavaScript code for model-driven apps.
 
 ## Define unique JavaScript function names
 
@@ -26,35 +26,33 @@ When you write functions that will be used in JavaScript libraries, your functio
 - **Unique function prefix**: Define each of your functions using the standard syntax with a consistent name that includes a unique naming convention, as shown in the following example.
     ```JavaScript
     function MyUniqueName_performMyAction()
-    {
-        // Code to perform your action.
-    }
+     {
+    // Code to perform your action.
+       }
     ```
 - **Namespaced library names**: Associate each of your functions with a JavaScript object to create a kind of namespace to use when you call your functions as shown in the following example.
     ```JavaScript
-    //If the MyUniqueName namespace object isn’t defined, create it.
-    if (typeof (MyUniqueName) == "undefined")
-       { MyUniqueName = {}; }
-       // Create Namespace container for functions in this library;
-       MyUniqueName.MyFunctions = {
-         performMyAction: function(){
-         // Code to perform your action.
-         //Call another function in your library
-         this.anotherAction();
-       },
-       anotherAction: function(){
-         // Code in another function
-      }
-    };
+    var Sdk = window.Sdk || {};
+    (function () {
+    this.formOnLoad = function () {
+      // Code to perform your actions.
+       }
+    this.attributeOnChange = function () {
+    // Code to perform your actions.
+      } 
+     this.formOnSave = function () {
+    // Display an alert dialog
+    }
+    }). call(Sdk);
     ```
 
     Then when you use your function you can specify the full name. The following example shows this.
 
     ```JavaScript
-    MyUniqueName.MyFunctions.performMyAction();
+    Sdk.attributeOnChange();
     ```
 
-    If you call a function within another function you can use the this keyword as a shortcut to the object that contains both functions. However, if your function is being used as an event handler, the this keyword will refer to the object that the event is occurring on.
+    If you call a function within another function, you can use this keyword as a shortcut to the object that contains both functions. However, if your function is being used as an event handler, this keyword will refer to the object that the event is occurring on.
 
 ## Avoid using unsupported methods
 
@@ -73,4 +71,4 @@ If you decide to use the remaining capabilities of jQuery that are useful with m
 
 ## Write your code for multiple browsers
 
-Model-driven apps support multiple browsers. You should make sure that any scripts that you use will work with all supported browsers. Most of the significant differences between Internet Explorer and other browser have to do with HTML and XML DOM manipulation. Because HTML DOM manipulation is not supported, if script logic is only performing supported actions and using the [Xrm object model](understand-clientapi-object-model.md), the changes required to support other browsers could be small. 
+Model-driven apps support multiple browsers. Make sure that any scripts that you use will work with all supported browsers. Most of the significant differences between Internet Explorer and other browser have to do with HTML and XML DOM manipulation. Because HTML DOM manipulation is not supported, if script logic is only performing supported actions and using the [Xrm object model](understand-clientapi-object-model.md), the changes required to support other browsers could be small. 

powerapps-docs/developer/model-driven-apps/define-custom-actions-modify-ribbon.md

@@ -2,7 +2,7 @@
 title: "Define custom actions to modify the ribbon (model-driven apps) | Microsoft Docs" # Intent and product brand in a unique string of 43-59 chars including spaces"
 description: "Learn about defining custom actions to modify the ribbon." # 115-145 characters including spaces. This abstract displays in the search result."
 keywords: ""
-ms.date: 10/31/2018
+ms.date: 10/13/2020
 ms.service: powerapps
 ms.topic: article
 ms.assetid: 72544b02-4eed-4d70-666e-a0d880f526af
@@ -19,8 +19,6 @@ search.app:
 
 # Define custom actions to modify the ribbon
 
-<!-- https://docs.microsoft.com/dynamics365/customer-engagement/developer/customize-dev/define-custom-actions-modify-ribbon -->
-
 The default, an application command bar or ribbon is defined by Common Data Service metadata. This default data can’t be changed, but you can include definitions of specific actions that will override the default ribbon.  
 
 ## Types of custom actions
@@ -49,18 +47,36 @@ The default, an application command bar or ribbon is defined by Common Data Serv
 ### Hide custom actions  
 
  A `<HideCustomAction>` is a statement that you use when you want to remove an existing ribbon element so that it is not rendered. This does not hide the ribbon element, it actually removes the ribbon element at runtime so that it doesn’t exist in the ribbon.  
+
+The **HideActionId** element provides a unique ID for the action. For consistency and readability, you should follow the same naming convention described for `<CustomAction>` elements. The **Location** attribute must match the Id of the ribbon element you want to remove.  
 
 > [!NOTE]
 > Because the `HideCustomAction` element removes a specified node from the ribbon, removing ribbon elements in this manner may not be the best option for every situation.  
 > 
 > - If you want to remove a button that is associated with a specific privilege, you should adjust the privileges for the entity in the security roles in your implementation. This will allow the default ribbon display and enables rules to hide or disable ribbon elements from users who do not have the necessary privileges to perform those actions.  
 >   -   If you want to replace an existing ribbon element with a custom ribbon element, you can overwrite that element by specifying a `CustomAction.Location` value identical to the existing element.  
+> - To remove the `HideCustomAction` element you need to create a new updated version of the same solution that installed the `HideCustomAction` element. A new patch of the solution cannot remove the `HideCustomAction` element.
+
+The `HideCustomAction` element cannot be removed, once added, except by creating a new updated solution. Instead, ribbon buttons should be hidden using a `DisplayRule` element that always evaluate to false. Having both `Mscrm.HideOnModern` and `Mscrm.ShowOnlyOnModern` would always evaluate to false. For example, to hide a deactivate button:
+
+```xml
+<CommandDefinition Id="Mscrm.HomepageGrid.Deactivate">
+    <EnableRules>
+      </EnableRules>
+      <DisplayRules>
+        <DisplayRule Id="Mscrm.HideOnModern" />
+        <DisplayRule Id="Mscrm.ShowOnlyOnModern" />
+      </DisplayRules>
+      <Actions>
+        </Actions>
+    </CommandDefinition>
+```
 
- The **HideActionId** element provides a unique ID for the action. For consistency and readability, you should follow the same naming convention described for `<CustomAction>` elements. The **Location** attribute must match the Id of the ribbon element you want to remove.  
+
 
 ### See also  
 
- [Customize commands and the ribbon](customize-commands-ribbon.md)   
- [Pass data from a page as a parameter to Ribbon actions](/dynamics365/customerengagement/on-premises/developer/customize-dev/pass-dynamics-365-data-page-parameter-ribbon-actions
+[Customize commands and the ribbon](customize-commands-ribbon.md)   
+[Pass data from a page as a parameter to Ribbon actions](/dynamics365/customerengagement/on-premises/developer/customize-dev/pass-dynamics-365-data-page-parameter-ribbon-actions
 )<br/> 
- [Define scaling for Ribbon elements](define-scaling-ribbon-elements.md)
+[Define scaling for Ribbon elements](define-scaling-ribbon-elements.md)

powerapps-docs/maker/canvas-apps/functions/function-ismatch.md

@@ -97,6 +97,7 @@ Predefined patterns provide a simple way to match either one of a set of charact
 | **Period** |Matches a period or dot ("."). |`\.` |
 | **RightParen** |Matches a right parenthesis ")". |`\)` |
 | **Space** |Matches a character that adds whitespace. |`\s` |
+|**Tab**|Matches a tab character.|`\t`|
 
 For example, the pattern **"A" & MultipleDigits** will match the letter "A" followed by one or more digits.  
 

powerapps-docs/maker/canvas-apps/functions/function-param.md

@@ -93,15 +93,15 @@ Use the *LaunchTarget* argument to specify the target browser window in which to
 
 | LaunchTarget enum | Description | 
 | --- | --- | 
-| **Blank** | The webpage or app is opened in a new window or tab. |
-| **Self** | The webpage or app replaces the current window or tab. |
+| **New** | The webpage or app is opened in a new window or tab. |
+| **Replace** | The webpage or app replaces the current window or tab. |
 | *name* | Instead of an enum value, use your own text string to *name* the window or tab.  *Self* is an internal only name that is only used by the **Launch** function. It has no impact on nor will it match the title of the window that your users see.  If a window or tab with the given *name* already exists, its contents will be replaced. Otherwise, a new window or tab will be created.  *name* can't begin with the underscore character "_". |
 
-**Blank** is the default enum when running in a web browser with **Self** and *name* as available options. In a mobile player, **Blank** is the default for webpages with *name* as an available option; while the current canvas app will always be replaced by another canvas app.
+**New** is the default enum when running in a web browser with **Replace** and *name* as available options. In a mobile player, **New** is the default for webpages with *name* as an available option; while the current canvas app will always be replaced by another canvas app.
 
 > [!NOTE]
-> - Using a *LaunchTarget* with any value other than **Blank** in embedded scenarios (for example, Power BI or SharePoint) is not supported and may result in unexpected behavior. In the future, this behavior may change, or may cause an error.
-> - *LaunchTarget* enum names are in transition. You may use **Blank** and **Self** currently, though these names will change in the future. **Self** will go through an intermediate change to **'Self'** as a new **Self** keyword is introduced. To avoid this conflict, the expected names may be **New** and **Replace**. Your app will automatically update when these changes occur. Your formulas won't need an update manually.
+> - Using a *LaunchTarget* with any value other than **New** in embedded scenarios (for example, Power BI or SharePoint) is not supported and may result in unexpected behavior. In the future, this behavior may change, or may cause an error.
+<!-- *LaunchTarget* enum names are in transition. You may use **Blank** and **Self** currently, though these names will change in the future. **Self** will go through an intermediate change to **'Self'** as a new **Self** keyword is introduced. To avoid this conflict, the expected names may be **New** and **Replace**. Your app will automatically update when these changes occur. Your formulas won't need an update manually.-->
 
 ### Security zones
 

powerapps-docs/maker/canvas-apps/geospatial-overview.md

@@ -1,19 +1,18 @@
 ---
-title: 
-description: 
+title: Add Geospatial components to apps made with Microsoft Power Apps
+description: Geospatial components let you view and manipulate 3D objects and images in the real world, in augmented reality. 
 author: iaanw
 manager: shellha
 ms.service: powerapps
 ms.topic: conceptual
-ms.custom: canvas
+ms.custom: canvas, ce06122020
 ms.reviewer: tapanm
 ms.date: 6/12/2020
 ms.author: iawilt
 search.audienceType: 
   - maker
 search.app: 
   - PowerApps
-ms.custom: ce06122020
 
 ---
 
@@ -62,7 +61,9 @@ The geospatial features require additional terms of use that must be reviewed an
     ![Screenshot of the terms of service](./media/geospatial/ppac-tos.png "Screenshot of the terms of service")
 
     >[!IMPORTANT]
-    >You must read and agree to the terms of service before you can use geospatial features. The following are the terms of service:  
+    >You must read and agree to the terms of service before you can use geospatial features. 
+    >
+    >The following are the terms of service:  
     >  
     >These features use mapping capabilities that are powered by a third party, TomTom(tm), and operate outside your tenant's geographic region, compliance boundary, or national cloud instance.  
     >
@@ -73,6 +74,12 @@ The geospatial features require additional terms of use that must be reviewed an
     >Additional licensing requirements might be required to enable this feature.  
 
     ![Screenshot of the geospatial services toggle switch to On](./media/geospatial/ppac-geo-on.png "Screenshot of the geospatial services toggle switch to On")
+    
+    >[!NOTE]
+    >Requests sent between TomTom(tm) and the Azure Maps service are not exposed over the public Internet.
+    >
+    >Requests between apps you create with the component and the Azure Maps service are sent over HTTPS.
+    
 
 1. Select **Save** at the bottom of the settings page.
 

powerapps-docs/maker/common-data-service/create-connection-reference.md

@@ -47,7 +47,7 @@ You can add a connection reference to a solution in a few different ways:
 
 ## Limits
 
-During the preview, the same connection reference can be used a maximum of 16 times in flows.
+While connection references are in preview, one connection reference can only be used within a maximum of 16 flows. If the same connection needs to be used in more than 16 flows, then create another connection reference with a connection to the same connector. There is no limit to the number of actions in each flow that can be associated with the connection reference.
 
 ### See also
 

powerapps-docs/maker/model-driven-apps/media/hide-property.png

@@ -25,16 +25,26 @@ search.app:
 ---
 # Show or hide model-driven app form elements
 
- Several types of form elements have the option to be shown or hidden by default. Tabs, sections, fields, iFrames, and web resources all provide this option. Using form scripts or business rules the visibility of these elements can be controlled to create a dynamic form to provide a user interface that adapts to conditions in the form.  
+Several types of form elements have the option to be shown or hidden at app runtime. Tabs, sections, fields, iFrames, and web resources all provide this option. You can change the default setting to view a form element in the form designer by selecting the **Hide** property.
+
+<img src = "media/hide-property.png" alt = "Hide property for a tab on a form" width = "300" height = "481">
+
+Using form scripts or business rules, the visibility of these elements can be controlled to create a dynamic form to provide a user interface that adapts to conditions in the form.  
 
 > [!IMPORTANT]
->  Hiding form elements is not a recommended way to enforce security. There are several ways people can view all the elements and data in the form when elements are hidden. 
-> Disabling, hiding, or locking a field, control, or form component using the form designer, manually in the form XML, or using a Client API only works to control data access in a Unified Interface or legacy web client app. It doesn’t strictly enforce data access by itself in the apps. Moreover, it doesn’t control data access using other ways to connect to Common Data Service such as using the Web service or a canvas app. It is also important to know that the app will not display an error message or block a save if a required field is null and has been disabled. This ensures that users are never blocked from completing a task. To control access, see [Set security roles for a form](control-access-forms.md#set-security-roles-for-a-form) or use [Field-level security](/power-platform/admin/field-level-security). 
+> Hiding form elements is not a recommended way to enforce security. There are several ways people can view all the elements and data in the form when elements are hidden. 
+> Disabling, hiding, or locking a field, control, or form component using the form designer, manually in the form XML, or using a Client API only works to control data access in a Unified Interface or legacy web client app. It doesn’t strictly enforce data access by itself in the apps. Moreover, it doesn’t control data access using other ways to connect to Common Data Service such as using the Web service or a canvas app. It is also important to know that the app will not display an error message or block a save if a required field is null and has been disabled. This ensures that users are never blocked from completing a task. To control access, see [Set security roles for a form](control-access-forms.md#set-security-roles-for-a-form) or use [Field-level security](/power-platform/admin/field-level-security).
   
- Rather than designing forms that depend on scripts to control visibility of options, consider whether a business process flow, a dialog, or switching to a different form may be better suited to meet your requirements. If you do use scripts, make sure that any element that might be hidden is hidden by default. Only show it with scripts when your logic calls for it. This way it will not be displayed in presentations that do not support scripts.
- 
- > [!NOTE]
-> In the Unified Interface, for sections where fields don’t span more than one column, hiding a field in the section moves the field below up on the form. If a field spans more than two columns in a section, hiding a field in the section that has a control across from it will not move the field below it up on the form. You will see additional white space where the hidden field is in the section.
+Rather than designing forms that depend on scripts to control visibility of options, consider whether a business process flow, a dialog, or switching to a different form may be better suited to meet your requirements. If you do use scripts, make sure that any element that might be hidden is hidden by default. Only show it with scripts when your logic calls for it. This way it will not be displayed in presentations that do not support scripts.
+
+In the Unified Interface, for sections where fields don’t span more than one column, hiding a field in the section moves the field below up on the form. If a field spans more than two columns in a section, hiding a field in the section that has a control across from it will not move the field below it up on the form. You will see additional white space where the hidden field is in the section.
+
+## Client API methods for controlling the visibility of form elements
+
+For information about how to change the form element show or hide status for the header, command bar, footer, and tabs at app runtime, see these client API reference articles:
+- [formContext.ui.headerSection item (Client API reference)](../../developer/model-driven-apps/clientapi/reference/formContext-ui-headerSection.md)
+- [formContext.ui.footerSection item (Client API reference)](../../developer/model-driven-apps/clientapi/reference/formContext-ui-footerSection.md)
+- [formContext.ui.tabs (Client API reference)](../../developer/model-driven-apps/clientapi/reference/formContext-ui-tabs.md)
 
 ## Next steps