When I go to Triggers>Workflow, only 7 random content types are shown with workflow state changes. I have approximately 25 different content types... I think it was a little easier with the previous Actions where you would select a workflow and then go to an actions page that was specific to only that workflow... not sure if it's possible for version 2.x.

Comments

jvandyk’s picture

First, they should not be "random content types". They should be content types to which you have assigned a workflow at Administer - Site building - Workflow.

Second, I agree. The UI has taken a step backwards. My goal was first to support Drupal-6-style triggers in preparation for the Drupal 6 port, with UI improvements to come later. The problem is currently that hook_hook_info()'s support for automatic menu generation does not extend to second-level local tasks. Ideas and patches accepted.

hillaryneaf’s picture

It appeared to be random because I have 13 content types assigned different workflows at Administer - Site building - Workflow. But then I realized where the magic number of only 7 different content types coming up. I have only 7 workflows but some content types use the same workflow. It looks as though it's pulling up only 1 content type for each workflow and ignoring the rest. This isn't the correct behavior is it? Can anyone else reproduce this?

jvandyk’s picture

Project: Actions » Workflow
Version: 5.x-2.4 » 5.x-2.x-dev
Status: Active » Fixed

I have redone the UI for workflow triggers. They are now presented as second-level local tasks by workflow name. If you have multiple content types using the same workflow, all triggers for both will be listed under the second-level local task for that workflow.

Internally, the structure of hook operation names has changed. When updating from 5.x-2.2 to 5.x-2.x-dev (or 5.x-2.3 when it is released) remember to run update.php so that your action assignments will be preserved.

Please test this and report any problems here. Use the 5.x-2.x-dev tarball dated May 6, or use CVS to get revision 1.54.2.28 of workflow.module.

hillaryneaf’s picture

It works excellent! Thank you!! The UI is much improved too!

hillaryneaf’s picture

Status: Fixed » Active

I found another bug... After assigning quite a few display messages and send email actions to workflow transitions in the Triggers, I get this message:

user warning: Data too long for column 'op' at row 1 query: INSERT INTO actions_assignments values ('workflow', 'workflow-homepage_section_article-5', '5', 1) in C:\Apache2.2\htdocs\connections\includes\database.mysql.inc on line 172.

Is there a limit to how many actions you can assign? Can it be lifted?

hillaryneaf’s picture

Ok.. I investigated further and it doesn't seem to be a limit to how many actions you can assign... the error only comes up for that specific content type's workflow transitions (homepage_section_article). Any idea what could cause that error?

jvandyk’s picture

If you've found another bug, please open another issue. One issue per bug.

The op column of the actions_assignments table of the actions module is 32 characters. You have more than 32 characters. You can alter the size of that column in the database to solve the problem. We will need to update the actions module to increase the column width to something more reasonable.

hillaryneaf’s picture

Status: Active » Fixed

Sorry I should have opened another issue. I didn't know if it was related to the new 5.x-2.x-dev tarball dated May 6 or not... I changed the name of the content type to be less than 32 characters and it works fine now.

Thanks again!

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

hillaryneaf’s picture

Status: Closed (fixed) » Active

After installing the 5.x-2.x-dev tarball dated May 6, (CVS revision 1.54.2.28) of workflow.module, If I edit an existing workflow (or add a new workflow!) and change the permissions (add a user to do state changes, etc.) and then save the changes, it completely removes my primary links menu. Any ideas what causes this... or how to fix it? I've reproduced the problem...

gnassar’s picture

Component: User interface » Code
Priority: Normal » Critical

Goodness gracious! I was wondering why my menus were getting deleted. You're right -- that's why. Problem confirmed.

jvandyk’s picture

Status: Active » Closed (fixed)

This issue, which relates to a bug where some content types were not showing up, is closed.

If you have found a bug with workflow, please create a new issue by going to the workflow project page and clicking the "Report new bug" link.

One bug per issue, please.

gnassar’s picture

Beat me to it. :-) Realized that after changing the issue settings. Reposting in separate issue.

#264344: Changing permissions deletes menu