Easier updating of calendars: book ranges at once

I agree, that would be a very useful feature.

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

Displaying different pricing can be handled with #306461: Custom availability states and legend where you can replace the "available" state with states "low", "middle" and "high". Easier updating is in the make, but will probably be first released for the D7 branch.

I do want to mention my opinion on the better updating of the calendar. I feel that bring the look and feel of the frontend to the backend edit form would be the best way to go.

The backend should look like the calendar on the frontend and make it easy to update.

I threw together a google drawing here:
https://docs.google.com/drawings/edit?id=1dBLYFYfdqbWyjbHPCKXjMqx-FNoygO...

You are welcome to collaboratively edit it so that we can come to an agreement. This is how I would suggest a specific month look when clicking the edit option.

Note that the first day shows my suggestion as to how to format the days. It would be too much work to update each individual day in that drawing.

I certainly agree on the frontend/backend remark, that is the way to go (here and in the booking process integration as well).

Regarding updating the states I think that, like the OP, I would like to see changing whole ranges at once. Let me publicize the part of the roadmap regarding this feature. (Roadmap being based on my current project requirements, which includes integrating the features in such a way that they can be committed to the publicly available module: thus including upgrade path, offering possibly disrupting features as an option, etc.)

• Present calendar as when showing it in view mode,
• But in the split day situation with all days renderd as split day.(One of the reasons for independent am and pm styling, as implemented in #660502: Custom Colors Using Administration Interface.)
• Show the states as a set of radio buttons.

1. User selects state in set of radio buttons.
2. User selects date by clicking on a date.
3. User selects a 2nd date by clicking on another date.
4. A textarea/hidden field gets updated with a command like: {state}: [start_date} - {end_date}
5. Calendar gets visually updated by changing states using javascript.
6. User continues from 1 or 2. If 2, state for the next command line remains the same.
7. Or user clicks “save”: textarea/hidden field is send to server and is processed line by line.

Notes, questions, and issues to be decided with this workflow:

• Textarea or hidden field: for reasons of accessibility an editable textarea may be better.
• (Canceling a command may also be easier with an editable textarea, but will be difficult to revert in the calendar).
• Start date and end dates will be ordered if not clicked in correct order.
• Split day situation: start_date will be changed for pm only, end_date for am only, in between dates whole day. If start date = end date => am and pm will get new state.
• If user selects a new state before ending current command, current command is canceled.
• Overlapping periods are allowed, lines are processed 1 by 1, thus later lines override earlier ones. Thus setting mid-season from May to September and then August to high-season will have same effect as setting May-July to mid, August to high and September to mid.There are of course also still questions:
• Use ajax for direct updating and remove the textarea/hidden field? (option to cancel/revert?)
• If editable textarea: should changes there be visualized in calendar?
• Fall back for accessibility or split day situations that are not easily handled with this scenario?
• Display 1 year, display to end of period? display old dates? allow to change old dates?
• What about the notes: text fields in the calendar or separate screen?

Only 7 clicks (state, date, date, state, date, date, save) to set the seasonality for a whole year (as per the given example). Only 4 clicks (state, date, date, save) to update the calendar on a booking, regardless of its length (week, weekend, 2 weeks, mid-week, whatever)

Committed to 7.x-2.x-dev.

Back porting to D6
To facilitate back porting I did a rudimentary back port of the current 7.x-2.x branch to a new 6.branch named x-2.x-backport. This includes this issue as well as #1083198: Optimize storage for tables of Availability Calendars. Anyone interested in completing and testing the back port?

What you will need to do:
- The functions that access the database (in availability_calendars.inc) need to be updated. The fields year, month, and day do not exists anymore.
- The functions that access the database (in availability_calendars.inc) that are new (availability_calendars_..._range) need to be rewritten to the D6 database API.
- The new javascript file needs some small changes to work with D6.
- The theme functions (availability_calendars.page.inc) need some special attention, as some parameters were added. check if they are passed in and if they appear in the correct order.

Please assign this issue to yourself when trying to do the back port.

I want feedback from other users about this new feature. Please try and test this new feature and report all your comments, remarks, suggestions, errors, etc. Specifically I want answers to the following questions:

- Currently this feature is a pure addition to this module. It does not replace the current way of editing calendar months. So both are still possible.
* Should we keep both ways of editing?
* If yes, where and when to show the edit links (I would prefer on the new edit calendar tab and no longer on the view node tab.)
* If not: how to edit week notes?
* If not: how to edit "special" split day states?

- The changes to the calendar are collected in a textarea and send to the server on submit.
* Should we show this textarea or make it a hidden field or collapse it by default?
* Will it be clear that the calendar will not be updated if you do not click submit?
* If not, does this imply that we should use ajax for immediate updates?
* Would an undo be needed?

-Should we allow to edit old dates (in the current month, older months are not shown)?

Please help us complete this feature in a way that will make your and our clients happy!

Some screenshots to show what has been done:

1: Click on new tab "Availability Calendar".
2: Click on the state you want the date range to change to, The radio button will become selected.
3: Click on start date: it will be highlighted, class="calselected", so you can style it the way you want.
4: Click on end date: state and date range will be stored for submission to the server. Range will be visually updated.
5a: repeat
5b: Click on submit to send all changes to the server.

Someone any remarks?

OK, to progress towards a 7.x-2.1 release, I made some of the above requested decisions:

- Edit calendar per month will remain available. However, it can be disabled with a setting (system wide or per node) as it won't be needed in all cases anymore (only if you use week notes or have special requirements for split states).
- The "edit" link (right of the month name) will only be displayed on the edit availability calendar tab. Thus no longer on the view node tab.
- the number of months that is displayed on the view node tab will now always be as defined in the settings, also for visitors with the edit calendar permission.
- On the edit availability calendar tab the number of months displayed can now be set with a separate setting.
- The textarea has been changed into a hidden field.

Defaults for new variables:
- edit link will be visible
- 18 months are displayed to editors.

Visit the admin settings page after upgrading if you want different or the old values.

IMO, visual feedback to editors still needs some attention. anyone some ideas:
- on clicking the start date, not only make it bold but change the state to the future state as well?
- use a different cursor?
- dynamically change the states of the range on mouse move/hover?

- The new 7.x-2.2 version contains more visual feedback: a pointer cursor and a border around the cell on hover and in (7.x-2.x-dev) the border stays visible on a selected cell.
- Although the javascript in the 7.x-2.2 version performs much better than before, dynamically updating the states on mousemove (and between 2 clicks) probably still puts too much demand on processing power. So I'll skip that for the moment.
- As the javascript has an infinite "restore old states" function, an undo button could now be added relatively easily. But I will also skip this for the moment.

So I will close this issue, as the original request has been satisfied to an extend the OP probably would not have dreamt of. Separate issues may be created for individual ameliorations.

When this will be officially ported to drupal 6?
Looks like a very interesting feature to have.

Thanks
Marco

I can't currently invest the time to do a backport. And as far as I can see the other maintainer doesn't have that time either. If someone else posts a patch I will assist in getting it committed.

Try to find funding in the project where you want to use it and back port it yourself or hire us to do it (note that the D7 version of this feature was also funded via a project that needed it).