Add availability onto a resource

Hej Chris,

I only came across this module a couple of days ago - now I am wondering if I understand this correctly: You would like to add the feature that a resources is only available during a certain time slot. For example a room where the building is locked during the night?

If it isn't that I don't understand what it is you are doing.

Thanks :-)

+1 on this feature....seems like a useful addition!

This sounds like a very useful addition - thanks for the patch.

• I added a date repeat field, but didn't enable it for availability, but availability errors were thrown as if it was added.
• There is a break; that is commented out and should be removed if needed.
• The help message for enabling availability should indicate what needs to be done to make it work, instead of just the message that it can't be turned on.
• Why are we doing a dsm() instead of a form_set_error()? Shouldn't unavailable times be blocked entirely?
• The error message for an unavailable time needs to be wrapped in t()
• While we're at it, we should rename $tmp and $tmp2 to be something a little more useful.
• There are some minor code style issues with comments and PHPDoc.

Thanks for the update.

• The 'validate' nodeapi case has been shifted back by two spaces - it should be indented twice from the switch.
• Actually, as an improvement from the original code - how about we negate the if statement, and remove the else entirely?
• Let's do it as a form error for now, and then we can change it in #791864: Admin page (and variable setting) to set whether the form errors or warns on conflict later if needed.
• $tmp was in the source, but could stand to be improved anyways. How about $resource_overlaps and $resource_availability?
• For code style, take a look at http://drupal.org/project/coder, and http://drupal.org/coding-standards.
• '#description' => t('sdkfjhlksfdjskfdjhasf') needs to be fixed.

Here is an updated patch that:

• Removing lines consisting only of whitespace.
• Clean up some comment standards.
• Fixed some further indentation issues.

Haven't tested functionality yet, will get to that soon.

Hey guys,

This is my 1st patch so I will lovely accept all of your comments and advices :)

In my case, I had to apply a patch to the 6.x-2.x for date repeats (with timespans) and later develop an availability approach that would satisfy all the possible availability cases.

So this patch includes this one:
http://drupal.org/node/641850#comment-3145876 - http://drupal.org/files/issues/641850_node_repeat_19.patch

As it was based of an older version so I had to walk through 1000+ lines and mix them correctly together.

Anyway, I also changed the caching model to a hashed one (as we won't have only one timespan).

Regarding the availability, I give users opportunity to use a specific view that will have start and end rows in its results. I did ahah way of specifying what way should the availability be used and changed some error messages.
I also give the opportunity to alter the view with hook_resource_conflict_view_alter($view, $display_id, $node).

I've attached an image of how it should work (general concept) and the patch itself.

I'll eagerly wait for your replies.

Made some unix-clean-up with the right endings (previous was giving me some errors in linux system).

And again, I've made some small fixes.

Niko, it its generally not a good idea to mix multiple patches. So if its possible I'd suggest that you try and keep this focused on the task.

Also you backport some Drupal7-functionallity: Is this really really necessary?

How could I integrate caching and OG awareness to this patch? I mean that I had to modify those as well.
Backporting some of the Drupal7-functionalities was a part of other patch.

I've forgot to clean-up the variables on uninstall.

Why does caching need to be integrated for this patch?

Why does this patch need to make resource_conflict og_aware?

You realize - someone has to actually go through and check every line in this patch? It makes more sense if it just completes this one functionallity. :-/ Sorry to say this ~ especially since the maintainer doesn't seem active at the moment.

Doesn't that somehow slowdown considerably the development and new features integration?
Original caching patch would be useless if we apply the node repeats patch, and og awarness also loses it's meaning there.
It doesn't make resource_conflict og_aware out of the box, it gives this option to users, if they want to.

I don't know, who would apply node repeats + availability if it makes all other patches useless?
Or we have to wait until the maintainer would actually apply the node repeats + availability, and only then open 2-3 more issues in the issue tracker regarding making it og_aware and caching and stuff? Would that take ages?(

Nah, if I'm doing something wrong and there are better ways to do this all, I'll collaborate :)

Thanks.

Quality and security are also important factors.
Your patch has has over 1100 lines adressing multiple different issues adding undocumented (nor discussed) features. Who is supposed to review that?

The issue queues idea basically is to provide patches towards the modules code in order to have it improved - not an feature repository for the users.. The maintainer reviews the patch and gets it into the development-version. Thus if you have new features and/or new bugs you open additional issues. If your patch depends on other patches you mark your patch "postponed"

You can also read here http://drupal.org/patch/submit

So I'd suggest you open multiple issues or ask deviantintegral to become a maintainer :-)

This is addressed in the coming 6.x-3 and the current 7.x-3 branch - you can set availability with Rules.