Bug 108155 - Default workflow not applied to new items
Summary: Default workflow not applied to new items
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise CMS
Classification: Retired
Component: content types
Version: nightly
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: ccm-bugs-list
QA Contact: Jon Orris
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 108949 106481
TreeView+ depends on / blocked
 
Reported: 2003-10-28 04:26 UTC by Jon Orris
Modified: 2007-04-18 16:58 UTC (History)
1 user (show)

(edit)
Clone Of:
(edit)
Last Closed: 2006-01-06 15:45:05 UTC


Attachments (Terms of Use)

Description Jon Orris 2003-10-28 04:26:23 UTC
Description of problem:
@37406/Postgres

To reproduce:
Create a new item
The default workflow is not applied.

Comment 1 Jon Orris 2003-10-28 20:30:32 UTC
I spoke with Randy regarding this. He thinks it was a simple oversight on his
part not to add this bit of functionality.

OTOH, as we thought about it, we raised the question as to whether a 'default
workflow' makes sense in the new scheme of things. Before, the types were
automatically added when you created the 'content' content section, which has
the single 'Production Workflow' added. 

Now we're loading types separately, and at an arbitrary time after server
initialization. It's possible that multiple Workflows may be created before one
loads, say, the Job type. In that case, what is the 'default workflow' for this
type?

Perhaps it makes more sense to not apply a default workflow at all anymore, and
to have that be a separate administrative task.


Comment 2 Richard Li 2003-10-30 15:28:05 UTC
reassign

Comment 3 Richard Li 2003-11-03 15:55:51 UTC
needs to be documented; adding cjt to cc

Comment 4 Archit Shah 2003-11-07 15:46:18 UTC
This bug applies to default lifecycle for added content types as well.

Comment 5 Archit Shah 2003-11-07 16:16:44 UTC
Change 37810 assigns an arbitrary workflow and lifecycle. This is
clearly an interim fix.

Comment 6 Jon Orris 2003-12-08 16:41:42 UTC
I still agree with my original comment. This is fundamentally a
requirements problem brought about by our re-packaging changes. We
need to decide what lifecycles & workflows should be applied to newly
loaded content items. 

Options: 
1) Don't assign anything. Leave to site administrator to do.
Pros: Almost zero engineering & QA resources involved; essentially
roll back 37810.
Cons: This may be a problem when loading a lot of content types. Since
we have no bulk admin functionality, it will be a real pain for the
user to go through 30 types, choosing the same workflow & lifecycle
for each.

2) Assign all newly loaded types to the default workflow & lifecycle.
This is what is done presently, though it requires more work. 37810
causes types to be assigned to an arbitrary workflow & lifecycle.
Until any new workflows & lifecycles are created, this happens to be
the default ones created by the system.

Pros: Minimal QA time, (probably) minimal engineering time to fix
correctly. Consistent with original system behavior. Allows all newly
loaded types to be usable 'out of the box', especially good if you're
setting up a new system with lots of types.
Cons: Has the same cons as option 1. If the admin wants all new types
loaded assigned to a different default workflow/cycle, it is still a pain.

3) Create a bulk UI for assigning content types to lifecycles & workflows.
Pros: Easy to use for the administrator.
Cons: Entirely new functionality with unknown Engineering & QA time.
Probably a 'medium sized' feature request that would take 1-2 weeks
QA/Eng time. (NOTE: This is only an estimate. Could be worse.)

4) Do something for content type loading that allows: 
 * Content types to be assigned to any section specified
 * Content types to be assigned any existing workflow & lifecycle
specified.

Pros: Very flexible for the user.
Cons: Entirely new development. Would require in addition fully moving
section initializers out of the legacy enterprise.init. This is likely
'Large sized' feature development, likely to take a month _at the
minimum_ to hash out all the requirements details, implement,
re-implement with newly discovered sub-requirements, and test.


Given these options, I think that 1 is preferred, with 2 almost as
preferred. These options are most consistent with pre-existing
functionality, and carry minimal risk.



Comment 7 Randy Graebner 2003-12-08 17:10:40 UTC
I have not yet met a customer that has used our workflow/lifecycle out
of the box.  Every site that I have seen has used the admin UI to
change the workflow/lifecycle and they go through each content type
one by one.  They all ask if there is a better way to do it but do not
complain too much since it is a one time thing.  I think that a
combination of 2 and 3 would be ideal...have every type get a default
but make it easy to change.

Even if we decide to do 1 or 2 only, I think that adding 3 as a
feature for down the road is a good idea and would help make CMS more
user friendly.  And, if we implement 4, then the benefit from
implementing 4 would be minimal at best.


Comment 8 Richard Li 2003-12-09 19:37:17 UTC
We will do option #2.

Comment 9 Richard Li 2004-01-08 20:41:31 UTC
Upon further discussion with Randy, Jon, and Justin, the lowest effort
/ best return option seems to be to document option #1.


Note You need to log in before you can comment on or make changes to this bug.