Drupal 7 version of Workflow, features

I too noticed this, and was curious. I don't see any slated or promised D7 release on the Workflow module page, so ... ? :)

I actually spent some time today looking at how workflow would work in D7. Perhaps as a module that exposes a field.

The workflow setting is a bug. I added #742458: Default publishing options still has 'workflow' phrasing to fix it. D7 is in feature freeze, so no new features will be added.

@jvandyk: How do you feel about merging workflow with rules in D7? Their similarities far outweigh their differences and fago is well underway with the rules upgrade.

subscribing

subscribing

It would be nice if workflow could be applied to any fieldably entity, which is what making it a field would support that, though that would not be well workflow_access would not be usable with much outside of nodes unless it turns into a sorta API.

As far as workflow merging with rules, I would probably prefer they remain separate, but with workflow continuing to integrate with rules.

hefox, hush, you are leaking my core dev summit talk! :)

opensanta, workflow and rules are different things. Maybe you mean actions/triggers and rules? Hope to meet with fago about that in SF.

Stu-Druwser, I think you have misunderstood? Fieldable entities are things like nodes and users. We're not talking about attaching workflows to individual fields themselves.

Sooo..... is anyone working on workflow for d7 then?

I believe the maintainers are. Most likely a post San Fran DC activity.

subscribing.

A good idea to redesign #723310: Break workflow into smaller modules

Funny, I just thought to check out the queue to see if there was work on a D7 upgrade and if any of the work in #723310: Break workflow into smaller modules would apply.

Breaking the modules up would also allow for other kinds of entities to be workflowed, to hefox's point. The breakup project is really close to having "transition entities" that could be pretty agnostic about what they were working on, and adding a "User API" or the like wouldn't be too much.

Anyone have a status update on the D7 version or thoughts on the breakup proposal? I'd be willing to take a stab at redoing it for D7 if people are on board with the architecture.

subscribing

Subscribing

Subscribing

subscribing

sub

Subscribing

subscribing

If there's no Drupal 7 version of workflow, is there any alternative that would work with D6 and be upgradable to D7 ?

If there's a Drupal 7 version of workflow, are you planning an upgrade path from D6 -> D7 ?

subscribe

Subscribe.

Subscriping.

Is it a bad thing that we just had the Beta 1 release for D7 and there's no word on an upgrade for Workflow?

subscribing

subscribe

subscribe

subscribe

subscribe

subscribe

subscribing

Thinking out loud...

Would a path WorkFlow D6 -> Maestro D7 be do-able ?

http://drupal.org/project/maestro

Subscribing too...

subscribing

subscribing

subscribing but no one's giving a clue apparently

maestro's in alpha 3 stadium for d7 now
http://drupal.org/project/maestro

subscribe

subscribe

+1 subscribing

And another sub from here...

Subscribing

subscribe

subscribing

subscribe

subscribing

subscribe

Subscribe

subscribe

subscribing - would love to see this for D7! :)

subscribe

Subscribing

sub.

subscribe

subscribe

subscribing

subscribe

subscribing

So maybe this issue should be renamed as "convert workflow 6 to Maestro 7 and update project page?

Seems like no progress on #723310: Break workflow into smaller modules

Please, don't rename this issue. Converting workflow to maestro should be opened separately (...and after trying maestro I still prefer to use workflow which is more drupalish :-) )

subscribing

subscribing.

subscribing

subscribing

I agree with #63, Maestro and Workflow may solve the same problem, but they are wildly different ways to arrive at a solution. After playing with Maestro, it seems like it would be too cumbersome for basic users to create a simple workflow. Likewise, maybe Maestro is more well-suited for advanced workflows with custom decisions and callbacks. These two modules are different enough that I think there's plenty of room for both to be used in their different use cases.

subscribing

subscribing as well...

subscribing

subscribing

subscribing

sub

subscribing

subscribe

subscribing....

I'm completely in agreement with #68 - Maestro is not a suitable D7 replacement of Workflow - it will be far too advanced for most users.

For example, I happen to have two projects in development at the moment that only fit one or the other.
One is a content publishing site that requires a simple content review workflow for which Workflow is ideal but Maestro is overkill.
The other is an intranet for project and support request management, for which Maestro is ideal for managing the complex web of workflow transitions required.

