Red Hat Bugzilla – Bug 108155
Default workflow not applied to new items
Last modified: 2007-04-18 12:58:49 EDT
Description of problem:
Create a new item
The default workflow is not applied.
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
Perhaps it makes more sense to not apply a default workflow at all anymore, and
to have that be a separate administrative task.
needs to be documented; adding cjt to cc
This bug applies to default lifecycle for added content types as well.
Change 37810 assigns an arbitrary workflow and lifecycle. This is
clearly an interim fix.
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.
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
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
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.
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.
We will do option #2.
Upon further discussion with Randy, Jon, and Justin, the lowest effort
/ best return option seems to be to document option #1.