Allow relative dates for scheduling and registration reminders

I'll see what I can do then. But it might take some time.

Perhaps you can think along with me to get this first time right.

The registration should be aware of a possible event date, thus we should add a property (event_date) to the registration entity. This property is to become the base for relative dates so that '-1 day' is calculated as event_date -1 day. There are two possible options;

1. This becomes a computed property, so during entity construction we calculate it's value based on the parent. (This requires updating eg. cron functions where we will not be able to use the database anymore, but we'd need to build entities.)
2. We add this field to the registration_entity table, but we must make sure to update the field every time the parent (date field) is updated, so it is always kept in sync.

On registration entity save, we update the reminder and schedule date fields with the newly calculated values reminder_date = event_date - x days or, when no event_date is provided (or the user does not want to use relative dates) we use the current date field. This makes sure all current implementations remain functioning as they are and requires some form API #states magic. The problem is we should store all relative date settings; open -10 days, close -1 day, reminder -3 days. Would a database blob field work (as we don't need this data to be readable or writable anywhere else except for in the forms).

Summary

Should we calculate the event date based on a parent entity's property OR do we want to clone the field value and make sure it is always kept up to date?
Would it suffice to store all relative date values in a database blob to prevent creating lots of new db columns which don't require reading or writing except for when used in the form?

@Greg, could you perhaps share your thoughts on the proposed changes?

Temporarily removing myself so hopefully a maintainer sees the issue.

Thanks Greg, I understand and I guess I can handle most of the issue by myself, I just wanted to get these basics discussed so I can write something that fits the module as good as possible.

The problem is twofold;

1. In order for a relative date to work, the registration module needs to be aware of the event date. The way node registration handles this, is by referencing a date field on the node and loading the date from there. The alternative option is to add a field to the database which stores the event date.
   The question, should we
   1. Load the event date from the parent entity (node in most cases), where it is likely to exist already (calendars, event listings, etc.)?.
   2. Store the event date on the registration, all settings for registrations are in one place and can be changed easily. Users might however change the date on the node and forget about changing it on the event.
   3. Offer both options and have the user choose to use the parent field, or use a 'local' value.
2. We need a place to store the relative date formatter. This can be a string in the form '-n days 5 hours' etc. This string is never to be used in Views and is just a setting on the registration field, therefore it is suitable for storing in a blob. My idea was to convert this setting during entity save into a regular date and store that date in the appropriate existing field (open, close, reminder date). This should work as long as nobody alters the date programmatically as the date will be out of sync with the relative date (we might need a mechanism to detect such a change).
   This has the following advantages:
   1. Relative date is built on top of current registration functions.
   2. Relative dates are not required and people can still use the existing date fields.
   3. All registration processing will function as it currently does.

   Is this solid or am I missing things?

I hope I explained better now. There are two things I'd like to know before I start.

Which of the options in 1 better fits this module?
Is storing relative date strings, which are only used during the saving of registration field for calculating other date fields in a blob ok?

Awesome! Lets do this :)

This is what I came up with. I contains a database update hook, so you need to run update.php.

It still needs some checking if the linked date field actually contains a value, relative date options should be completely disabled otherwise.
Further it seems the state options are terribly broken somehow so all fields are shown at once. (No idea why though...)
Finally, the form validations might need some time but I could not look into that yet.

Last you want to know is that the fields are fully compatible with php relative formats, so you can enter things like -2 weekdays, -1 month, first day of this week, etc.

Please let me know what you think, I can continue working on this tomorrow.

Credits to nielsonm and oranges13 for their initial work on this.

Removed some TODO's as they were already done...

States API is fixed and the linked date field is actually working.

Now there are some validations that need updating (such as the registration requires a date check).
Also if no field is provided, it should not be an option to select it and minor ui tweaks (such as field descriptions).