There may even be a use case for the two modules to work together - Maestro doesn't actually do anything to change what people can do through the usual Drupal interface (there is no change to permissions, for example). So even if you setup a content review workflow, even though it may assign the task of reviewing a piece of content to an editor it will not prevent the content from being published by another user unless some other permission prevents it already.
So you could use the Workflow module in the usual way but hide the usual UI elements for making transitions and instead manage its transitions with Maestro. This would allow you to tie permissions to certain workflow states (and have additional benefits such as allowing filtering on workflow in views).

subscribe

Maestro was looking great in its first look. But I completely hate it. It works among its circle and can not be integrate with current content types what we are using.

Has anyone looked at the Workbench suite modules (http://drupal.org/project/workbench)? It looks like it might be good alternative to Workflow for drupal 7.

Trying out workbench is on my todo list.
It looks interesting though I'm not sure it will cover all the use cases of workflow (it sounds like it will cover many of them though!)

subscribing.

Architectural Ideas of D7-8 vision #723310-16: Break workflow into smaller modules

Any ideas or just thoughts?

EDIT: suppose storage for workflow-related staff could stay the same

subscribe

Subscribe.

subscribe

subscribe

Subscribing.

subscribe

subscribe

subscribe

sorry, someone else not adding value and just subscribing.

Just a note to try and add something of value to this thread to any new subscribers :)

These up and coming modules coupled with rules can often replace the functionality of Workflow in D7:

• workbench
• maestro

It's not a one-to-one feature list and won't work for everyone, but these modules are similar enough that often times you can get what you need done if you're creative enough.

Out of the two, workbench is probably going to be what most people coming from workflow will want - but maestro will certainly be more appropriate for some.

Just saying so folks know which they should take a look at first.

Subscribe

sub

Subscribe

Here's an interesting sandbox module - http://drupal.org/sandbox/andypost/1114392

With the launch of Workbench, does it make sense to combine forces instead of updating Workflow? I'm quite happy with Workbench and it seems to do almost everything Workflow currently does in D6. A little community involvement could fill the gap I'm sure.

I've been wondering this, too. Workflow seems to be drifting towards entity management, while Workbench is solidly focused on content management. You can imagine Workflows being useful for administering users or comments, for example. Workbench doesn't concern itself with this, just with providing editors a nice way to manage their content and some revision tools, which is great, but a different goal.

There's also a retraining cost. Workflow can be somewhat unintuitive but it was the best solution in D6, so a lot of site and organizations have come to use it over the past few years. Relearning content management may be challenging - this applies to Maestro as well.

That said, I'd love to see convergence of these modules somehow. Workbench is already an API in most senses. If Workflow were to break into smaller modules, you could imagine it becoming the backend for aspects of Workbench.

Subscribing

subscribe

subscribe

subscribe

