In the upper right corner of the edit panel for any content type -- folders, images, pages, etc., and any specialized content types -- there is a menu on the right for publication state. This state menu has settings for controlling publication state:

The header for the menu will show the current publication state for the content item, such as state: public draft, as shown above. Public draft is the initial state when you create a content item -- an uploaded image, a page, a news item -- and in the public draft state, as the name indicates, the content item will generally be available to visitors to the web site.  There are several subtleties about this, however. Content items in public draft state may or may not be shown in menus, but they could be seen by search engines and by direct access by web address.  So, if the item is definitely meant to be hidden from view, because it is very rough draft perhaps, the make private menu choice is the appropriate step after the content item has been created.  

Also, and this will be very important, certain content types, such as news items and events, will not appear on the website as you expect, until they are explicitly published.

Store this in your memory: Publication state is important!

Publication state can be changed only by users whose accounts have the necessary permissions. The menu choices in the state menu will reflect existing permissions settings. For example, in a big newspaper web site, a reporter could add pages for news articles, but the state menu will not show a publish menu choice, only a submit menu choice. This is because a reporter must submit articles up the line to the editorial staff for approval before publication.  If your account has the permissions, however, the publish menu choice will appear and you can simply publish in one step.

For an editor, a content item that has been submitted may be published or rejected, either outright, because it is an inappropriate submission for the situation, or for the more typical reason that the content item needs revision.

After a content item has been published, it may be retracted, to change the state back to public draft state, and from there set to private, if desired. The menu choices in the state menu will change accordingly.

Consideration should be given to retracting ("unpublishing"), or setting to private, any content that has become obsolete or undesired for some reason.  Setting to private will take the item from public view and from showing up in search results, but will keep it around in case the format or the actual material (text, images, etc.) is needed later. This is especially true for content relating to events that may recur or to one-of-a-kind creations. The decision to delete or to set to private may depend on whether or not the content exists elsewhere, on a local computer.  If the content is large in size, in the sense of disk space taken, perhaps saving to a local computer is warranted before deletion, if space on the website server computer is an issue.

The state menu has an advanced... item:

which brings up the advanced state panel:

Below an explanation section at the beginning of the panel, there is a check box showing the content that will be affected by this change of publication state.  It shows that the folder "Long-tailed Skipper" will be affected by this state change. 

The next field, Include folder items, is a check box for controlling whether the state change affects this item only (the "Long-tailed Skipper" folder) or the items it contains and all of any subfolders and other contained items.  This is an important check box.  It lets you easily change the availability of an entire section of a website.  For example, the "Long-tailed Skipper" folder could contain four subfolders, for photographs, species occurrence descriptions, taxonomic history, and behavior descriptions, all of which has been kept private during the initial work to build up this content.  All of it could be immediately made public -- it could be published -- by checking this box and checking publish at the bottom before saving. 

Likewise, an entire section could be immediately made private. For example, if an automobile rental agency decided to remove a car model from its fleet, an entire section of their website devoted to this car model, with several subfolders full of pages, images, and files, could be set to private.

The next two date fields are for effective date and expiration date. Their meanings are straightforward.  If there is a window of time, for which a content item or a set of content items is valid for publication, it may be set with these fields.

A comment lets you attach an explanation to all content affected by the state change. This is especially useful when several people are working on a website, and a person less familiar with an area of the web site looks at content and wonders why it isn't published. They wonder, "This information looks good. Why isn't it published already?" Then they read a comment that says something like, "Don't publish until Richard checks on copyright issues regarding the items described here."  Using comments is a good idea for sensitive information, even if you are the only person working on the web site, because you might forget why you made a decision about publication state.

Finally, at the bottom there is a choice of several available states for this action.  It will vary, depending on the present state of the item. For example, if the item is currently in a published state, there won't be a choice for publish, if the item is presently in a private state, there won't be a choice for make private, etc.  If an item is published already, there will be choices in this bottom part of the panel for reject and retract, for "unpublishing" at item, setting it back to public draft or then to private state.

 Watch a video about controlling publication state.

The state menu has a choice for policy:

Workflow is an advanced subject. It involves creation of a more regimented control of content creation, review, and publication. If you have a user account on a typical small Plone site, you will probably not encounter custom workflow policies, because there isn't a need for this more sophisticated control. But, the potential is there for using this functionality, as it is built in to Plone.

For an introduction to the workflow concept, consider an example involving a web site for a newspaper business, for which these different groups of people are at work:

Reporters

Can create stories, but can only submit them for review.

Editors

Can review stories, but can't publish completely. They send positively reviewed and edited stories up the line for further approval.

Copy Editors

Do final fact checking, fixes, and review, and may publish stories.

A workflow policy, sometimes abbreviated to workflow, describes the constraints on state-changing actions for different groups of people. Once the workflow policy has been created, it needs to be applied to an area of the website for the rules to take affect. In the example of the newspaper web site, a workflow policy would be set up and then applied to the folders where reporters do the work of adding news articles. Then, reporters create stories and send them up the line for review and approval:

Reporters would add news articles and would submit them (the publish menu choice is not available to them). Likewise, editors may reject the article for revision or they may, in turn, submit the article up the line to a copy editor for final proofreading and publication.

Configuring a workflow policy is a matter of applying it to an area of the website. The policy menu choice brings up the workflow policy panel:

This small panel contains a link with the explicit title, "Add a workflow policy's local configuration in the Folder," which offers an intermediate check to make sure the intention is clear. Clicking the link brings up a workflow scope selection panel:

 

In this example, there is only one workflow policy available, "Default Policy," which is the standard workflow policy for Plone web sites.  In the newspaper business example, there would be a policy here called something like "Editorial Review Policy." The choice here is between setting For this Folder, to apply the policy the contents of the folder itself, and the Below this folder choice, to apply the policy to any subfolders, as well. After saving, the workflow policy would be in effect for this area of the web site.

The sharing tab panel is a large panel with many input fields:

The top box, called "Assigned Roles," shows existing settings for sharing of this item. It lists John Smith as the Owner of the item. That means that John Smith has the right to change the item, even delete it.  This is similar to privileges of the Manager role. Buttons at the bottom allow you to change the assigned roles or delete them.

The next box, called "Add Sharing Permissions to Users," has a search function for finding specific users. Once found, sharing privileges are set via the buttons at the bottom of the box.

The next box, called "Add Sharing Permissions to Groups," works the same way, except it is targeted at whole groups of users. For instance, on a web site for a community group, there could be five groups, one for each main committee of the organization. Perhaps this item is a folder to contain documents maintained by the "Recruitment" committee. Sharing permissions could be set for the "Recruitment Committee" group, and all users within it would have the same privileges. Very easy, and very powerful.

The "Advanced Settings" box is for controlling sharing access within a hierarchy of folders. There can be sophisticated arrangements for sharing, to manage "groups within groups."

Finally, the "Change Ownership" box at the bottom has a link to change ownership -- akin to "reassigning" -- to another user.