You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: powerapps-docs/maker/portals/configure/publishing-states.md
+29-12Lines changed: 29 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,8 +4,8 @@ description: "Learn how to create and manage publishing states in a portal."
4
4
author: sandhangitmsft
5
5
ms.service: powerapps
6
6
ms.topic: conceptual
7
-
ms.custom:
8
-
ms.date: 11/22/2019
7
+
ms.custom:
8
+
ms.date: 09/22/2020
9
9
ms.author: sandhan
10
10
ms.reviewer: tapanm
11
11
---
@@ -16,7 +16,7 @@ Publishing states allow for the definition of a content lifecycle in portals web
16
16
17
17
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.
18
18
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.
20
20
21
21
## Manage publishing states
22
22
@@ -41,25 +41,41 @@ Publishing states can be created, edited, and deleted within portals.
41
41
42
42
8. Select **Save & Close**.
43
43
44
-
45
44
### Publishing state attributes
46
45
47
46
|Name|Description|
48
47
|-----|--------|
49
48
|Name|The descriptive name of the state. This field is required.|
50
49
|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.|
53
52
|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.|
54
53
|||
55
54
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
+
56
72
## Publishing state transition rules
57
73
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.
59
75
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.
61
77
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.
63
79
64
80
1. Open the [Portal Management app](configure-portal.md).
65
81
@@ -82,13 +98,14 @@ If the logged-in user who is attempting the change is in any of the roles you as
82
98
83
99
## State-based control rules
84
100
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.
86
102
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.
88
104
89
105
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.
90
106
91
107
> [!div class=mx-imgBorder]
92
108
> 
93
109
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.
0 commit comments