I recently took over an aging Drupal module, Resource Conflict. It had a D6 version with a lot of outstanding bugs in the queue... I started by simply rewriting it for D7 and my specific use case, but ended up in a discussion with the module's old maintainer about a total rewrite for Entities and Rules. So that's what I did, and I just released the 7.x-3.x-dev version.
Resource Conflict USED to be a module that detected booking conflicts in resources, and threw a form error. Resources were node reference field entries, and it supported date and event modules for the date/time. Resource Conflict version 3 is built on Entities and Rules, so the behavior is now totally customizable. This lets it support a wide variety of use cases.
How to use it
Out of the box, the module lets you enable Content Types for resource conflict checking, and you select which date field to use for each enabled content type. You do all this on the Content Type's edit page.
The module comes with a sample Rule for you, which throws a form error any time you try to save a Resource Conflict enabled node with a date that overlaps another Resource Conflict enabled node.
But this is not a very realistic use case. More likely you will want to edit the rule to add some more conditions - for example, maybe a resource conflict on your site means overlapping taxonomy terms. Or entity references. Or titles. Or anything at all!
To give an example of how complex this can go - on a site I recently launched, I have two kinds of resource conflict events. "Hard" conflicts are when two bookings at the same time reference the same user or taxonomy term. Hard conflicts throw a form error and prevent saving the node. This is just like the above case, and it's a really simple modification on the default Rule. "Soft" conflicts are when you try to book a taxonomy term that is a parent or child of a term in an existing booking, or a user who is tagged with a term or child of a term that is already booked. For example, maybe I try to book the taxonomy term "Maintenance", but the sub-term "Plumbers" is already booked at the same time. Or maybe I try to book John Doe, who is tagged as a "Plumber", but Maintenance is already booked at that time. Soft conflicts can be booked, but they create a node to record the conflict.
Other people have asked about using the module to integrate with Organic Groups, or to control bookings of finite resources - you could easily use Rules to build those functionalities. Best of all, it's all exposed and easy for you to maintain.
Here's a run down of the Rules components included with Resource Conflict 7:
{% endraw %}
Resource Conflict USED to be a module that detected booking conflicts in resources, and threw a form error. Resources were node reference field entries, and it supported date and event modules for the date/time. Resource Conflict version 3 is built on Entities and Rules, so the behavior is now totally customizable. This lets it support a wide variety of use cases.
How to use it
Out of the box, the module lets you enable Content Types for resource conflict checking, and you select which date field to use for each enabled content type. You do all this on the Content Type's edit page.
The module comes with a sample Rule for you, which throws a form error any time you try to save a Resource Conflict enabled node with a date that overlaps another Resource Conflict enabled node.
But this is not a very realistic use case. More likely you will want to edit the rule to add some more conditions - for example, maybe a resource conflict on your site means overlapping taxonomy terms. Or entity references. Or titles. Or anything at all!
To give an example of how complex this can go - on a site I recently launched, I have two kinds of resource conflict events. "Hard" conflicts are when two bookings at the same time reference the same user or taxonomy term. Hard conflicts throw a form error and prevent saving the node. This is just like the above case, and it's a really simple modification on the default Rule. "Soft" conflicts are when you try to book a taxonomy term that is a parent or child of a term in an existing booking, or a user who is tagged with a term or child of a term that is already booked. For example, maybe I try to book the taxonomy term "Maintenance", but the sub-term "Plumbers" is already booked at the same time. Or maybe I try to book John Doe, who is tagged as a "Plumber", but Maintenance is already booked at that time. Soft conflicts can be booked, but they create a node to record the conflict.
Other people have asked about using the module to integrate with Organic Groups, or to control bookings of finite resources - you could easily use Rules to build those functionalities. Best of all, it's all exposed and easy for you to maintain.
Here's a run down of the Rules components included with Resource Conflict 7:
- EVENT: A Resource Conflict Node Form is Validated: This rule fires during node form validation on Resource Conflict enabled content types. You should use this event if you want to set form errors, or if you want to interact with Rules_forms module. It provides both a node object of the node being created/edited and a form object for use with rules_forms. This is the event trigger for the default Rule.
- CONDITION: Contains a Resource Conflict: Evaluate a node object for conflicts. Returns TRUE if there are conflicts for the node.
- ACTION: Load a List of Conflicting Nodes: Creates a list of nodes that conflict with the given node.
- ACTION: Set a Form Validation Error: Stores a form validation error to be fired the next time a validation hook is called on a conflict-enabled node. This is intended for use with the "A Resource Conflict Node Form is Validated" Event.
Future plans
I'm pretty happy with this initial dev release; it solves a lot of problems quite elegantly. But there are a few remaining. Here are the items I'm planning on knocking out first.
- Drupal 6 backport: I'll release a 6.x-3.x branch which uses Rules for reactions. The biggest issue here is that rules_forms module doesn't exist for D6, which makes it impossible to throw a form validation error from within Rules. I may have to write a custom Rules action to do this.
- Full Entities integration: I'd like to generalize the module out to support ALL fieldable entities.
- Better Integration with rules_forms: rules_forms is pretty cool, and even cooler is the new version they're working on, that doesn't rely on the "form" Rules object. I'm looking forward to this, because it means we'll be able to do cooler things with resource_conflict.