Dates as Entities
A core concept presented in this module suite is "Dates as entities." The dates as entities are referred to "Date sets," and are managed from a user-specific calendar-based UI. An administrative user can create numerous "date set" bundles, which can each have their own fields. The end users then place "date sets" onto their calendars. Each new "date set" bundle automatically has fields attached that help sort the instance onto one or more schedules, and into "repeating patterns." The date sets then utilize entity view modes on the calendar output.
Repeating Patterns as Entities
The Date Repeat module provides a Date Repeat UI for managing a repeating date field. This module provides a Date Repeat UI that manages numerous entity instances that can each be of different bundles. It pulls the pattern out of a field formatter and puts into its own entity. The pattern has a title, is fieldable, and integrates with a user's schedule.
Schedules as Entities
Each user gets a "Schedule Manager" that allows "date sets" to be reviewed, edited and placed onto a specific time via a Calendar-based UI. A user can have multiple schedules, and have date repeat patterns that integrate multiple "date set" entities and "pattern" types.
Date exclusions as Entities
Seems crazy, but now you can have multiple types of date exclusions (e.g. "sick days" vs. "holidays" vs. "cancellations") that are fieldable. You can put explanations body fields onto exclusions, apply the exclusions to numerous date set entities and even display a calendar of exclusions. The default Date/Date Repeat modules treat exclusions as negative entity -- it's just a hole in your calendar with no explanation. By making exclusions entities, we can describe why something is cancelled and even treat the cancellation as a "substitution" by putting something on the calendar in place of the cancelled date.
Why the added complexity?
This post describes some of the same motivations I had for starting this project: http://groups.drupal.org/node/18628
The primary goal here was to provide a calendar-based UI for adding dates of various types to a user-specific schedule of events. After much user testing, it became a recurring request for repeating sets of dates to be manageable in bulk. The Date Repeat API lets you set up complex repeat rules for 1 single entity instance. This module lets you set up complex repeat rules that apply to numerous entities.
Quicker updates to shared repeat patterns across numerous entities
For example, say you have a class schedule that repeats 5 different classes for 6 months. Then you want to extend the repetition of all 5 classes another week. In the current Date Repeat module, you'd have to edit each of the 5 different classes, one-by-one.
Variations within a repeat pattern
Another example: say you have a single class that repeats every Tues/Weds for 6 months. What if on Weds, it was a different time of day? What if on Tuesday the class had a different location than it does on Wednesday? By separating the Date from the "Class" and separating the Day of week and Time of day from the "Repeat pattern," new layers of flexibility are added.
There's still a few holes in this module that need to be filled. Any help would be greatly appreciated.
Date repeat exception handling. Allow single instances of a repeat to be deleted separately from the entire date:
- Currently only weekly repeat patterns are supported. You can create Monthly repeats, but they are broken:
Permissions need to be tested. Right now I think any user can add an event to any other users' schedule. The schedule reference field on "date set" entities needs to be protected:
- Allow co-ownership/sharing and multi-user management via the User Relationships module or possibly OG
- Break schedule date management away from the Pattern-related "WeekBuilder" object. Set date schedules were orginally placed into a custom calendar that was week-based. By integrating Calendar module, a lot of this has become unnecessary.
- Fix the Date repeat "Manage Dates" view to be a Calendar Week view and not a hacked Calendar month view that's boiled down to a set number of weeks. It currently works well, but I think this could be improved
- AJAXify the UI: This module was originally a not-so-modular module that was developed for Drupal 6. Events could be drag/dropped onto the calendar. A ctools modal form AJAX handler would really push this to the next level.
- Better tying together of related entities. Integration of CER
- Quick configuration of the ""Represented Entity" (see below) either with Inline Entity Form or some kind of views select widget:
I originally had Event nodes drag/drop onto a calendar, which would pre-populate the "referenced entity" with the dropped node. This was awesome, but it was D6 code that had too many hard coded references to the specific site content types and depended heavily on the abandoned Ajax module
- Better language support -- I have
[LANGUAGE_NONE]hardcoded in many field references.
- Tie in the pattern entity into a new formatter for the Repeat field formatter, which would address these issues:
- Calendar import/export with gcal and with ical
Important Requirements / Installation instruction
Patch to calendar
A patch needs to be applied to the Calendar module in order for this module to work.
Alternatively, the plugin this patch creates could be integrated into this module, but I'd rather not completely separate this module from Calendar. Please post on the above issue and encourage the Calendar maintainers to make their code more extensible.
Patch to date
There's a field provided in this module that allows time entry without Year/Month/Day -- this causes a small UI problem that can be solved with this patch:
Again, please get in that queue and test and let the Date maintainers know how it makes Drupal more awesome.
You must install ALL modules
There are 5 modules included in the main "dsm" folder. All 5 are required. Installing only a few will break your site because they cross-reference PHP classes. If you install/uninstall only 1 of the 5, you will get fatal "class not found" errors. Technically the "Exclusion" module is not required, but you'll need it if you want to handle date exclusions.
Configuration of a "Represented Entity" field
When you install all 5 modules, it should be pretty intuitive what to do next, but there comes a point when you're asked to configure a "Referenced Entity" field. A Date set is an entity that should only have date related fields. The "Represented Entity" could be an entity that has non-date related fields. For example, if a class has a related image, description and difficulty field, these fields don't change by date. The Class would be a node, while the Class Date would be a "date set." The "Represented Entity" field ties them together. It's not a required field, but it could be useful. I recommend using it.
Configuring a schedule
After installation, you will be directed to create a date set entity type. Once you've done this, you're ready to start building schedules. The "Schedule Manager" link exists in the user menu. You can navigate to "/dsm" or "/dsm/UID" similar to the way "/user" works. This is set up this way so schedules are user-specific. It should be fairly intuitive from the UI what to do next.
Displaying a schedule
There's nothing in this module that will display a schedule onto the front end. Everything is built with standard Date Repeat fields and Entity Reference fields, so configuring the front end is up to you. You should be able to create a Calendar view just fine with all of the data types this module provides.
Problems with Date module that become apparent here
Time vs. Date in UI
There are 2 concepts in this module that are difficult and buggy to work with, both are related to the core of Date module.
- Date without time:
- Time without date:
Any love in these issues would make this module and the Date module a little bit better to live with.
Repeats stored as individual date records in DB
This module uses the Date Repeat module to create repeated date field records. Unfortunately, the Date Repeat module stores each instance of a repeat rule as a record in the database. This blows up the site when you want your repeat to have a duration of several years or so. I don't know a way around this, and this module doesn't address that issue.
First instance of date repeat can't be excluded
I tried to work around this, but it causes a problem when reviewing the repeat pattern. It's related to these issues:
We've tried to make the code as intuitive as possible. It makes heavy use of the Entity API and Object Oriented Programming. As much of it is commented as possible. If you'd like to get into the code and get involved please let me know on the issue queue.