[drupal-devel] [task] Better default workflow

stefan nagtegaal drupal-devel at drupal.org
Sat Jan 22 09:28:37 UTC 2005

 Project:      Drupal
 Version:      cvs
 Component:    node system
 Category:     tasks
 Priority:     normal
 Assigned to:  drumm
 Reported by:  drumm
 Updated by:   stefan nagtegaal
 Status:       patch

Wow, i really like this patch!
This implementation is very clean and looks consistant with the way the
input format's are configured. (Which is imo one of the best UI we
+1 for this..

stefan nagtegaal

Previous comments:

December 10, 2004 - 03:27 : drumm

Attachment: http://drupal.org/files/issues/types1.png (8.05 KB)

This is a screenshot of the page replacing the 'default workflow.'


December 10, 2004 - 03:29 : drumm

Attachment: http://drupal.org/files/issues/types2.png (18.41 KB)

This is what you get by clicking 'configure.'


December 10, 2004 - 04:01 : drumm

Attachment: http://drupal.org/files/issues/default_workflow.diff (10.79 KB)

The default workflow page quickly becomes usuable as modules are added.
I think it works much better broken up into one page per content type.
This is a very basic patch which simply moves around the UI and does
not change any functionality.

I see lots of potential in following this path:
* The submission guidelines would make sense on this page. Have the
node module put those in, no need to have it duplicated in all the
* This page could be moved around to be a top level admin menu with
local tasks 'list' and 'add new type' for making lightweight types on
the fly instead of the very lightweight modules we have now.
* Permissions for who can create nodes or edit their own might make
sense on or next to these pages.
* The various elements of the create content form, or even the node
view, could be reordered with weights.

This requires modules implementing hook_nodeapi('settings') to return
strings containing the form elements instead of associative arrays.


December 10, 2004 - 04:09 : moshe weitzman

Perhaps we could preserve the overview of all node types and settings in
read only table view. then an edit click would lead to the form you
show. i think the overview of all settings at once is useful sometimes.


December 10, 2004 - 09:35 : Dries

This is a step in the right direction but the patch needs to evolve a
bit before it is commit-worthy.  For one, I would use form_group()
rather than a form_item-hack.  For consistency, table headers should
start with a capital letter.  Furthermore, I support the idea of
creating a more prominent workflow-menu.  Moving the story and forum
settings to this page, might make sense, although I'm not sure people
expect to find the 'submission guidelines' or 'forum structure
settings' under 'workflow'.  I guess it would work.  Either way, this
patch has potential so keep working on it.


December 10, 2004 - 16:57 : tostinni

Is this : Configure Workflow by roles [1] could be a way of improvement
to ?
Good ideas for the patch, thanks.
[1] http://drupal.org/node/13129


December 16, 2004 - 23:22 : Dries

The statistics module's "Display node counter" setting could be part of
the workflow system (that or it should be added to the theme's "Toggle
display" settings).  Similarly, the "Display post information on"
setting on the global theme configuration page might be better of being
part of the workflow system.


December 17, 2004 - 10:55 : Bèr Kessels

Display and rendering setings should always be part of the theme
settings, and preferably only the global settings. they have nothing to
do with workflow, and will confuse people if they are "hidden"there.
Similar to the "permissions" for upload, that are (were?) hidden there,
since uploading has little to do with "allowing uploads".


January 21, 2005 - 01:26 : drumm

Attachment: http://drupal.org/files/issues/default_workflow_0.diff (16.22 KB)

Here is a cleaned up patch which:
- Capitalizes the column headers
- Uses form_checkboxes() instead of the form_item() hack

Because I wanted to use form_checkboxes() rather than a form_group() I
had to make those 5 variables into one array. There is an update to set
the one variable per node type to the values of the five old ones, and
delete the five. I have not benchmarked the difference of one array per
node type in the variables table vs. five booleans (ints) per node type,
but I expect it might be faster.

I do have more ideas for what should be done once this first step is
- I think 'content types' should be a menu item in the navigation menu,
not a local task. This will let us put a 'add content type' tab in the
logical place when/if it is time to do that. Also this page is buried
- I think that the submission guidelines and minimum words should go on
these pages.
- I think form_group() should be used once the form grows. We could
stick what we have now in a 'Workflow' fieldset.
- I think that the 'settings' $op of hook_nodeapi() should be rethought
and maybe put in another hook.
- I think that node create/edit permissions could go on these pages.
- I think that this form should have a 'save' $op and use
system_settings_save() because that limits what modules can do to using
- I think that there should be a 'validate' $op so modules can do
- I think that the five options should be rethought.

However, these are all separate issues which should have their own
patches and debate and many will have to wait until 4.7. But this gets
the door open for modules and ideas in 4.6.

I'm willing to put more in the overview table, but I would like input
on what it should look like to avoid width problems and be as usable as
possible moving forward. Perhaps that should wait for another patch?


January 21, 2005 - 01:32 : drumm

BTW, I consider the added 'else' in system.module to be a bugfix. I'm
not exactly sure why system_settings_save() does a drupal_goto(), but
it helps make the form act a lot more predictably if it does the same
type of returning or goto for whichever button is pressed.

View: http://drupal.org/node/14170
Edit: http://drupal.org/project/comments/add/14170

More information about the drupal-devel mailing list