I'm curious if it would be difficult, or even possible to modify this module so that it could utilize the Date API, rather than requiring the node to be "event enabled".
As far as I can tell, the event module does not provide date information to be used in Views, as the Date module and Date API do. This makes it quite handy for managing the display of information utilizing the Resource Conflict module.

Here's a little background on what I'm specifically doing with it:

I am using Resource Conflict in a scheduling functionality on a website. I have two content types set up, "Resource" and "Reservation". The Resource content type is for the actual things that will be reserved, like rooms and equipment. The Reservation content type is for the actual reservation that is made. I have it set to nodereference the "Resource" content type, so that the same resource cannot be reserved at the same time. I then want to be able to display these reservations in a calendar. I already have calendars set up utilizing the Date API and the Calendar View in Views. I would like to be able to add these reservations to my existing calendars, but Views does not see any field information from Event module, like it does with Date API info.

I hope that wasn't confusing.
Thanks for the work on this module; it seems very promising for this sort of functionality. Right now I'm just struggling with the limitations of Event module over Date API.

CommentFileSizeAuthor
#4 resource_conflict_date_api.patch14.27 KBdeviantintegral

Comments

deviantintegral’s picture

deviantintegral commented
Status: Active » Postponed (maintainer needs more info)

The event module does expose it's information to Views. It's also possible for modules to support both the Date API and event, such as calendar.module does.

I don't have a lot of time to code it up, but if you submit a patch I'll be glad to test it and review it.

--Andrew

Matthew Kivett’s picture

Matthew Kivett commented

Unfortunately I'm still learning when it comes to development, so I don't think I can be of much help in writing a patch at this point.

I am happy to contribute any user testing and assist with documentation if needed, but I'm afraid that's about all I have to offer.

This module would certainly be a welcomed addition to my setup, but I can make due without the functionality, so no pressure.

dugh’s picture

dugh commented

The calendar module isn't compatible with the event module though.
Views may be able to access event fields, but not a calendar view from what I can tell.

deviantintegral’s picture

deviantintegral commented
Status: Postponed (maintainer needs more info) » Needs review
StatusFileSize
new resource_conflict_date_api.patch14.27 KB

Thanks goes to Cassus for the work attached to this. I've attached what he emailed me as a patch; enough has changed that I think it would be best to create a version 2 branch to work in, using this patch applied as a starting point.

The cross-api work is pretty cool.

I would appreciate it if at least one other person could test this before I branch to make sure that there isn't anything glaring that I've missed. Overall, it's a much better piece of code then what was started with :)

Items which on the creation of a new branch should be created as new issues:

  1. Don't require Date API; worst case, either Date or Event should be required. On reading, I don't see why any date-dependent code couldn't be wrapped in module_exists()
  2. Implementation of the appropriate install hooks for upgrading
  3. Now would be the time to investigate any Drupal 6 compatibility. I imagine Event hasn't changed very much, but much of the CCK / Views stuff has been in flux so there may be some things to do there.

Here is the email sent to me by Cassus:

OK, I did it.

But at a price.. Broken upgrade compatibility. So if someone upgrades, he looses most of the preferences.

If you had a spare hour, you could write a migration script, to help the upgrade.

new features:

  1. drupal coding standard compilance (as for code-style.pl)
  2. more documentetion, comments in the code
  3. smaller, simpler functions
  4. supporting both event, and CCK date conflicts, even for cross-conflict (a date and an event node conflicting)
  5. In the conflict error box, tells you not only the conflicting object, but the name of the event you have a resource conflict with
  6. validation for the node_type_form

bugfixes:

  1. the variable name "resource_conflict_".$type could cause trouble with some fancy type names conflicting with other variables.

price:

  1. need for an upgrade script
  2. new dependency: date_api
deviantintegral’s picture

deviantintegral commented
Assigned: Unassigned » deviantintegral
Status: Needs review » Closed (fixed)

I've run through the code. I've found a few bugs, but nothing horribly wrong!

I've created separate issues for everything I've found against the 2.x branch. There will be packages available soon, so it'd be appreciated if anyone else felt like testing it. Otherwise, take a look at the issue queue and feel free to contribute in any way you can.

--Andrew