Description of problem: @37406/Postgres To reproduce: 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 type? Perhaps it makes more sense to not apply a default workflow at all anymore, and to have that be a separate administrative task.
reassign
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. 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.
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.