By default, the Alfresco WCM UI allows an author to select a different workflow and even reconfigure it at submission time, as shown in the following screenshot:
[caption id='attachment_243' align='aligncenter' width='500' caption='Screenshot: Configure Workflow at Submit Time']
[/caption]
The obvious issue is that typically authors should not have the ability to influence the approval process, which, after all, is intended to ensure that any content they submit is appropriate for display on the live site. As the feature currently exists in Alfresco, it is possible, for example, for the author to set themselves as the approver of their change set, completely circumventing the approval process that has been put in place.
While there is an open enhancement request (ENH-466) requesting that these controls be removed, many implementers need to be able to remove them immediately, on versions of Alfresco where this enhancement request has not yet been implemented.
Luckily there's a straight forward way of doing this, albeit one that requires modification of a core Alfresco JSP†. The UI for the Submit Items dialog is rendered by a single JSP in the Alfresco Explorer UI:
At around line 104 (on Enterprise 3.2r - it may be slightly earlier or later in the file on other versions) the following two <h
anelGrid> blocks appear:
Removing the ability for authors to select a different workflow and/or reconfigure the selected workflow is as simple as commenting out both of these blocks, using JSP style comment tags (<%-- and --%>). The result appears as follows:
[caption id='attachment_246' align='aligncenter' width='499' caption='Screenshot: No Ability to Select or Configure Workflow']
[/caption]
As you can see, the entire Workflow section of the Submit Items dialog has now been removed, and the user no longer has the ability to select a different workflow or reconfigure it.
While it may be tempting to simply modify the JSP directly in the exploded Alfresco webapp, it is critically important to understand that doing so is unsafe. Specifically, Tomcat may choose to re-explode the alfresco.war file at any time, overwriting your changes without warning and thereby reverting the Submit Items dialog to the default behaviour.
A better approach is to package up the modified JSP file into an AMP file, and deploy it to other environments (test, production, etc.) using the apply_amps script or the Module Management Tool. Packaging the JSP as an AMP file also allows you to 'pin' the change to a specific version of Alfresco (via the module.repo.version.min and module.repo.version.max properties, described here), which is also important to prevent someone accidentally installing an older version of the JSP into a newer version of Alfresco (which can create other, difficult-to-track-down issues in Alfresco).
† Please note that modifying core Alfresco code (even JSPs) will technically invalidate support for the installation if you are a subscriber to Alfresco's Enterprise Network - this should not be done lightly! In this case, however, the risk of unexpected side effects is minimal and although the change will need to be manually re-applied every time the installation is upgraded, there are ways of pro-actively managing that risk.
[caption id='attachment_243' align='aligncenter' width='500' caption='Screenshot: Configure Workflow at Submit Time']
The obvious issue is that typically authors should not have the ability to influence the approval process, which, after all, is intended to ensure that any content they submit is appropriate for display on the live site. As the feature currently exists in Alfresco, it is possible, for example, for the author to set themselves as the approver of their change set, completely circumventing the approval process that has been put in place.
While there is an open enhancement request (ENH-466) requesting that these controls be removed, many implementers need to be able to remove them immediately, on versions of Alfresco where this enhancement request has not yet been implemented.
Luckily there's a straight forward way of doing this, albeit one that requires modification of a core Alfresco JSP†. The UI for the Submit Items dialog is rendered by a single JSP in the Alfresco Explorer UI:
/jsp/wcm/submit-dialog.jsp
At around line 104 (on Enterprise 3.2r - it may be slightly earlier or later in the file on other versions) the following two <h
anelGrid> blocks appear:<h:panelGrid columns='1' cellpadding='2' style='padding-top:12px;padding-bottom:4px;'
width='100%' rowClasses='wizardSectionHeading'>
<h:outputText value=' #{msg.workflow}' escape='false' />
</h:panelGrid>
<h:panelGrid columns='1' cellpadding='2' cellpadding='2' width='100%' style='margin-left:8px'>
<h:panelGroup rendered='#{DialogManager.bean.workflowListSize != 0}'>
<h:outputText value='#{msg.submit_workflow_selection}' />
<h:panelGrid columns='2' cellpadding='2' cellpadding='2'>
<a:selectList id='workflow-list' multiSelect='false' styleClass='noBrColumn' itemStyle='padding-top: 3px;'
value='#{DialogManager.bean.workflowSelectedValue}'>
<a:listItems value='#{DialogManager.bean.workflowList}' />
</a:selectList>
<h:commandButton value='#{msg.submit_configure_workflow}' style='margin:4px' styleClass='dialogControls'
action='dialog:submitConfigureWorkflow' actionListener='#{DialogManager.bean.setupConfigureWorkflow}' />
</h:panelGrid>
</h:panelGroup>
<h:panelGroup rendered='#{DialogManager.bean.workflowListSize == 0}'>
<f:verbatim><% PanelGenerator.generatePanelStart(out, request.getContextPath(), 'yellowInner', '#ffffcc'); %></f:verbatim>
<h:panelGrid columns='2' cellpadding='0' cellpadding='0'>
<h:graphicImage url='/images/icons/warning.gif' style='padding-top:2px;padding-right:4px' width='16' height='16'/>
<h:outputText styleClass='mainSubText' value='#{msg.submit_no_workflow_warning}' />
</h:panelGrid>
<f:verbatim><% PanelGenerator.generatePanelEnd(out, request.getContextPath(), 'yellowInner'); %></f:verbatim>
</h:panelGroup>
</h:panelGrid>
Removing the ability for authors to select a different workflow and/or reconfigure the selected workflow is as simple as commenting out both of these blocks, using JSP style comment tags (<%-- and --%>). The result appears as follows:
[caption id='attachment_246' align='aligncenter' width='499' caption='Screenshot: No Ability to Select or Configure Workflow']
As you can see, the entire Workflow section of the Submit Items dialog has now been removed, and the user no longer has the ability to select a different workflow or reconfigure it.
A Note about Packaging
While it may be tempting to simply modify the JSP directly in the exploded Alfresco webapp, it is critically important to understand that doing so is unsafe. Specifically, Tomcat may choose to re-explode the alfresco.war file at any time, overwriting your changes without warning and thereby reverting the Submit Items dialog to the default behaviour.
A better approach is to package up the modified JSP file into an AMP file, and deploy it to other environments (test, production, etc.) using the apply_amps script or the Module Management Tool. Packaging the JSP as an AMP file also allows you to 'pin' the change to a specific version of Alfresco (via the module.repo.version.min and module.repo.version.max properties, described here), which is also important to prevent someone accidentally installing an older version of the JSP into a newer version of Alfresco (which can create other, difficult-to-track-down issues in Alfresco).
† Please note that modifying core Alfresco code (even JSPs) will technically invalidate support for the installation if you are a subscriber to Alfresco's Enterprise Network - this should not be done lightly! In this case, however, the risk of unexpected side effects is minimal and although the change will need to be manually re-applied every time the installation is upgraded, there are ways of pro-actively managing that risk.
1 Comment
