search

subscribe

Have you found a solution for that ?

This would be a cool feature, especially if the module can work with views (filters).

Please tell me if you find a solution

I agree with #3

Maybe this comment about other Issue of the same Module can be useful: http://drupal.org/node/312402#comment-2011228

Lusco, do you have some end time in mind?
Just to know what to do...

Thanks in advance!

Amazing +1

if this gets added it will be in 2.x branch

changing to feature request

OK, I'm starting to do some work on this request.

Prerequisites
Because of #306461: Custom availability states and legend we need to know for each state whether it is to be regarded as available or not.
- Add a boolean field to the states table indicating this.
- Add a checkbox to the edit states part of the admin settings form to edit this field.

UI
I guess that the date fields used to search for availability, typically will be part of a larger search form (allowing to also search on price, number of persons, number of bedrooms, ...). Furthermore this search form might present 1 date field and 1 duration field (select) instead of 2 date fields, or any other slick way of letting the user indicate when he wants the availability.
- So I guess we won't do any UI/form building for this request.

Searching
Given that the search might be part of a larger search form, we would have to be able to add conditions to a query builder. D7 provides a query builder, so that is what we will use. Back porting to D6 will thus not be easy.
- I envision an API function that accepts a query builder object, and adds the conditions to it.

Expected difficulties
I'm still not sure about how the query conditions will look like especially taking into account:
- default state: not all days have to be stored in the table, module assumes the default status for days not present in the table
- default status might be available or not available, impacting the SQL to generate to a very large degree
- default status might differ per node if the setting "Allow to override settings per node" is enabled, further complicating the SQL to generate.
- If the "Allow split day statuses" setting is enabled special start and end day handling will be needed in the generated SQL
- Translation sets share 1 calendar. Thus the resulting node id's might not be of the current language, so we will have to find the counterpart nodes in the current language.
- ...

I hope to overcome all these difficulties and be able to present a generic solution. If not this will become a documentation issue, outlining how to set up a search under some given conditions.

Sorry if I mistake, but is not more reasonable (and simple) add a views support (for D6 and D7)?
With a views support the search can be made with a filter exposed in the view!
Thanks in advance and sorry if I mistake.

Well, that filter will need the same code in the background to filter nodes, so integrating with views does not take away the expected difficulties. It would however give a simple integration at the UI level making it more accessible to web site builders that don't want to program.

So eventually, views integration will be the way to go.

I understand. Thanks!
But will be integrated with views in D6?
If you need someone for testing I'm available. :-)

Thanks for your work!

subscribing

OK, the expected difficulties from #11 turned into real obstacles.

- default state: not all days have to be stored in the table, module assumes the default status for days not present in the table
- default status might be available or not available, impacting the SQL to generate to a very large degree
- default status might differ per node if the setting "Allow to override settings per node" is enabled, further complicating the SQL to generate.
- If the "Allow split day statuses" setting is enabled special start and end day handling will be needed in the generated SQL
- Translation sets share 1 calendar. Thus the resulting node id's might not be of the current language, so we will have to find the counterpart nodes in the current language.

The default status being available or not available and the translations ets issue can be overcome by rewriting the query. However the different default statuses per node and the split day status are real obstacles.

What is the problem?
Different default status: the value of the default status to be considered available or not-available makes the query completely different (basically searching using a not exists clause versus a select count = %number_of_days clause). Thus having different default statuses cannot be combined into one query. Being able to do it in 1 query is paramount in the case where we are extending another query (e.g. searching on price range, number of people or bedrooms, or geographical region)

Split day status: the format of the status field of the availability_calendar_day table is too free. It may contain values like (and all these values are telling the same story):
* calav calnotav-pm
* calav-am calnotav-pm
* calnotav calav-am
* calav-am calnotav
So no way I'm going to get this into a query, especially not if one state is a substring of another one (e.g. using av and notav versus calav and calnotav). Remember that regular expressions are a no go in standardised SQL.

Solution
A solution would be to remove the following features:
- Settings per node.
- Split day from the database.

Consequences
Consequences are the loss of backwards compatibility for sites that:
- Do actually use different settings per node.
- Do use multiple states per day, where the 2nd state of a day does not need to match the 1st state of the next day (i.e. their resource can be booked twice per day).

Why is this not so bad as it may seem?
Settings per node: this feature will be removed anyway when converting to fields. With fields you will get settings per node type, which is probably what you wanted anyway.

Split day:
[@see comment http://drupal.org/node/721762#comment-4203092 and the agreement on that from the other maintainer:
http://drupal.org/node/721762#comment-4205722 ]

The split day status is primarily meant to indicate that you are renting out per night, not per day. So in cases where the calendar is used where it is meant for, namely whole day/night renting, not intra-day. the pm state will always equal the am state of the next day. And if that is the case there is no need to store that data twice in the database.

Moreover, currently if you are switching the setting from split day to whole day or vice versa nothing is changed in the database. This kind of makes this an unusable setting for live sites. So moving this setting from the database storage level to the UI level, makes it actually more useful for the intended usage.

Updating
Of course, making the decision to remove some features means a lack of backward compatibility in some situations. So we are planning to do this in a new major version and in D7 first. The upgrade path will need special attention as well: checking if the database can be converted without loss of information, reporting problems, doing the actual conversion.

Please tell us what you think
So what are your ideas on this? Agree and acceptable? Totally unacceptable (and why)? All reactions are welcome. These ideas are still young and absolutely not decided on, so your reaction may make a difference!

IMHO It can be a good idea...

subscribing

Backwards compatibility is important, but when it stands in the way of future improvements it sometimes is better to stop development and maintain the software as some sort of legacy.

A new version with new features can then be developed without the need for backwards compatibility and using newer and improved technology (faster deployment, richer feature set, etc)

so in my opinion updating and losing backwards compatibility is acceptable. If it is implemented on version 7.x it will not break 6.x versions at all.

subscribing

Please find the next version of this module on Availability Calendar. Started as a complete rewrite, it is currently in its own sandbox. A tar.gz can be found as an attachment in issue #1252106: Beta1 release as tar.gz.

This version has:
- Fields based (so D7 only).
- Views integration including ...
- Filter on availability.
- Booking integration by means of a separate booking formlet field.
- Show week numbers option.
For an in-depth comparison of all current features see the included "README when coming from Availability Calendars.txt".

An upgrade path is not yet available but will be in the near future!

Please have a look at the new version and report any findings, bugs, suggestions, etc.

Note specific for this issue (the above text is used in a number of issues that can be closed by this new version):
I indeed removed split day future at the database level and it is now a display setting. So you can edit in full-day status and view in split day or have the teaser show slit day and the full node view showing in full day.

This sound great! thanks

Moved the sandbox project back here into the 7.x-3.x version.

The search function has now also been backported to 6.x-2.2 (with the restrictions of not using split day and not allowing to override settings on a per node basis).