In addition to the new features which were already available for some time in worflow-ng's 2.x series, some further improvements are waiting for you!
Logging per entity
First off there is a new extension module, which is shipped with workflow-ng. It allows you to log a customize message on every support workflow-ng event for content or users. This is done by actions! For flexible display of the log messages, views support is available. So there a lot of possible use cases for this, I have to in my mind:Activities..
You could easily log certain actions of users and their buddies and list them in blocks and pages generated by views. So you can build something similar like the (really interesting) activity module!State change log
In workflows it's often desired to have a log of state changes. E.g. if content, let's say an article goes from "needs review" to "published" this should be logged and displayed on a tab associated with the article (yes, views can do that!). Great, isn't it? Thank GHOP and corsix for that! Yes, corsix implemented the whole module in two GHOP tasks. This took him only 1 day per task, awesome!Rules ?
Furthermore I've changed the terminology as preparation for 6.x. Configurations are now called rules. I think the term "rule" describes it very well. With 6.x the core of workflow-ng will be a separate project: the Rules Engine I also rearranged the menu items in a "workflow-ng section". Hopefully this increases usability :) So check out the first beta of 2.0. If everything goes well, it will be the only one.Rules?
I'm not really sold on changing the name from configurations to rules. Can you explain the reasoning behind it? I just balk at the name b/c a configuration more aptly encompasses the three-fold combination of events, conditions, and actions. A rule in my mind seems limited to the condition/action part and not the event. In other words, when an event happens, I may evaluate a set of rules to see if any actions need to be taken, but I wouldn't consider the event as part of the rules. Then having this new module be a more robust replacement of the new triggers module seems like it would be supplanting the part (events) that I wouldn't consider part of a rule.
hm
yes, a rule consists of configured actions and conditions, which are assigned to an event. Actually, the event isn't part of the configuration, it's just assigned to it, so that the rule / configuration gets evaluated when the event occurs.
My main point of this change is, that "configuration" is really general and says nothing about it. If a new user gets into the workflow-ng admin screen, I think he can't imagine what a configuration is. But "rule" should give him a good idea of what he can expect.
I've thought about detaching "configuring rules" from assigning rules to events, but I think that would make all just more complicated to use, as the assigned event specifies the available arguments. But perhaps something (optional) like "rule sets" will come for 6.x.
That helps. Thanks for the
That helps. Thanks for the explanation. : ) I agree that rules is a little more descriptive. I've been referring to them as workflow configurations to avoid confusion. I also agree that the way you have it setup it's essential to connect "rules" to "triggers" (new D6 lingo) so we can specify arguments and such. I didn't like that in D6 you could only apply a single action to a trigger. If you intend to build off of the core modules in some way, we're available to help out as that would be better for Ubercart in the long run.
d6
it's great to see, that you are happy with the choice :)
@d6
It's planned to integrate the "rules engine" as much as possible with core. So it will support executing d6 actions. But it won't integrate with the trigger module, instead of the old known event system of workflow-ng will go into the "rules engine" and act as a trigger module replacement.
D6 time frame?
Not to rush you or anything, but is there a rough road map for D6 development? Any idea when we might have a beta rules engine to take out for a spin?
I noticed in Drupal 6 that
I noticed in Drupal 6 that the Actions module is incapable of adding/removing roles. So when workflow-ng moves to using it in six, will it add any Actions to keep functionality the same as previous versions of workflow-ng?
Configurations, Rules or What ?
I think that the issue of definitions is very important to nail down early in the development cycle.
I agree that the term "configuration" is under-defined. Among other things, it should include the rules or the ruleset invoked to start a workflow as well as information about the process state, work steps, etc.
The idea of a configuration can also include the set of initial data values as they were when the workflow was invoked, the initial dataset. In case of a simple workflow manager, if a process fails, values can be restored by transaction roll-back.
In the case of a rule engine, some tentative bindings may be generated by the rule 'component' of the workflow engine ( such as Customer Credit = OK ). Potentially, a process can also do an update to the database and invalidate the conditions that triggered it, which might create side effects ( logical inconsistencies within the rule engine ). Often, this can be implemented as arrays of conditions ( conditional bindings ) along with an associated vector for changed data values to the underlying data in the database.
Rather than get into the details of an rule engine, this is intended to show that there are definite parts to the rule/workflow engine and they need distinct names. I think there's a useful distinction to be made between a 'rule' that triggers a workflow ( such as "Update_Customer_Balance" ) and a 'rule' that binds an internal condition ( such as Customer Credit = OK ). They can often work against one another and it can become very confusing when trying to track down side effects in the engine.
Some of the difference may be explained by the forward and backward chaining components of the workflow/rule engine. In general, workloads are triggered by forward chaining ( data-driven ) rules and conditional bindings are triggered by backward chaining ( goal-driven ) rules.
There are other tricky areas of terminology, but there are very good business rule and process model definitions available on the web. The OMG also has numerous standard terminologies for Business Rules that might be useful ( such as BPEL mentioned elsewhere ).
Bill Breitmayer
http://billbreitmayer.com/drupal