You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

From Kevin Cochrane's email April 05 email:

Please note that for 2.1.0, we intend to provide the following enhancements to the workflow GUI:

*  Comment capture on task transition
*  Workflow history within task details (completed tasks along with associated comments; current active tasks)
*  Comment capture on individual files (under investigation; potential to push to post 2.1.0 release)
*  File comment history within task details

In addition to addressing commenting and history in workflow, we will be also adding support for:

*  Task timers
*  Launch and expiration date capture in submit dialog
*  GUI support for viewing queue of timed launches (incl. ability to preview, immediately launch, change launch date)
*  Updated default workflow to include content launch
*  New WCM workflow for content expiration (automatically instantiated based on content expiration)

Task timers can also be used outside the context of content launch for workflow escalation handling (up priority, reassign
to other users, groups, or managers).  We will investigate adding escalations into the default workflow as well, though
this update to our default workflow will likely punt to a post 2.1.0 maintenance release.

We have finalized our initial pass at deployment (which is only Alfresco to Alfresco currently; Alfresco to file server to
come).  We are now working on the following items:

*  Locking
*  Search
*  Links management
*  Content launch and expiration

Once work on content launch and expiration is complete, we will be turning our attention to workflow GUI enhancements
(likely timeframe:  May).  Prior to initiating that work, we will do a thorough review of MIT's JIRA workflow issues and confirm
those that we intend to fix for the 2.1.0 release.
 -----------------------

WORKFLOW WISHES

FOR AUTHORS:

* Make it easy for techwriter to find workflow information on their
  projects. Suggest it be accessible from their sandbox, from the modified
  documents list, since that's where users do their work.

* Expect techwriters to be working on multiple documents and multiple projects
  at a time. UI should help techwriter see changesets of related documents rather than a
  long list.   Ex: techwriter has modified 50 documents as part of three
  changesets. Help them view it as three changesets, instead of a list of 50
  documents.

* Help users easily determine the status of their projects. Perhaps selecting
  a changeset opens a status screen, showing which files are included, what
  workflow (including version) were applied, what workflow stage it's in now,
  if reviewed, who has reviewed it and who is holding things up.

* View workflow/changeset history from document - planned for 2.1.0
  Scenarios: author wants to know who last made a change, what it was; similar
  to a developer consulting source control system to see when a file was last
  changed and who did it.

* Useability question on completed tasks portlet: how long can that list get? Will it be useable 100+ completed tasks for now?
Limit number displayed, add pagination or something.

* Thumbs up on default settings for workflows! Continue to minimize the
  author's need to mess around with configuration.

FOR REVIEWERS:

* Make it easy for reviewer to see what changed in this version of a document: support diffs, or ability to
  see both the current head version from the staging sandbox as well as the
  version under review

* Make it possible to send URLs for previews in mail. ( ?? Thought I saw a
  remark in the forums that the document URL wasn't available through Freemarker).

* Make it obvious when a user has a task waiting. Show "My Tasks" and "My Pooled Tasks" portlets by default.

* Want to continue using URLs on the virtualisation server for review rather
than requiring users to log in to Alfresco. Content reviewers may come from any part
of the Institute, and we'd rather not make an account for each of them.

  Scenario: a press release goes out; it must be reviewed by someone from
  Legal, Professor So-and-so from the Whatsis Department, and someone from the
  public relations department.

* Would like a web- or email- based way to respond to review requests, since
  users are more accustomed to web pages than loggin into Alfresco.

Example:  user gets an email notification that something requires review; user
is given a URL on the virtualisation server. The page contains links to
preview each of the changed files and buttons corresponding to the workflow
transitions.

* Make it obvious when a user has a task waiting; Show "My Tasks" and "My Pooled Tasks" portlets by default

* Need a way to nag/remind reviewers easily

* Would like expiring review tasks -- to be included in 2.1 . An expiring task
  might say "if you don't respond by Friday, this will automatically be approved."

FOR MANAGERS:

* Be able to change workflows into different states. May wish to apply
  permissions to thigns - only author may, or only people with publisher or
  manager role in that project space.

* Be able to modify assignees

FOR ADMINISTRATORS AND ENGINEERS:

* Need a better workflow  admin console, which might include:
    * a list of all workflows, with friendly names, not jbpm$123
    * a way to click through a particular workflow to process definition
    * a list of versions of all deployed workflow, and their process definition
    * a list of in-flight instances, with enough information to identify
    * a way to change workflow state;  a representation of the workflow and
    transitions that lets me know what states I can request
    * ?? transitions should run whatever events etc. are specified in the
    process definition, like AVMClearSubmittedHandler, so doc is actually
    submitted - does it do this when it's nudged from the admin console?

Scenario: a user tells me they kicked off a document workflow and it doesn't
work. Help me find the document and debug the workflow.

Scenario: I want to deploy a new version of an existing workflow. Help me see
what workspaces, forms, and in-flight documents are affected by that.

* Need a way to gracefully undeploy a workflow.

* A simplified way to write and deploy workflows for use in the webclient.  Right now I have to
  - create a process definition file
  - create or modify a workflow model
  - add labels to messages file
  - add UI components to web-client-config-wcm.xml
  - add items in 2 places in bootstrap-config.xml

For comparison - NetBeans does a nice job assisting with deployment
descriptors.

* Would prefer not to restart the server to make a workflow available to the
  WCM. We're committing to 24x7 uptime and need to minimize restarts.

  • No labels