rules

I've just released the first release candidate for rules 1.0. There were quite some improvements since the last beta release, so check the release notes. After updating, don't forget to run update.php and help testing the RC1 thoroughly! When no major problems occur I plan to release sometime next week.

The list of issues to be fixed for 1.0 can be found here: http://drupal.org/project/issues/search/rules?issue_tags=rules 1.0

I'm currently planning the rule based custom logging module, which I'm going to write after rules 1.0 is out. I post this to the activity group too, because I think there is quite a overlap to 2.x version, which is currently under development.

Note: My proposal has evolved to include a detailed schedule, glossary, and long brief about the reasons why my methodology is at least different, if not better than the existing ones. I have moved the content from this single page to the Package Management project page. The project home page links to the SoC Proposal with the schedule.

Old Titles for this project ordered by earliest (from these you can see 3 major aspects of the project):
Automated Drupal Software Appliance Builder

I am not a developer, but looking for opinions on the best way to approach this to guide my team... It revolves around workflow, triggers, actions and maybe some rules.

A content type (call it bid) can be created with a nodereference to another content type (call it RFP)

The workflow has been created with the following steps:
(creation) - can be created by anyone with a vendor role(and some other "pre-qualifications") (done by workflow fields)
draft - Only Author can edit (done by workflow fields)
Submit - Only Author can edit (done by workflow fields)

Hi!

I noted the post is missing in this group, so I just want to point to this soc-idea:

Rules Module extension und perfection (a.k.a. Rules monkey)

Feedback wanted .. :)

Portland Community Media, in partnership with Denver Open Media, has created documents explaining the rules of scheduling Producer> Project> Programs. The document includes rules for series programs, scheduled on a quarterly basis, as well as individual programs that get scheduled on a first come, first served basis.

I have also included rules on how PCM schedules filler programs.

The focus of this discussion is:
- to communicate current scheduling rules and guidelines
- to discuss other methods of annual, quarterly or daily scheduling rules used by other media centers

I just today started looking at the Rules Module. The description looks like it fits the bill but not being a programmer type I want to make sure I am on the right track.

I have workflow, workflow access, and workflow fields set to do the workflow transitions I would like on a per content type basis.

The Rules Module description states, "The rules modules allows site administrators to define conditionally executed actions based on occurring events (ECA-rules). It's a replacement with more features for the trigger module in core and the successor of the workflow-ng module." On first glance I wasn't sure, but...

Overview

The Rules module is designed to support actions that are executed depending on events and conditions (ECA rules) in Drupal. This proposal is about extending and enhancing Rules module with new features and ideas.

Motivation

In my system I have a series of nodes that are created every hour, each one with a set of environmental paramaters. the date is stored as a cck datetime with the time ignored and the time is stored as an integer in a cck feild and is from 0-23. Lastly is a field called station which contains a code for a particular station. Now at run time during creation of the nodes, which is handled by feedapi, a series of physics equations which has been converted into php functions and are activated by a set of trigger rules and rule sets.

Unfortunately the handbook got scrambled when d.o. upgraded to d6. See http://drupal.org/node/376790.

As mentioned in the issue the work is ongoing and hopefully the docs are fixed soon. mitchell and me thought about doing our on documentation site in the meantime or forever, but I think it's better to stay on d.o. - so people can contribute faster, without the need for registering or even logging into another site.. (Yes, every d.o. user can contribute to docs).