Automatically Create Registration Settings when Entities are Created

Thanks @dpi. I don't think registrations should be enabled by default when a new entity is created but before a user has had a chance to configure settings. It'd make more sense if we had a default settings form at the field level.

Agreed with levelos here.

Just as a simple use case, we have an 'event calendar' that has the registration entity tied to it. Most of the events aren't registration based, only a few. A configuration option would be wonderful, but to force it on by default without an option to disable this seems a bit backwards.

It was mostly my misunderstanding. I am not completely familiar with the new version of this module yet.

I may take a crack at this update this weekend. I need more exposure to entity's and how they are all tied together.

To me, it makes sense that we have these config settings on the manage registration %entity% edit page. The defaults... to the defaults should be:

Enabled : 0
Capacity : 0
Reminder : 0
Reminder Template : [empty string]
Allow Multiple Registrations : 0
From address : [admins email]

These defaults will then propagate to the specific add/edit content registration entity.

Thoughts?

I'm new to all of this, but it seems to me that the default value for Enabled should be 1 -- similar to the way that a new node is, by default, set to published. In most cases, when someone creates a new registration entity, it is one that he wants to be immediately available for registrations, and not one to be enabled at some point in the future. Furthermore, if the entities are being created by non-admin site users, they may not even be aware that they have to also enable the entity, and otherwise no one can register.

@dpi, great start. I agree that the idea place to store these is at the field instance settings level, which can obviously be overridden per entity. Interested in flushing it out a bit more?

It would be great to get some feedback on the 'needs review' issues in the queue as well before too many incompatible patches are submitted.

Agreed. I took a swipe at a number of them this morning.

+1

Just a matter of philosophy, but would it not be better to just have the hook_registration_update_entity_settings return an array of settings that gets merged with the array in the base function? This way module developers wouldn't have to write to the database and have their own settings just get overwritten since the base function doesn't take into account changes in the settings in between function call and actually writing them to the DB.

IE: Default settings set status to 0, registration_update_entity_settings is called, triggers hook functions which update status to 1, registration_update_entity_settings is done with hooks, merges settings into DB which then set status back to 0.

new patch, hook is called from inside the insert

You mean a UI for admin/structure/registration_types/manage/ so the defaults can be set? If so, I will have a look at it later, my patch just added all settings and uses a hook to alter them.

This patch adds a 'Default registration settings' fieldset to the field instance form.
These settings will be the default for all entities of the bundle the field is attached to.

This time without whitespace errors...

I adapted the patch so the fieldset is open by default

@dpi, so the difference with our implementation is:

1. you use variables instead of field settings? Are there benefits?
2. we have an extra hook so other modules can control the settings from code, see example
3. you re-use the form, we don't

function MY_MODULE_registration_settings_alter(&$settings, $entity) {
  if ($entity->type == 'studiedag') {
    $settings['status'] = 1;
    $settings['open'] = date('Y-m-d H:i:s');
  }
  else if ($entity->type == 'cursus') {
    $settings['status'] = 1;
    $settings['open'] = date('Y-m-d H:i:s');
    
    $field_cursus_datum = $entity->field_cursus_datum;
    $field_cursus_datum = array_shift(array_shift($field_cursus_datum));
    if (is_array($field_cursus_datum)) {
      $field_cursus_datum = strtotime($field_cursus_datum['value']);
      $field_cursus_datum = $field_cursus_datum - (60 * 60 * 24 * 7);
      $settings['close'] = date('Y-m-d H:i:s', $field_cursus_datum);
    }
  }
}

I'm good with storing the settings inside variables, although personally i prefer my approach. Only thing i would like to see in your patch is the addition of our hook. And then i think this can be committed?

Sorry for the delay gang. I took inspiration from both of you and implemented in 8b4ceb36a2a2222b0afc589afb375a7f2fae73e0. Quite a number of changes in there, so some review/testing would be great. @dpi, if/when you get around to it, probably a great candidate for a unit test.

@dpi, just pushed a solution. Ref: c6eaa1ecbbb3706eb7c7e929d88d9ca4c8870081.

I think this is the appropriate place for this, if not please excuse me.

After turning on the current -dev to try testing the default settings I get

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'ucg7dev.registration_state' doesn't exist: SELECT base.registration_state_id AS registration_state_id, base.name AS name, base.label AS label, base.description AS description, base.default_state AS default_state, base.active AS active, base.show_on_form AS show_on_form, base.weight AS weight, base.status AS status, base.module AS module FROM {registration_state} base WHERE (base.name IN (:db_condition_placeholder_0)) ; Array ( [:db_condition_placeholder_0] => test_state ) in EntityAPIController->query() (line 152 of /mnt/www/html/ucg7dev/docroot/sites/all/modules/entity/includes/entity.controller.inc).