My impression after reviewing the documentation and watching the screencast (http://drupal.org/documentation/modules/workbench) for Workbench is that Workbench module is the Workflow module + some added admin screens for editors. The UI in the admin lays out the forms a little differently but it accomplishes the same goal. It seems to me that the only reason to upgrade Workflow to D7 would be to do as jvandyk suggested a year ago, to rewrite Workflow module "Perhaps as a module that exposes a field..." As pointed out above, it looks like andypost has already done some work on this http://drupal.org/sandbox/andypost/1114392. I'll review that code this coming weekend. Can some others also review it so we can start to discuss the possibility of moving it into the Workflow D7 branch?

So, assuming we are going with Workflow as a Field approach, there is one implication I would like to bring up. If changing States is exposed only as a field, then Workflow Access module hits the wall when you don't want a role to edit a node/entity but you do want that role to change the state of the node/entity. In this scenario, Workflow Access permissions on a Field level would be needed. So when you don't want a role to edit a node but you do want them to update the State, what you really want is the user to not be able to edit specific fields but update the Workflow State field. This is a good problem to have and I think it makes Workflow incredibly more useful!

I'm more than happy to help out on this, in my opinion, while CAPTCHAS are nice, these types of modules (state machines) really unleash the power of user submitted content.

Personally I'm using workbench now as it does everything I used to use workflow for and more.

The way workflow moderation handles revisions is particularly useful.

@Shadlington - Thanks for confirming that. Workbench definitely seems worth grokking before moving forward on what Workflow for D7 might look like.

In other news... Palantir.net's presentation on Workbench was just approved for DrupalCon London. http://london2011.drupal.org/conference/sessions/workbench-managing-cont...

@jvandyk In response to your comment "workflow and rules are different things", I tend to disagree. How is Workflow module not a bunch of event, condition, and action sets? Rules for D7 is looking really slick right now BTW.

For example in Rules, to replicate Workflow module functionality, you can set up:

Event = Node: Content is being edited (ok, this Event doesn't actually exist yet :P )
Condition = User: Has role
Condition = AND
Condition = Node: field-state = value
Action = Data: Remove item from list (hide the items you don't want the user to be able to transition to)

This accomplishes the same goal for the end user. To the Administrator it's only a difference of UI in the backend. Though, I do feel right now that the checkbox grid is a much easier way to Administer workflows but hey, I could develop a UI for Rules that looks like what the Admin UI for Workflow module looks like right now. Perhaps the Workflow module should just be an alternative UI for Rules...

Rules would also be really good for applying permission schemes to entities thus replacing the Workflow Access module. We just need a module that allows us to define permission schemes that define CRUD grants per field that can be applied to entity instances.

About rules...

1. It's been years now since I've been listening this kind of «rules and workflow are the same thing» ideas from developers. Of course I respect that opinion and almost anything can be whatever you want if you work hard enough. But it generally only results in delaying the porting/developing of workflow module while rules stays rules and workflow module stays workflow module.

2. A workflow is not «a bunch of event, condition, and action sets». A workflow is a bunch of roles, states, transition rules between states and permissions associated with the combination of states/roles. This concepts are not details, they exist longer then computers have been around and not understanding them results in not being able to plan and execute complex workflows.

3. If it's possible to reproduce the workflow module with rules:
a) Why hasn't any developer done that already? Even the example you give in #111 shows that it would be necessary to create new actions («Content is being edited» doesn't exist. And does «Data: Remove item from list» exist?) in a time when rules (a wonderful module) still hasn't an action to publish a costume comment or a condition to detect taxonomy...
b) What are the advantages for site builders in that? Have you imagine how it would be to manage a site with 10 roles, 10 workflows with 10 states each with the rules UI and the kind of methodology you describe in #111?
c) ...and if you're going to build a new UI (a new module...) so that rules can became workflow and the UI gets somewhat like workflow module, what's the advantages of that to developers who will have to reinvent the wheel?

