<h2>{i18n}Manage State{/i18n}</h2>

{$edit_form->render()}

{* The real meat is down here.  We define and list a set of actions and links to them. *}

<h3>{i18n}State Effects{/i18n}</h3>

<p class="descriptiveText">{i18n arg_appname="$appname"}One of the reasons that workflow is so key to
the way #appname# is used is that states can have a variety of effects on
the way other systems work.  For example:  workflow states can override the permissions
on a document, and reaching a state can cause notifications to be sent out.{/i18n}</p>

<dl>
    <dt><strong><a href="{addQS context=$context}action=security{/addQS}">{i18n}Security{/i18n}</a></strong></dt>
    <dd class="descriptiveText">{i18n}When a document is in a workflow state, that
    state can override some or all of the permissions that would "normally" be
    assigned to the document (e.g. via the folder it is in).  It can also restrict
    which document actions are available.{/i18n}</dd>
    
    <dt><a href="{addQS context=$context}action=editnotifications{/addQS}"><strong>{i18n}Notifications{/i18n}</a></strong></dt>
    <dd class="descriptiveText">{i18n}In order to progress through a workflow, a document
    will usually require collaboration between a number of different users.  
    One way to help this process is to inform certain groups or roles about
    the document's current state.{/i18n}</dd>
</dl>
