Skip to content

Commit 839ce78

Browse files
authored
Merge pull request MicrosoftDocs#2889 from MicrosoftDocs/portals-1820794
Portals publishing state - 1820794
2 parents 9c6f3fb + 4537f55 commit 839ce78

File tree

1 file changed

+29
-12
lines changed

1 file changed

+29
-12
lines changed

powerapps-docs/maker/portals/configure/publishing-states.md

Lines changed: 29 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -4,8 +4,8 @@ description: "Learn how to create and manage publishing states in a portal."
44
author: sandhangitmsft
55
ms.service: powerapps
66
ms.topic: conceptual
7-
ms.custom:
8-
ms.date: 11/22/2019
7+
ms.custom:
8+
ms.date: 09/22/2020
99
ms.author: sandhan
1010
ms.reviewer: tapanm
1111
---
@@ -16,7 +16,7 @@ Publishing states allow for the definition of a content lifecycle in portals web
1616

1717
Publishing states can be used with [web pages](web-page.md), [web files](web-files.md), [web links](manage-web-links.md), forums, and advertisements.
1818

19-
By default, two publishing states are available: Draft and Published. Draft specifies content that should not be visible to non-content-author users, while Published specifies content that should be visible to all portal users (barring other security restrictions). You can modify the default configuration to meet your specific requirements, if desired – by adding new states or renaming states.
19+
By default, two publishing states are available: Draft and Published. Draft specifies content that shouldn't be visible to non-content-author users, while Published specifies content that should be visible to all portal users (barring other security restrictions). You can modify the default configuration to meet your specific requirements, if wanted – by adding new states or renaming states.
2020

2121
## Manage publishing states
2222

@@ -41,25 +41,41 @@ Publishing states can be created, edited, and deleted within portals.
4141

4242
8. Select **Save & Close**.
4343

44-
4544
### Publishing state attributes
4645

4746
|Name|Description|
4847
|-----|--------|
4948
|Name|The descriptive name of the state. This field is required.|
5049
|Website|The website to which the state belongs. This field is required.|
51-
|Is Default|If checked, designates this state as the default state for the website. This will determine the default state selected when creating new entities through the portal front-side editing interface.<br>**Note**:Only one Publishing State in a given Website should be marked as the default state.|
52-
|Is Visible|If checked, designates that entities associated with this state will be considered visible (or published) on the portal.<br>While an entity associated with a non-visible state will not be visible on the portal, an entity associated with a visible state may also not be visible, due to security permissions, expiration dates, or other visibility rules.<br>Users with content management permissions may be granted the ability to use Preview Mode, which allows these users to see (preview) unpublished content.|
50+
|Is Default|If checked, sets this state as the default state for the website. This option will determine the default state selected when creating new entities through the portal front-side editing interface.<br>**Note**: Only one Publishing State in a given Website should be marked as the default state.|
51+
|Is Visible|If checked, sets that entities associated with this state will be considered visible (or published) on the portal.<br>While an entity associated with a non-visible state won't be visible on the portal, an entity associated with a visible state may also not be visible, because of the security permissions, expiration dates, or other visibility rules.<br>Users with content management permissions may be granted the ability to use Preview Mode, which allows these users to see (preview) unpublished content.|
5352
|Display Order|An integer value indicating the order in which the state will be placed, in menus and drop-down lists for selecting a Publishing State – mostly found in the portal front-side editing interfaces.|
5453
|||
5554

55+
> [!IMPORTANT]
56+
> Creating new pages using portals [Studio](../portal-designer-anatomy.md) will fail if you don't have any default publishing state. Ensure that you have a default publishing state by selecting a publishing state record and set the **Is Default** attribute value to **Yes**.
57+
58+
> [!NOTE]
59+
> Web pages with no associated Publishing State may cause issues with the navigation menu and affect the page visibility. You may see a warning about such missing Publishing State associations for the pages when editing your portal. To fix this warning, select a Publishing State for each [Web Page record](web-page.md) using the [Portal Management app](configure-portal.md).
60+
61+
### Considerations for publishing state when editing portal
62+
63+
When you edit the portal using [Studio](../portal-designer-anatomy.md), you may see one of the following warning messages. To fix the warnings, follow the steps described in the description.
64+
65+
| Message | Description |
66+
| - | - |
67+
| `Found missing publishing state association for the page(s): {list of pages}. To avoid issues with the page(s), ensure each webpage has a publishing state configured.` | Web pages with no associated publishing state may cause issues with the navigation menu and affect the page visibility. You may see a warning about such missing publishing state associations for the pages when editing your portal. <br> To fix this warning, select a publishing state for each [web page](web-page.md). |
68+
| `Found multiple default publishing states configured. Publishing state {name} will be used as the default.` | More than one publishing state is set as the default. Since only one publishing state should be set as the default, the portals Studio will choose one from the configured multiple default publishing states. <br> To fix this warning, ensure only one publishing state is set as the default. |
69+
| `No default publishing state configured. Publishing state {name} will be used as the default.` | None of the available publishing state is set as the default. Portals Studio will choose one from the available publishing states as the default. <br> To fix this warning, ensure you set one publishing state as the default. |
70+
| `Found publishing states missing. Please create at least one publishing state as the default.` | There are no publishing states available. <br> To fix this warning, create at least one publishing state and set it as the default. |
71+
5672
## Publishing state transition rules
5773