4. The workflow module works fine and has immense potential for new features and scalability. More then 11.000 sites are stuck with D6 and what they need is an urgent port and update path to D7 that takes the minimum time possible from developers. After that it is possible to optimize and add new features (like #1176192: Workflow Access Extension).

About other modules...

Will Maestro or Workbench or whatever have upgrade paths from Workflow module? Changing may be interesting but will more then 11.000 sites be able to discard their present workflows and build them all over again in new modules?

No upgrade paths exist and it is doubtful that there will ever be any.

(Why is this in "needs review" state? There's no patch.)

@hefox LOL. We're all talking about states and workflows and we don't get this one right :P Back to active it is.

@Shadlington We haven't really reached our stride in D7 adoption. With 11,000 sites all on aging D6 systems who are bound for D7 upgrades, I bet some one is bound to get paid to write and share a migration script for workflow-6.x-1.x to ?-7.x-1.x. Heck, I'll do it if anyone wants to hire me :P. But, in all honesty it's probably not economical to write a migration script considering that configuring a few workflows can be done in a couple of hours where as a migration script might take a day or two to get right. Perhaps it's more likely that some module looking to gain the workflow-6.x-1.x crowd would write that migration script (*hint* *hint*).

@Encarte In response to "Why hasn't any developer done that already?"
No one has implemented Workflow as a UI for Rules because it has always been less work to implement a quick solution that gets the job done as opposed to flexible framework like Rules. But I think the tables may have turned. It may be the case now that it would take less time to write the Workflow UI for Rules and fill in the missing gaps for Rules than it is to port all of the Workflow module to Drupal 7. Such a radical shift seems even more like the right thing to do since the Workbench module has already tackled node workflows in Drupal 7, this would be entity based + the super powers of rules. But I hold my breath on this, more research is necessary to uncover how much work my proposal would actually take, not to mention alternatives such as andypost's are definitely worth considering.

@rjstatic I doubt that there will be a migration available for workflow -> maestro/workbench because the modules do not overlap completely. They are used in different ways and I doubt it would be possible to write an script for migrating all but the simplest workflows.

Unless you're talking about workflow-6.x -> workflow-7.x, which I wasn't. That'll probably have an upgrade path.

@Shadlington I was just going off of what you said "Personally I'm using workbench now as it does everything I used to use workflow for and more." Also, watching the demo it looks like Workbench tackles the core functionality of Workflow module, dictating on which node types, which states a node can be moved to by which roles. For now though I'll shut up till I actually try the Workbench module myself, try out andypost's Workflow 7.x-1.x sandbox project, and evaluate how much work it would be to fill in the last few gaps of the Rules module so it could work as the engine for a possible Workflow module in D7.

Actually, it would be great to get a second or third set of eyes/opinions on my current task list. If anyone else thinks it's worth while, you could also tackle the following tasks:

1. Compare the Workbench module to the Workflow module. What does each do differently? On the parts in which they are the same, how might we approach this differently to make it worth our efforts as opposed to just reinventing the wheel built by Workbench.

2. Try out andypost's Workflow 7.x-1.x sandbox project and write up more details on his approach. What are the advantages of his approach? Is this approach worth our time in light of what we find in the Workbench module?

3. Evaluate how much work it would be to fill in the last few gaps of the Rules module so it could work as the engine for a possible Workflow module in D7.

I'm pretty sure you could recreate most workflows in workbench. I'm just not sure it would be that easy to make a script that does it as I would imagine it'd require tweaking on a case-by-case basis - I could be wrong though!

@Shadlington You're absolutely right, it could be tough, no point in saying it's easy without trying first :)

I took notes on the "Workbench: Managing Content Management" presentation from DrupalCon. It answered ALOT of my questions. I'm still planning on reviewing the code as well to get a deeper understanding and I've also started participating in discussions in the the Workbench issue queue.

my notes -> http://groups.drupal.org/node/156729

subscribing

Subscribe (sorry I can't contribute much more to this thread, but I will say that it looks like dealing with Rules-based workflows, without using the Workflow module, is "the hard way" and will require much more work, so I do hope that a good port of Workflow or upgrade path is ready by the time we are ready to port this site to D7 (already in "production" on D6, but with new features which will require some editorial workflows).

OTOH, if someone really needs an editorial workflow in D7, the tutorials for a Rules-based implementation of this functionality:
http://drupal.org/node/550716 (actually for D6)

and http://drupal.org/node/1027546 (that one is D7)

are likely to be potential solutions (as alternatives to some of the other modules discussed above), the primary "pro" being that Rules is released and reasonably stable already for Drupal 7 (the 7.x-2.0-beta2 of Rules is already in use on over 2000 sites, but of course most may not be using it for anything like a "workflow", per se).

+1

@Lomo Thanks for the links to relevant docs. Setting up a workflow using the current Rules UI is definitely an arduous process when compared to using the what we currently see in the Workflow module. I really do think that the Workflow module's UI while some people complain it is confusing, is much LESS confusing than having to set it all up in small pieces like you have to do using the Rules module. The UI should be as simple as possible but no less. Also, thanks for pointing out the Rules adoption for D7. I think it makes the case for a Workflow module that leverages the power of Rules ever more appealing as the Rules code is over a year ahead of Workflow for D7 at this point.

Agreed. On all points. I'm glad the workflow I need to set up now is still on D6 as it would be a lot more work doing it without Workflow. For D7, a Workflow module might best implement the Rules API.

i'm thinking that Workflow could be replaced with Flag + Rules

flags can be restricted to roles, and thus shown or not, they are shown on the node edit form, and you can even create complex layouts with panels where you show or not flags.

with rules you can create all those conditions + actions that will make a email user when draft -> review happens...

Seems like a lot of work to use Flag+Rules, although it's flexible

current using workbench moderation module with some custom access code, it's kinda good (at least for my use case)

Flag hasn't had its rules integration ported to D7 yet, so currently it isn't usable for this purpose.

the rules and flags, after being created, can be exported as plain exports or features exports.

if the module adapts to the feature export mode, then enabling the module will import over the rules and flags automatically.
that puts a dependency on features module (which requires ctools).

if the users want to override the default rules and flags, they can do so if they have strongarm.
that puts an optional dependency on strongarm module (which requires features).

rules AFAIK is stable, for both D6 (1.4) and D7 (2.0-beta2).
flag is stable for D6 (1.3), and i think, close to stable for the 2.x line (2.0-beta5) for D6 and D7 (given me no issues on D7).
strongarm, features and ctools are also stable. no issues on my demo installs (D6 and D7).

Rules integration in Flag seems drawing close to being complete. see reply #73 and #78:
http://drupal.org/node/875366

with this, ofc i'm suggesting the project to be converted to Flag + Rules running on Features

You should be aware that the issue you referenced #875366: Port the Rules integration to D7 has been dragging along very slowly for a very long time.

i am aware, and i checked that and other details before posting.

on the other hand, this issue is equally old (>1 year).

so my question is, do you want a module with the most flexibility and least code?
then it's probably not the old way.

do you want it for yesterday, today or tomorrow?
for the looks, it is for tomorrow, so Rules + Flags is still a good bet.
otherwise it would be a direct port of D6 with little changes. and perhaps that could be done already. or not.

if you aren't happy with the code, or it's taking too long, perhaps a new approach could be a good idea.
you don't have to wait another year. you could start doing work with D6 and then import and upgrade the rules and flags into D7 and have them exported for the new APIs.

I'm not arguing that your solution isn't viable - it certainly is (though I think it may have usability issues). I'm just making sure that other people subscribing to this issue are aware that it isn't ready yet.

In the meantime, workbench moderation is a module that will solve a lot of use cases. Mine included.

Using Flags for states as opposed to a CCK field for states is an interesting idea. It seems to satisfy those that don't believe that states should be a content field while still having the benefit of code reuse. I'm still partial to the idea of a system where states is just another field and workflow gives you a UI for managing what roles have CRUD grants for each field. In this sense, the code for managing access to state transitions given a specific state and the code for accessing a field given a specific state is the same.

Hi all,

I have an initial pass at the Drupal 7 update here:

http://drupal.org/sandbox/bastlynn/1152380

Please read the UPDATE.txt file if you are using Workflow with Rules - there are some changes that came with the upgrade (for the better, for the most part) that require a little bit of configuration tweaking after you update from Workflow 6 to Workflow 7 and export your old rules.

This module is under testing, I'm hoping to get feedback on major bugs found before presenting it to the current maintainers of Workflow as a starting point. Please leave bug reports or patches in the issue queue on the sandbox to avoid littering the Workflow issue queue with them.

subscribing

subscribing

subscribing.

subscribing

+1

subs

just tossing in my $0.02 worth.. and subscribing...

@encarte.. thank-you for stating what really should be obvious.. Rules != Workflow.. yes, you could possibly patch some mess together with Rules to do what Workflow does (which is define a s/w state machines).. but why, why would you ever want to do something that silly..

I just took a look at Workbench screencast and, although optimistic that everything is not covered in the cast; i am not sure i agree that this replaces Workflow. I did not see (although possibly it is there) where the transition access settings are done - that is how do you define who has the rights to move content between each state. I also didnt see the feature for defining state transition actions.

If both of these are covered by Workbench then i agree this could be a very nice replacement for Workflow.

Also agree without an update script from Workflow to Workbench; a lot of sites may not get converted over to D7 to quickly.

Just for the record - i have used Workflow on numerous projects and my company considers it one of the "premier" modules that we anticipate using on nearly every project we do. Right up there with cck, views, pathauto, notifications, messaging, etc.

subscribe

having used both, I can say that workbench != workflow either. Workbench, while also an excellent module, is more like an advanced revision_moderation module than it is workflow.

I've spent quite a lot of time trying to find an alternative to workflow, and there simply isn't (unless as liquidcms describes you fake it with rules).

Workbench isn't workflow. Workflow is more flexible.
Workbench is more like a specific (but common) use case of workflow.
So it will meet the needs of a lot of people currently using workflow, but definitely not all.

subscribing

maybe then just to further this discussion i thought i would list what i think Workflow is and someone with Workbench knowledge can tell us what it doesn't do. This might help decide which is the right path for D7 - advance Workbench to do what Workflow used to do OR upgrade Workflow to D7.

These are what i think of as basic features of Workflow:

- define any number of workflows
- allow definition of any number of states in each of these workflows
- assign a workflow to a node type
- define permissions for which roles can move content from state to state
- define std view/create/update rights for nodes based on role and state (likely didnt say that well - e.g. NodeType A, can be edited by RoleX when in State4, but not when in State5)
- define Actions which will be triggered when a node transitions states
- schedule state transitions or simply edit a node and set to new state
- VBO: bulk set nodes to state
- VBO: bulk set nodes to next state
- define field level permissions based on state (added module)
- Views: filter, etc on state

i think that's about it. Did i miss anything?

Which of these does Workbench not handle?

Ok, in the context of the above comment #148, I feel a shameless plug of my own module can be justified: Workflow Extensions.
The features it adds to Workflow are listed in detail on the project page.

Also, Workflow used with Revisioning makes a powerful combination to implement editorial and publication workflow.

Rik

@liquidcms - thanks for the summary in #148

plug away RdeBoer -- i use workflow_extensions with every single instance of workflow. So much so, that I forget it's not part of it, lol.

subscribing

subscribing

subscribe

This needs to get moving; Drupal 7 has been out for a while and is pretty and clean, but this module is critical for my site (and I'm sure a lot of yours as well). Workbench (with Workbench Moderation) isn't a good replacement for Workflow, because (as said before) it's not as flexible. Workflow is much more powerful; the main utility of Workbench (in my mind) is the definition of a place to put all UI/tasks for certain types of users (like content contributors) in one place so they don't have to learn to use the full Drupal UI. A module can basically "integrate" with Workflow just by providing a View that shows up as a tab on the "My Workbench" section of the site. And this is pretty easy to do.

So everyone, please take a look at @Bastlynn's sandbox that was set up and linked in #136. Download it, test it out, and report problems/provide patches. I provided a patch there that would add tabs to "My Workbench" for Workflow data - so all you talking about Workbench can be happy. Anyway, unless some people test it out and provide feedback, all the work done there will go to waste.

And @Bastlynn, have you contacted any of the Workflow module maintainers directly? Have you considered applying for co-maintainership?

Thanks,
Nathan

The problem with this type of rudderless/maintainer-less development is that now there are essentially two forks of this module (and who knows, there may be even more hidden in the issue queue)-- this one and #558378: Make workflows exportable with Features (D6). Features integration is critical for me so i can't simply switch to a different fork.

It's a shame that such a unique and important module is languishing-- but I don't really see it making real progress unless one of the maintainers set some sort of direction with an official dev release.

Subscribing

subscribing

subscribing

Has anyone tried running this through Coder?

Will Hearn of StatsCanada replied via email to me regarding the abilities of Workbench/Workflow from my post in #148, figured i'd repost here:

- define any number of workflows (Feature being worked on not yet implemented single workflow)
- allow definition of any number of states in each of these workflows (YES But Single Workflow)
- assign a workflow to a node type (YES)
- define permissions for which roles can move content from state to state (YES permissions for each state assigned)
- define std view/create/update rights for nodes based on role and state (likely didnt say that well - e.g. NodeType A, can be edited by RoleX when in State4, but not when in State5) (No but rules integration looks to be forthcoming)
- define Actions which will be triggered when a node transitions states (YES Can use Actions As in Sending an Email on state change, requires a current patch)
- schedule state transitions or simply edit a node and set to new state (YES with Scheduler and Directly on the node based on user can see state have permission to change to)
- VBO: bulk set nodes to state (No hopefully planned)
- VBO: bulk set nodes to next state (No hopefully planned)
- define field level permissions based on state (No Not Sure)
- Views: filter, etc on state (Have not tried but see no reason why state would not be exposed)

i admit this seems closer than i had expected with notable exceptions:

- only one flow per site seems to be very constricting
- rarely do i understand anyone mentioning Rules as a portion of any of this.. how does it work to use Rules to replace access based on state? do you mean use something like TAC and when a node transitions state use rules to assign different tax for that node to set access? very cludgy if that is the mechanism.. but maybe missing something still. this is one of the key aspects of Workflow.. this is what makes it a state machine builder.. it is used to define states - these are static holding patterns for nodes; will be messy to ever replace that by something that is triggered.

My apologies for the long delay to your reply nkschaefer

Yes I've tried contacting the maintainers directly, (just sent another email off). I'm about to just run down the list of them at this point to get someone to look at it. I do regularly swing by the check the issue queue, so please please let me know if you spot anything. I would really like to have a count of testers on it before adding anything like new features (ok, truthfully I'd really like to get the code into Workbench proper before new features or data storage redesigns come into play).

It's working pretty well on a few sites I run, but I'm sure there are others that need it even more.

Let me look over your patch (if I didn't already).

And we have signal - I got the attention of one of the maintainers, he'll take a look when he gets a chance to. :) I guess my last attempt got ate by a spam filter or some such.

subscribe

Subscribe

subscribe

Sounds really great Bastlynn.
Once you become a co-maintainers, we will start to port #1176192: Workflow Access Extention to D7 version as well.
This module is really important to us. This is the last block stops us upgrade to D7.
We will test it out and let you know the result.

Marking needs review, as there is some code way back in comment #136 that seems to need it =)

The latest round of updates based on bugs found so far have gone into the module, let me know if you spot any more. Just drop the bug reports into the sandbox issue queue and I'll get to work on em.

Sandbox code has been pulled into Workflow proper. :)

D7 dev branch is now in place based on the latest code from the sandbox: http://drupal.org/node/1338770 - this *is* dev, so keep that in mind and always test before you go live. Place issues in Workflow.

@Bastlynn: thanks so much for all your good work!

Only 2 issues with current code:
- license.txt should be removed also as .po files
- D7 has no update_sql()

A living maintainer for Workflow module after all this years! Welcome Bastlynn, I hope you can survive and save all this lost souls, trapped in the D6 limbo. :)

sweeet!!

Thanks for all the work you put into this, Bastlynn - this was the last thing keeping my project in Drupal 6. I'm pretty excited now.

Fantastic! If you have anything in particular to test or fix, please indicate so to jump in =)

Right now what I'm doing is just going through the issue queue figuring out what bugs are reported, what issues have been taken care of but not closed, what issues are totally out of date, and generally getting familiar with the needs. So right now what I need is a little bit of time to get everything lined up ready to roll, then there shall be loads of work to be done and tested. :)

For the moment - beat on the 7.x-dev branch and hunt up any bugs in there for me.

I put in a few extra features on the latest version in the 7.x branch (split the module up into sub modules, and completely reorganized and re-factored throughout in preparation for a CTools integration). Let me know if I broke anything in that process! :)

Bastlynn, I rely heavily on Workflow for a lot of the things I do, and having it in D7 is really really going to help things. Please let me know if you need or want a co-maintainer on it.

State machine solve everything!

I've now got the feature export working on the latest 7.x branch and I've spoken with the maintainers for Workbench and State Machine. Once I get a 7.x-1.x release out, I'll probably be opening a 7.x-2.x branch for code to allow Workflow to play nicely with those two modules.

In the meantime - please test the 7.x-dev branch and tell me if we've got any more bugs to fix! :)

Yea!

Happy New Year: http://drupal.org/node/1395452

holy workflow batman--- you rock Bastlynn! Congrats.

And Bastlynn did it almost single-handed. Hurrah for Sarah Hood and Classic Graphics!

Great effort, great result.
Thanks for all the work, Bastlynn!

Thanks to all! Next up is backporting a lot of these updates to D6. :)

Bastlynn, Great work and Happy New Year!

thanks!

Nice!!! Happy New Year peeps!

Post #148 claims that it is possible to "define field level permissions based on state (added module)", but i could not find a way to use this feature.
What is the additional module needed?
I've found "Workflow Fields", but it's only for D6.
Any help?
Thanks in advance.

@franco.accordino Workflow Fields is the module #148 referred to. But no, it still doesn't have a D7 version (follow #1339290: Port Workflow Fields module to Drupal 7 for news).

This is a closed issue, so please open new support issues for further questions.