 |
Support Extranet
|
|
|
Core Feature or Module - New Publishing Workflow and Notifications - COMPLETED
The functions in this briefing document were added to the core version of cm3 during the version 4.x series of releases. They are now available to all customers.
2008-12-14: This draft specification is subject to change without notice.
Index
- Introduction
- Core Feature or Module?
- The Customer Brief
- Project Detail
- Timeframe
Introduction
This document outlines the modification of cm3's core publishing workflow modules to accommodate review, "unpublishing" events, publishing job notifications, review and publish status permisions, and other new features related to distributed authoring for larger publishing communities.
This project is underway due to the requirements of a particular customer, but we have extended the scope of the requirement to include a range of additional features that are already on the cm3 product development roadmap. We have included the original customer brief in this proposal for general reference.
The functinality requested in the customer brief appears to be relatively simple on the surface, but it reaches deep into the process of content management and therefore affects cm3 at a fairly basic level. The good news is that the changes requested in the brief have been anticipated, so the foundation for this project has already been built. For instance cm3 already has a concept of "ownership" that will be applied to the requested notification system.
Our approach to this project will be to modify the core cm3 publishing module, rather than to apply once-off customisations specifically for this project. The amount of work to achieve the end result is substantially higher, but these modifications are useful to all users of the product and something we have been planning to implement ourselves. The net result will be a more robust publishing module that will have guaranteed future support as well as additional functionality that was not requested.
This document assumes deep familiarity with the cm3 software and associated language.
Core Feature or Module?
At this stage we have not made a final decision about whether this upgrade will be included in the core cm3 system for all users, or whether it is an extended module. Our plan is to create this functionality as an extended module due to the complexity of the system and the fact that it will not be needed by all users. If customer demand is overwhelming we may reconsider this approach.
The Customer Brief
We have included the original customer brief in this proposal for general reference:
" I have decided on a two-level authoring and approval process. I had considered both a single and three-level process but discounted because of either too little or too much process - I think two is just right! Of course site administrator status should remain and include all options slated below.
DISTRIBUTED AUTHORING
-
Assign page owners and approvers to each page (both container and article levels)
-
For pages under review the following occurs: (Note this might need to be an optional functionality as there may be some pages that have short life spans and should expire automatically without intervention)
1. Four weeks prior to page expiry an email is sent to Owner to begin review process
-
Once the review process has begun page expiry dates can be amended to provide content authors and approvers more time
-
Email contains a link directly to admin site page editing form
2. One week prior to page expiry an email is sent to both Owner and Approver to alert to page's imminent expiry
-
Email contains a link directly to admin site page editing form
-
Develop a workflow so that the following occurs for both new pages and pages under review:
1. Owners can only:
-
'Save changes' (for later author review; this action causes the page to remain unpublished for new pages or go offline for pages under review)
-
'Save and request publish' (possibly rename 'Send to Approver') (email notification sent to Approver; this action causes the page to remain unpublished for new pages or go offline for pages under review)
2. Approvers can only:
-
'Return to Owner' (add a 'notes' field so that instructions can be passed along; email notification sent to Owner; this action causes the page to go/remain offline)
-
'Save and publish now' (send new or updated page live to the internet)
Note the theory behind pages going offline when in a 'saved' state of review is so that we don't have two versions of the same page. And this will obviously require a lot less functionality."
Project Detail
Project Overview
The following features will be incorporated into the cm3 publishing workflow system. This is a draft specification only. It has been designed from a best practises viewpoint in order to assure that meeting the CCV workflow requirements is handled in a truly modular fashion.
A Note About Multiple Versions
The assumption that pages need to disappear from live view when they enter a review process has been ignored in our specification. This is because cm3 already supports multiple article versions for development and live views, so the assumed technical constraint does not exist.
Ownership
- The existing concept of article ownership in cm3 will be expanded. Currently the person who creates an article owns the article. This will continue, but ownership will become a "transferrable" right.
- Two new permissions will appear in the container permissions sheet
- Change ownership - Users with this permission may alter a single article to be owned by any other content author.
- Take ownership - Users with this permission may acquire ownership of a single article, but may not assign it to other users.
- In order to address the risk of orphaned articles when an author is deleted from the system, an author may not be removed from the system unless they do not own any articles.
- An administrative function will be added to view all articles owned by a particular author. The administrator may change the ownership of individual articles.
- An administrative function will be added to transfer the ownership of all articles from one author to another author.
- Note: Depending on the performance of other parts of this project, the two functions outlined above may be left for a future update. If this is the case, when authors leave the organisation their account may simply be altered to the details of the person that takes there place.
- In the central website search authors will be able to tick a box saying "show only my own articles"
Notes on Articles
- A notes field will appear on the article edit form
- Notes will be recorded as separate items against each article, i.e. each new note will be separate to the last
- Any authors with view permission will be able to click a button to see a history of all notes
- The most recent note will be visible on the article editing screen
- Notes will be visible as individual events in the audit log
- The Administrator can delete content of notes, but not the log of the note
- An "Add Note" button will appear for stakeholders who don't have edit permission on the article - anyone with review or publish permission may add a note at any time
Publishing Event Dates
- Publishing event dates will be added to the core publishing system (as opposed to being available as dynammic metadata fields like in the current system).
- Can configure individual dates to appear or not, e.g. on content types
- Can configure dates to be editable by authors or reviewers
- A start date
- Two review dates
- An end date
- The following options will be available to the article author for actions to take at the end date:
- Notify owner - The owner is notified by email and in the jobs system that the article has expired.
- Notify owner and reviewers - The owner and any publishers/reviewers are notified by email and in the jobs system that the article has expired.
- The selectable options may be set to a system wide default within the core cm3 configuration.
- The selectable options may be disabled within the core cm3 configuration, forcing the system wide default to be used for all articles.
- A setting for each content type will specify whether the start, review, and end dates may be set by authors. If authors may not set the dates then reviewers/publishers may set the dates if they have edit permission on the article.
"Publish" Becomes "Publish Approval" and Publishing Workflow is Altered Slightly
- Since publishing is now based on dates rather than on a button clicked at a certain moment in time, the system language will change:
- "Publish" becomes "Approve for Publish"
- "Request Publish" becomes "Request Publishing Approval"
- Once an article has been approved for publishing it will move to the right column of the CMS publishing window (currently known as the "live" area) irrespective of the start and end dates
- The right column of the CMS publishing window will change from "Published" to "Publish Status". The published date will no longer be visible (since it is now a collection of dates - e.g. start, end, review), and each article will show one of four publishing status settings:
- Never Published
- Approved / Pending
- Live
- Expired
- Clicking on any of these status settings will show a "read only" view of the article that was approved for publishing
- The middle column of the CMS publishing window (currently called "Publish Status") will be renamed to "Workflow Status" and will show the article's current position in the editing workflow:
- Author Mode (currently "Edit Mode")
- Review Mode
- Awaiting Publishing Approval
- Other options such as unpublish and delete...
- In the middle column of the CMS publishing window if the last action that took place was a backwards workflow step (e.g. publishing approval denied or review denied), a small note will appear to this effect.
- The left column will remain as "Modified" and will always show the last date that the article was modified. Clicking on the modified date will show the audit trail of edit and publishing events.
- The pull-down list of saving options on the article editing screen will be altered:
- Save Changes
- Save & Send Back to Author Mode
- Save & Request Publishing Approval
- Save & Approve for Publish
- Note: As with the current system, only the options for which the user has appropriate permission will appear
- The publishing popup window will contain new options. Only the options for which the user has appropriate permission will appear:
- Author Mode (currently "Edit Mode")
- Request Publishing Approval
- Approve for Publish
- Unpublish and delete options as appropriate
- If in the publishing window a publisher decides to switch an article from "request approval" mode back to author mode, they will be prompted to enter a note to explain why
Review Mode
- A new level of permission will be added called "Review"
- Articles must pass the review level before they can be approved for publish
- If a user has both review and publish permission they may bypass the review step and go directly to publishing approval
- The review permission is group based. Once an article enters review mode all users in a group with review permission will be able to perform the following actions:
- Request the article to be approved for publishing (i.e. send it to publishing)
- Send the article back to the author (i.e. request further updates before sending it to publishing)
- The pull-down list of saving options on the article editing screen will be altered:
- Save Changes
- Save & Send Back to Author Mode
- Save & Request Review
- Save & Request Publishing Approval
- Save & Approve for Publish
- Note: As with the current system, only the options for which the user has appropriate permission will appear
- The publishing popup window will contain new options. Only the options for which the user has appropriate permission will appear:
- Author Mode (currently "Edit Mode")
- Request Review
- Request Publishing Approval
- Approve for Publish
- Unpublish and delete options as appropriate
- If in the publishing window a publisher decides to switch an article from "request approval" mode back to author mode or reviewer mode, or if a reviewer decides to switch an article back to author mode, they will be prompted to enter a note to explain why
Event Notifications
- Notifications will be sent by email and also recorded in the jobs system (see below)
- All reviewers will receive a notification when an article enters or exits review mode (from either the author or publisher direction)
- All publishers will receive a notification when publish approval is requested
- Article owners will receive a notification if an article is sent back to author mode
- Notifications will be configurable separately for each of the article publishing dates by way of tick boxes:
- Owner
- All users with edit permission
- Reviewers
- Publishers
- Administrators
- Defaults for notification settings will be set on each content type
- For each content type, the CMS to be configured so that the default settings are the only notifications available, or so that authors may override the default notification settings on an article by article basis
- Three options for notification sending can be set on a system wide basis:
- Immediate notifications for all events
- Scheduled report, i.e. a report goes out on a defined schedule outlining all articles waiting in various review and publish modes
- No notifications (users must check the jobs system or CMS publisher system to view article reports)
- Administrators may opt to receive immediate notifications, scheduled reports, or no notifications at all. This is a system wide setting.
- If the Administrators receive immediate notifications they will see an opt-out tick box on all publishing option screens and the article editing screen: "Do not send a notification for this event". In smaller environments this will avoid the need for a single Administrator to receive their own spam.
- If the "immediate notifications" option is switched on each notification will contain a pointer (and direct link) to the edit form for the article in question, the last relevant note recorded against that article in the article system, and a summary report of all articles waiting within this user's content publishing area. (The summary report avoids the need for users to manually cross reference all emails, and also avoids the need for reviewers to double check to see if an article has already been approved by another reviewer.)
Simple Messages / Jobs System
- A simple jobs listing system will be created for the cm3 administrative console
- Each job article will consist of the following fields:
- Title / short description
- Notes / long description
- Message type - E.g. Personal Job, Job Request, Review notification, Publish notification
- Job requested by
- Priority
- Posted date
- Target date
- Closed date
- Users can view and edit "My Jobs", i.e. any jobs assigned to them
- Any author may add any number of jobs for themselves
- Any author may post a job request to any other author. Once a job has been requested of another author, the recipient of that job owns the job. The creator of the job has no permission to update the job details in any way.
- In addition to being sent by email, all publishing notifications will be listed in the jobs system
Further Notes
- The article audit logs will be updated to show all relevant events
- Pages do not need to go offline once they reach the second review point (as requested) since cm3 already supports separate live and working versions of articles. Pages will only go offline at the second review date if the appropriate expiry option has been selected.
Assumptions
- This proposal outlines a draft specification for the publishing system updates only. Please note that due to the complexity of CMS publishing this specification goes far beyond the basic requirements. (In order to follow a best practise approach this is a necessity.) The specification may change at DDSN's complete discretion, however we are happy to guarantee that the basic requirements of the customer brief be met as a minimum.
Timeframe
The new publishing workflow module is expected to be available in February 2005.
Date: 2004-12-14
|
|