58-
Publishing state transition rules allow you granular control over which web roles have the right to make what content changes on the portal in terms of publishing state.
74+
Publishing state transition rules allow you granular control over which web roles have the right to make what content changes on the portal for publishing state.
5975

60-
To be precise, publishing state transition rules govern the transitions between publishing states (Draft or Published). When a user attempts to switch the publishing state of an item from one to another, if a rule exists for this transition, then the security provider will assert that the web role for the logged-in user has permission to perform this transition.
76+
To be precise, publishing state transition rules govern the transitions between publishing states (Draft or Published). When a user attempts to switch the publishing state of an item from one to another, if a rule exists for this transition, then the security provider will assert that the web role for the logged-in user has permission to do this transition.
6177

62-
If the logged-in user who is attempting the change is in any of the roles you assign to the rule, the transition will be successful. If a user does not have permissions to make a change from one rule to another, then the front-side editing will not allow them to make that change. Alternatively, you can create the rule; then as you create web roles add the rule to the web roles. One rule can be associated with any number of web roles and vice versa.
78+
If the logged-in user who is attempting the change is in any of the roles you assign to the rule, the transition will be successful. If a user doesn't have permissions to make a change from one rule to another, then the front-side editing won't allow them to make that change. Instead, you can create the rule; then as you create web roles add the rule to the web roles. One rule can be associated with any number of web roles and the other way around.
6379

6480
1. Open the [Portal Management app](configure-portal.md).
6581

@@ -82,13 +98,14 @@ If the logged-in user who is attempting the change is in any of the roles you as
8298

8399
## State-based control rules
84100

85-
[Web page access control rules](webpage-access-control.md) can be linked with publishing states to allow or deny the right to view or modify content based on the branch of the website and the publishing state of content within that branch. To accomplish this, associate a web page access control rule with a publishing state. Once it is associated with a publishing state, the rule will only be applied to web pages when that publishing state is active.
101+
[Web page access control rules](webpage-access-control.md) can be linked with publishing states to allow or deny the right to view or modify content based on the branch of the website and the publishing state of content within that branch. To accomplish this task, associate a web page access control rule with a publishing state. Once it's associated with a publishing state, the rule will only be applied to web pages when that publishing state is active.
86102

87-
For example, say you wanted someone in the content publishing role to be able to modify a page's content, but only when that page is in Draft mode. This would ensure that changes to the page are not done while the page is 'live' and would allow for an approval process to be undertaken on pending changes.
103+
For example, say you wanted someone in the content publishing role who can modify a page's content, but only when that page is in Draft mode. This scenario would ensure that changes to the page aren't done while the page is 'live' and would allow for an approval process to be undertaken on pending changes.
88104

89105
To do this, you would create a rule with the grant change permission and apply it to the branch in question (or the home page if the rule is to apply to the entire site). You would then associate this rule with the draft state.
90106

91107
> [!div class=mx-imgBorder]
92108
> ![Create state-based control rule](../media/state-based-control-rule.png "Create state-based control rule")
93109
94-
You would then associate this rule with the appropriate web role, for example, Content publishing. Assuming this web role is not associated with a more permissive rule (i.e. a rule that grants change regardless of publishing state) then users in the content publishing web role will be able to modify pages in the draft state but will not be able to modify pages in the published state.
110+
You would then associate this rule with the appropriate web role, for example, Content publishing. Assuming this web role isn't associated with a more permissive rule (a rule that grants change no matter which publishing state) then users in the content publishing web role can modify pages in the draft state but can't modify pages in the published state.
111+

0 commit comments

Comments
 (0)