Merge branch 'master' into 2234623

Author: tapanm-MSFT

powerapps-docs/maker/portals/configure/assign-entity-permissions.md

@@ -5,7 +5,7 @@ author: GitanjaliSingh33msft
 ms.service: powerapps
 ms.topic: conceptual
 ms.custom: 
-ms.date: 04/21/2021
+ms.date: 05/13/2021
 ms.author: gisingh
 ms.reviewer: tapanm
 contributors:
@@ -42,25 +42,25 @@ When creating a new Table Permission record, the first step is to determine the
 
 ### Global access type
 
-If a Table Permission record with Read permission is granted to a role that has global access type, any contact in that role will have access to all records of the defined table. For example, they can see all leads, all accounts, and so on. This permission will be automatically respected by any lists, essentially showing all records according to the model-driven app views that have been defined for that list. Further, if a user attempts to access a record via a basic form that they don't have access to, they'll receive a permission error.
+If an Table Permission record with Read permission is granted to a role that has global access type, any contact in that role will have access to all records of the defined table. For example, they can see all leads, all accounts, and so on. This permission will be automatically respected by any lists, essentially showing all records according to the Microsoft Dataverse views that have been defined for that list. Further, if a user attempts to access a record via an basic form that they don't have access to, they'll receive a permission error. For example, [show all car listings to all authenticated users in a car dealership](entity-permissions-studio-walkthrough.md#view-all-car-listings).
 
 ### Contact access type
 
 With Contact access type, a signed-in user in the role for which the permission record is defined will have the rights granted by that permission only for records that are related to that user's contact record via a defined relationship.
 
-On a list, this access type means that a filter will be added to whatever model-driven app views are surfaced by that list, which only retrieves records directly linked to the current user. (Depending on the scenario, this relationship can be thought of as ownership or management rights.)
+On an list, this access type means that a filter will be added to whatever Microsoft Dataverse views are surfaced by that list, which only retrieves records directly linked to the current user. (Depending on the scenario, this relationship can be thought of as ownership or management rights.) For example, [show, update, and delete owned car listings in a car dealership](entity-permissions-studio-walkthrough.md#view-update-and-delete-owned-car-listings).
 
-Basic forms will only allow the appropriate permission for Read, Create, Write, and so on, if this relationship exists when the record is loaded. [!INCLUDE[proc-more-information](../../../includes/proc-more-information.md)] [Define basic forms](entity-forms.md).  
+Basic forms will only allow the appropriate permission for Read, Create, Write, and so on, if this relationship exists when the record is loaded. More information: [Define basic forms](entity-forms.md).  
 
 ### Account access type
 
 With Account Access Type, a signed-in user in the role for which the permission record is defined will have the rights granted by that permission only for records that are related to that user's parent account record via a defined relationship.
 
-This access type means that the list will only show the records of the selected table that are associated to the user's parent account. For example, if a table permission allows Read access to Lead table with the Account access type, the user having this permission can view all the leads of only the parent account of the user.
+This access type means that the list will only show the records of the selected table that are associated to the user's parent account. For example, if an table permission allows Read access to Lead table with the Account access type, the user having this permission can view all the leads of only the parent account of the user. For example, [show all car dealerships](entity-permissions-studio-walkthrough.md#view-all-car-dealerships).
 
 ### Self access type
 
-Self Access Type allows you to define the rights a user has to their own Contact (Identity) record. Users can use basic forms or advanced forms to make changes to their own Contact record linked with their profile. The default Profile Page has a special built-in form that allows any user to change their basic contact info, and opt in or out of marketing lists. If this form is included in your portal (which it is by default), users won't require this permission to use it. However, they'll require this permission to use any custom basic forms or advanced forms that target their User Contact record.
+Self Access Type allows you to define the rights a user has to their own Contact (Identity) record. Users can use basic forms or advanced forms to make changes to their own Contact record linked with their profile. The default Profile Page has a special built-in form that allows any user to change their basic contact info, and opt in or out of marketing lists. If this form is included in your portal (which it is by default), users won't require this permission to use it. However, they'll require this permission to use any custom basic forms or advanced forms that target their User Contact record. For example, [profile page in a car dealership](entity-permissions-studio-walkthrough.md#change-profile-details).
 
 ### Parental access type
 

powerapps-docs/maker/portals/configure/entity-permissions-studio-walkthrough.md

@@ -5,7 +5,7 @@ author: ckwan-ms
 ms.service: powerapps
 ms.topic: conceptual
 ms.custom: 
-ms.date: 04/26/2021
+ms.date: 05/13/2021
 ms.author: ckwan
 ms.reviewer: tapanm
 contributors:
@@ -67,12 +67,13 @@ Contoso has the following relationships configured between tables in Dataverse.
 
 Contoso has the following customizations configured for this scenario.
 
-- Web pages have table permissions enabled. More information: [Manage page permissions](webpage-access-control.md)
+- Lists on web pages have table permissions enabled. More information: [Configure lists](entity-lists.md)
 - Web pages have [lists](entity-lists.md) configured with the tables, views, and the ability to create/view/edit/delete records as appropriate.
-    - To show [all car listings to all authenticated users](#view-all-car-listings), the web page has list with a view from the **Car listings** table with only View record permission.
-    - To show, update, and delete [owned car listings](#view-update-and-delete-owned-car-listings), the web page has list with a view from the **Car listings** table having View, Create, Edit, and Delete records permissions.
-    - To show [all car dealerships](#view-all-car-dealerships), the web page has list with a view from the **Dealerships** table having View, Create, Edit, and Delete records permissions.
+    - To show [all car listings to all authenticated users](#view-all-car-listings), the web page has list with a view from the **Car listings** table with only View record permission. Access type: [Global access](assign-entity-permissions.md#global-access-type).
+    - To show, update, and delete [owned car listings](#view-update-and-delete-owned-car-listings), the web page has list with a view from the **Car listings** table having View, Create, Edit, and Delete records permissions. Access type: [Contact access](assign-entity-permissions.md#contact-access-type).
+    - To show [all car dealerships](#view-all-car-dealerships), the web page has list with a view from the **Dealerships** table having View, Create, Edit, and Delete records permissions. Access type: [Account access](assign-entity-permissions.md#account-access-type).
     - To show [car listings for an associated dealership](#view-car-listings-for-associated-dealership), the web page has a list with a view from the **Dealerships** table. This list can be used to view the dealership details, with view having subgrid that shows the car listings associated to the selected dealership with View, Create, Edit, and delete records permissions.
+- Default [profile page](#change-profile-details) to allow sales staff to change their contact details. Access type: [Self access](assign-entity-permissions.md#self-access-type).
 
 ## View all car listings
 
@@ -233,6 +234,42 @@ To configure table permissions for sales staff to view associated dealership's c
 
 1. Select **Save**.
 
+## Change profile details
+
+Contoso uses the default profile page available with the portal template to allow sales staff to update their contact details.
+
+![Contoso Limited - sales staff able to change their own profile information](media/entity-permissions-studio-walkthrough/self-access.png "Contoso Limited - sales staff able to change their own profile information")
+
+To configure table permissions for sales staff to view associated dealership's car listings:
+
+1. Sign in to [Power Apps](https://make.powerapps.com).
+
+1. Select **Apps** on the left-pane.
+
+1. Select your portal.
+
+1. Select **Edit** to open portals Studio.
+
+1. Select **Settings** (:::image type="icon" source="media/entity-permissions-studio/settings.png":::) on the left pane inside portals Studio.
+
+1. Select **Table permissions**.
+
+1. Enter table permission name as "Staff contact details".
+
+1. Select **Contact** table.
+
+1. Select **Self access** as the access type.
+
+1. Select **Read**, and **Write** privileges.
+
+1. Select **Add roles**.
+
+1. From the list of available roles, select **Authenticated Users**.
+
+    ![Contoso Limited - self access](media/entity-permissions-studio-walkthrough/contoso-ltd-self-access.png "Contoso Limited - self access")
+
+1. Select **Save**.
+
 ## Summary
 
 Now that you have all the table permissions configured, this is how the permissions look like inside portals Studio.
@@ -243,6 +280,7 @@ Now that you have all the table permissions configured, this is how the permissi
 - **Cars associated to sales role** - This table permission allows each sales staff to view the car listings created by themselves using **Contact access** access type.
 - **Car dealerships owned by company** - This table permission allows sales staff to view all dealerships across the company using **Account access** access type.
 - **Cars in dealerships** - This child permission with is associated to the **Car dealerships owned by company** table permission. And allows sales staff to view car listings associated to their assigned dealership using **Associated access** access type (through child permission).
+- **Staff contact details** - This table permission allows sales staff the ability to change their profile information (their own Contact record).
 
 This scenario explained how to configure table permissions in a real-world scenario to achieve business goals. You can now use the learnings from this tutorial to configure table permissions for your portal to meet your business requirements.
 

powerapps-docs/maker/portals/configure/entity-permissions-studio.md

@@ -5,7 +5,7 @@ author: ckwan-ms
 ms.service: powerapps
 ms.topic: conceptual
 ms.custom: 
-ms.date: 04/26/2021
+ms.date: 05/13/2021
 ms.author: ckwan
 ms.reviewer: tapanm
 contributors:
@@ -33,8 +33,7 @@ Portals Studio shows four different **Access types**. Depending on the access ty
 1. **Self access** - Applies the selected table permission and privileges to the users from the selected role *for only their own contact record*.
 
 > [!NOTE]
-> - **Parent access type** is only available in the Portal Management app. Instead of creating a table permission with the access type as **Parent**, directly add child permission to existing table permissions when using portals Studio.
-> - Ensure you enable table permissions on web pages for permissions to take effect. More information: [Manage page permissions](webpage-access-control.md)
+> **Parent access type** is only available in the Portal Management app. Instead of creating a table permission with the access type as **Parent**, directly add child permission to existing table permissions when using portals Studio.
 
 ## Configure table permissions using portals Studio
 
@@ -70,6 +69,9 @@ To create a table permission using portals Studio:
 
     ![Contact or Account access type](media/entity-permissions-studio/contact-account-access-type.png "Contact or Account access type")
 
+    > [!NOTE]
+    > If you don't have any relationships available for the selected table, you can select **New relationship** to create a new relationship.
+
 1. Select privileges that you want to grant.
 
 1. Select **Add roles** to add the roles that this table permission will apply to.
@@ -103,6 +105,14 @@ To view table permissions using portals Studio:
 
     ![Group or filter table permissions](media/entity-permissions-studio/group-table-permissions.png "Group or filter table permissions")
 
+    > [!NOTE]
+    > - When you group table permissions by role, table, or state, the permissions are listed as a flat structure without the parent-child relationships for configured permissions.
+    > - You can only filter for parent table permissions, not child permissions.
+
+1. To sort the table permissions, select a column at the top in the list of table permissions.
+
+    ![Sort table permissions](media/entity-permissions-studio/sort-permissions.png "Sort table permissions")
+
 ### Edit table permissions using portals Studio
 
 To edit a table permission using portals Studio:
@@ -121,12 +131,18 @@ To edit a table permission using portals Studio:
 
 1. Select the table permission that you want to edit.
 
+1. Select **Edit** from the menu at the top. Alternatively, you can also select :::image type="icon" source="media/entity-permissions-studio/more-commands.png"::: (More Commands), and then choose **Edit**.
+
 1. Change table permission details, such as the name, table, access type, privileges, and applicable roles. More information: [Create table permissions using portals Studio](#create-table-permissions-using-portals-studio)
 
 1. Select **Save**.
 
 ### Deactivate/activate or delete table permissions using portals Studio
 
+A deactivated table permission becomes ineffective. You can activate a deactivated table permission later. When a table permission is deactivated, its child table permissions remain active but are not in effect due to the ineffective parent table permission. You can deactivate child permissions separately.
+
+When a table permission is deleted, it also deletes all associated child permissions.
+
 To deactivate/activate or delete a table permission using portals Studio:
 
 1. Sign in to [Power Apps preview](https://make.preview.powerapps.com).
@@ -143,7 +159,7 @@ To deactivate/activate or delete a table permission using portals Studio:
 
 1. Select the table permission that you want to deactivate/activate or delete.
 
-1. Select **Deactivate**, **Activate**, or **Delete**.
+1. Select **Deactivate**, **Activate**, or **Delete** from the menu at the top. 1. Select **Edit** from the menu at the top. Alternatively, you can also select :::image type="icon" source="media/entity-permissions-studio/more-commands.png"::: (More Commands), and then choose your option.
 
 1. Confirm when prompted.
 
@@ -165,7 +181,7 @@ To add a child permission to an existing table permission using portals Studio:
 
 1. Select the table permission that you want to add the child permission to.
 
-1. Select **Add child permission**.
+1. Select **Add child permission** from the menu at the top. Alternatively, you can also select :::image type="icon" source="media/entity-permissions-studio/more-commands.png"::: (More Commands), and then choose **Add child permission**.
 
 1. Create the child permission with the following details:
 
@@ -183,6 +199,30 @@ To add a child permission to an existing table permission using portals Studio:
 
 To view, edit, deactivate/activate or delete child permissions using portals Studio, follow the steps explained in the earlier section to [configure table permissions using portals Studio](#configure-table-permissions-using-portals-studio).
 
+## Additional considerations
+
+Table permissions configuration is subject to the following additional considerations and rules.
+
+### Parent table permission missing web role associated to its child
+
+When you have a child permission associated with one or more web roles missing from the parent permissions, you'll see the following error while editing the child permissions.
+
+"One or more roles applied to this permission aren't available to its parent table permission. Modify roles in either permissions."
+
+For example, a child table permission shows the below message when the parent table permission doesn't have the *Marketing* web role associated, even though the child permission is still associated.
+
+![Parent table permission missing one or more web roles associated to child table permission](media/entity-permissions-studio/missing-webrole-parent.png "Parent table permission missing one or more web roles associated to child table permission")
+
+To fix this problem, add the *Marketing* web role to the parent table permission, or remove the *Marketing* web role from the child table permission.
+
+### Table permissions without any web roles associated
+
+For a table permission to take effect, it has to be associated to one or more web roles. Users that belong to web roles are granted the privileges you select for the associated table permission.
+
+The following message shows when you try to save a table permission without any web role associated.
+
+![Saving a table permission without any associated web role](media/entity-permissions-studio/table-permission-without-webrole.png "Saving a table permission without any associated web role")
+
 ## Next steps
 
 [Tutorial: Configure table permissions using portals Studio](entity-permissions-studio-walkthrough.md)