Provide a view that replicates the "node/%/registrations" list with Views

I was thinking a views bulk operations view ala Organic Groups 2.x, if the module is available.

Although we need a few more views fields to be added.

Thanks @lsolesen, but we very intentionally did not make this module dependent on Views. If you want to override the default display with a custom view, that easy to do and your prerogative.

I'll bring back my example of Organic Groups, they have no dependencies on Views Bulk Operations (VBO). Like Registrations implementation of the 'Devel' tab on registration entities, there is no dependencies, its just there if you have it.

Registration provides Views functionality if you have it, but its not a dependency.

If you don't have VBO, then default to a generated table.

I'm willing to work on this, as its on my to do list as well. I need to bulk set an 'availability' or 'attended' field.

I planned to override the page callback to inject a view, so I don't care if that becomes a function of the module, but VBO support would be great.

I understand the point made by levelos and it is a reasonable decision to not make the module dependent on Views.

What would be great however, and I think this is what #6 is referring to, is if the module shipped with a default (inactive) View that essentially replicated what was in the module, so that if you had Views installed you would see that, and if you activated that View it would automatically be a drop-in replacement for the current registrations handling. This would mean that if a site builder wanted to add just a single field to the current table, they could just activate this default view, make one minor modification to it, and it'd be done. That'd be a nice feature. And of course for more significant changes, this provides a departure point as well, which would be a help for less experienced users of Views, and maybe even the more experienced ones too...

So a feature request. :)

@babbage, reasonable and well put request. If/when added, it should be the registration_views submodule.

thanks for your code in #2

when I try to import I get this error:

Field handler registration.mail is not available.
Field handler registration.mail is not available.
Unable to import view.

which modules must be enabled in reference to this

/* Field: Registration: Mail */
$handler->display->display_options['fields']['mail']['id'] = 'mail';
$handler->display->display_options['fields']['mail']['table'] = 'registration';
$handler->display->display_options['fields']['mail']['field'] = 'mail';
$handler->display->display_options['fields']['mail']['label'] = 'Email';
$handler->display->display_options['fields']['mail']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['mail']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['mail']['alter']['absolute'] = 0;
$handler->display->display_options['fields']['mail']['alter']['external'] = 0;
$handler->display->display_options['fields']['mail']['alter']['replace_spaces'] = 0;
$handler->display->display_options['fields']['mail']['alter']['trim_whitespace'] = 0;
$handler->display->display_options['fields']['mail']['alter']['nl2br'] = 0;
$handler->display->display_options['fields']['mail']['alter']['word_boundary'] = 1;
$handler->display->display_options['fields']['mail']['alter']['ellipsis'] = 1;
$handler->display->display_options['fields']['mail']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['mail']['alter']['trim'] = 0;
$handler->display->display_options['fields']['mail']['alter']['html'] = 0;
$handler->display->display_options['fields']['mail']['element_label_colon'] = 0;
$handler->display->display_options['fields']['mail']['element_default_classes'] = 1;
$handler->display->display_options['fields']['mail']['hide_empty'] = 0;
$handler->display->display_options['fields']['mail']['empty_zero'] = 0;
$handler->display->display_options['fields']['mail']['hide_alter_empty'] = 1;

I've read that you can override the default list of registrations for an event, but I'm not sure how that is to be done if the default table is in code. If I create a new view that lists the columns that I'd like to appear for managing the registrations on an event, how do I replace the default Registrations tab?

Please create your own issue without hijacking others. Thanks.

My apologies. When I realized I had posted in the wrong place I tried to delete the comment but could not find a way to do so. I then erased the text and created a new issue.

Ditto to #9. A feature like this would have saved me hours and kept a few extra hairs on my head.

@babbage is on point with this concept.

I looked in the README file and cannot figure out how to override the current table with views. It would be much appreciated if the default views were added so that we can easily alter the display.

This would also help with creating views to export the registrations in different data formats #1923428: CSV Export for Registered Participants

Also if views has already been added to D8 core then I don't see the downside to have views as a dependency.

With this said I am not a php developer and do not understand the complexities of implementing something like this so it would be great to hear an explanation :)

@Isolesen: #3 patch failed.

root@ubuntu:/var/www/vhosts/drupal.local/htdocs/sites/all/modules/registration# patch -p1 < view-instead-of-table-issue-5707586.patch 
patching file registration.module
Hunk #1 FAILED at 224.
1 out of 1 hunk FAILED -- saving rejects to file registration.module.rej

why not just modify registration_registrations_page() function body to return a formatted view instead?

regarding edit, should've read through your patch first.

am trying to replicate the node/%/registrations table with a view - however, cannot get the system user or anonymous user email into a single view column, without loading each registration entity, as registration.module does:

$wrapper = entity_metadata_wrapper('registration', $registration);
...
l($wrapper->mail->value(), 'mailto:' . $wrapper->mail->value()),

when adding view relationships, only the anonymous email is provided - but not either system user or anonymous user email into a single field.

anyone have a way to do this without views_php?

didn't notice how long ago patch #3 was submitted. the following replacement for function registration_registrations_page() worked against registration -dev, commit c47de239d535628f9ebf9afd73ee21c53e7b9891.

assign $view_name and $machine_name as needed. works with entity type node, views data export. haven't tested with other combinations.

function registration_registrations_page($entity_type, $entity) {

	list($entity_id) = entity_extract_ids($entity_type, $entity);
	$settings = registration_entity_settings($entity_id, $entity_type);
	$label = entity_label($entity_type, $entity);
	if ($settings['capacity'] != 0) {
	  $caption = t('List of registrations for %title. !count of !capacity slots are filled.',
	    array(
			      '%title' => $label,
			      '!count' => '<strong>' . registration_event_count($entity_id, $entity_type) . '</strong>',
			      '!capacity' => '<strong>' . $settings['capacity'] . '</strong>'
			    ));
	} else {
		$caption = t('List of registrations for %title. !count slots are filled.',
	    array(
			      '%title' => $label,
			      '!count' => '<strong>' . registration_event_count($entity_id, $entity_type) . '</strong>',
				    ));
	}
	$view_name = '{YOUR VIEW NAME HERE}';
	$machine_name = 'page';
	$args = $entity_id;
	$view = views_get_view($view_name, TRUE);
	$view->set_display('block');
	$out = t("<h2>@title</h2>", array('@title' => $view->get_title())) . '<p>' . $caption . '</p>' . views_embed_view($view_name, $machine_name, $args);
	unset($view);
	return $out;
}

Attached is a patch against registration_views .

Some observations:

1. The email field could be made easier with a custom field handler for views. The only option available is the Regsitration: Anonymous email or you have to reference the registered user, then grab their email address.
2. Views only lets you select 1 access permission. To make it identical to the current permissions check we'd need a custom plugin that checks for entity type specific permissions. e.g. "administer own $registration_type registration" and "administer $registration_type registration" rather than the standard "administer registration"

Fixed an issue with the menu tabs/url.

Ugh. let's try that again. Fixed an issue with the menu tabs/url.

moonray, #23 patch included registration_views_views_default_views() inside of your docroot folder. anyway, the table provided by registration_registrations_page() still shows when your view is enabled, still, after caches are flushed.

can you define a single views field for mail as registration_registrations_page() does (see #19) - inside registration_views_views_default_views()?

...

@jaypark: My view includes both the user email address field and the anonymous field. The anonymous field is hidden, and rewrite field enabled on the user field to include both fields' output. When user email exists, anonymous wouldn't and visa versa. It looks like 1 field in the output.

EDIT: I just figured out I was missing an option. Adding this line will make the anonymous emails display in the user email field.

<?php
  $handler->display->display_options['fields']['mail']['hide_alter_empty'] = FALSE;
?>

As for the default page view displaying vs the view, I'm not sure why that's happening for you. It works on my end.

@moonray,

could you re-roll a patch with your most recent change ? Would love to give it a test.

Thanks

Updated patch takes the work from above and updates broken relationships and filed handlers, and adds the file to the correct location within registration_views. I couldn't get the slots used header text working, as there doesn't seem to be a relationship that lets you get back to the host entity.

Updated patch. Last one wasn't right.

@mrfelton thank you so much !! Please show some love to @jaypark, @mrfelton, @moonray for getting it done !

I am confirming that this patch works but you must configure your own view's url as follows: node/%/registrations.

Here are a couple of questions

• Features: For some reason when I attempt to export the view in features, I am able to check the view but it is not included in the features export. Not sure if this is related
• Default View: Is it too much to ask to have the view already created but disabled ?
• Also once you enable your own view the message stating how many slots available disappears. Any help to get that message back would be great.

> I am confirming that this patch works but you must configure your own view's url as follows: node/%/registrations.

You should not need to do this at all. Clearing the cache should be enough for these views to get picked up.

> Features: For some reason when I attempt to export the view in features, I am able to check the view but it is not included in the features export. Not sure if this is related
You wouldn't be able to export a default view like this with Features - if you want to alter the default view, you should implement hook_views_default_view_alter. For example, we did this to add an additional field to the view:

/**
 * Implements hook_views_default_view_alter().
 */
function sac_event_reg_views_default_views_alter(&$views) {
  if (isset($views['registrations'])) {
    $handler =& $views['registrations']->display['default']->handler;

    /* Field: User: Member ID */
    $member_id_field = array();
    $member_id_field['field_phoenix_member_vid']['id'] = 'field_phoenix_member_vid';
    $member_id_field['field_phoenix_member_vid']['table'] = 'field_data_field_phoenix_member_vid';
    $member_id_field['field_phoenix_member_vid']['field'] = 'field_phoenix_member_vid';
    $member_id_field['field_phoenix_member_vid']['relationship'] = 'user_uid';
    drupal_array_insert($handler->display->display_options['fields'], 'name_1', $member_id_field);
  }
}

> Default View: Is it too much to ask to have the view already created but disabled ?
That is already the case - actually, the view is enabled by default.

> Also once you enable your own view the message stating how many slots available disappears. Any help to get that message back would be great.
there is no reason for that, and I suspect something else may be causing that to happen for you,

I don't have time to reroll the patch with this included. But attached patch adds a access handler specific to registration. using this in the view will allow you to hide the menu items/tabs using the sames access control that the non-views one does.

If someone has the time to test and implement it into the patch from #29, that would be great.

EDIT: It's based on my patch a little higher up, in case something doesn't make sense.

@mrfelton

Is it possible to construct the view similar to how Organic Groups does it ?

Basically the view is disabled by default and if you want to reuse the view you can clone it or you can just activate and change the configurations. With the cloned view everything is exportable with features.

from an end users perspective customizing what is visible for each registration display is pretty important and could change between the type of events.

applied #32 to #29 to dev (commit c47de239d535628f9ebf9afd73ee21c53e7b9891) so at this point you can apply the next patch to the latest dev release. note that the #32 patch from moonray didn't apply cleanly to modules/registration_views/registration_views.info (rejected):

root@ubuntu:/var/www/vhosts/drupal.local/contrib.drupal.org/modules/registration# patch -p1 < registration-views_access_plugin.patch
patching file docroot/sites/all/modules/registration/modules/registration_views/includes/registration_plugin_access_administer_registrations.inc
can't find file to patch at input line 156
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/docroot/sites/all/modules/registration/modules/registration_views/registration_views.info b/docroot/sites/all/modules/registration/modules/registration_views/registration_views.info
|index 04cb81d4105e3a0c7d5e077134575fe041443763..f556afbc887f4e5ef6e47cc5f8d8f79bd705bd8c 100644
|--- a/docroot/sites/all/modules/registration/modules/registration_views/registration_views.info
|+++ b/docroot/sites/all/modules/registration/modules/registration_views/registration_views.info
--------------------------
File to patch: modules/registration_views/registration_views.info
patching file modules/registration_views/registration_views.info
Hunk #1 FAILED at 17.
1 out of 1 hunk FAILED -- saving rejects to file modules/registration_views/registration_views.info.rej
can't find file to patch at input line 168
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/docroot/sites/all/modules/registration/modules/registration_views/registration_views.module b/docroot/sites/all/modules/registration/modules/registration_views/registration_views.module
|index c5921a2eabafa24be03191643bcad77cf5c70042..df5304a497482c33119eac004e7504f73dcb4297 100644
|--- a/docroot/sites/all/modules/registration/modules/registration_views/registration_views.module
|+++ b/docroot/sites/all/modules/registration/modules/registration_views/registration_views.module
--------------------------
File to patch: modules/registration_views/registration_views.module
patching file modules/registration_views/registration_views.module
can't find file to patch at input line 206
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/docroot/sites/all/modules/registration/registration.module b/docroot/sites/all/modules/registration/registration.module
|index dd7e678add0e407fb227215a1c630846019a5254..82ac7a60e43023101b1866c16f2f2b9f6921788e 100644
|--- a/docroot/sites/all/modules/registration/registration.module
|+++ b/docroot/sites/all/modules/registration/registration.module
--------------------------
File to patch: registration.module
patching file registration.module
Hunk #1 succeeded at 471 (offset -3 lines).
Hunk #2 succeeded at 480 (offset -3 lines).

don't apply that last patch #35.

patch includes mrfelton #32 patch, with an attempt at a correction for what was intended: assumed new file included as dependency in registration.info, registration_plugin_access_administer_registrations.inc

@mrfelton: if you create the contrib module patch at the module's root directory, that should help resolve the patch file path issues.

@jaypark. You should not be creating patches from your Drupal root. Please refer to http://drupal.org/node/707484 for details of how to correctly generate the patch (you should be using git diff from the module registration module root). That patch you have provided in #37 will not apply cleanly with git or with drush make.

The patch in #37 is missing the .default.views.inc. Updated patch includes the missing file, and fixes the patch format to conform to Drupal standards. Also, I have altered the validation on the contextual filter so that it only validates that the argument is numeric and does not validate that it's a valid Node ID since registrations can be attached to any Entity (Commerce Products in the case of Commerce Registrations). I also added some empty text to the view for when there are no registrants - as per the non-views list.

mrfelton, my mistake, thank you for the correction and the patch. meant to address #38 to moonray.

applied your patch #40, but with some resulting .rej. at first review, the only salient issue is that after enabling registrations view, "[capacity_used]" appears at node/%/registrations/list header, rather than the numeric value. prior to enabling the view the numeric value shows correctly.

@jaypark are you using the latest git code? The patch applies cleanly against latest code in git. Re the issue with "[capacity_used]", I noted this when I originally posted the patch. A view field handler doesn't exist for that yet, so that needs to be created first.

[capacity_used] in the header will be grabbed from the first record. If there are no records, [capacity_used] does not get replaced by a number. It's a small nuisance.

Updated patch makes proper use of the access plugin that was provided in #32.

patch #44 applies cleanly to

commit c47de239d535628f9ebf9afd73ee21c53e7b9891
Author: Tauno Hogue
Date: Tue Feb 26 07:55:08 2013 -0800

User entity_type for token tree instead of node

moonray, mrfelton - try enabling the Registrations view, visit node/%/registrations and see if "[capacity_used]" also shows for you. it does for me, with 1 anonymous user registered.

@jaypark - yes, [capacity_used] works fine if there are some registrations.

yes [capacity_used] works when the view is disabled- try enabling the view. then "[capacity_used]" shows instead of [capacity_used].

jaypark is correct ! for some reason once the view is "enabled" the token's no longer work as before.

Does patch #44 work correctly with the patch located here: #1949466: Add views filters for open date and close date ? After applying both, my Total Capacity field ended up showing as "missing field/handler" in views.

It would be even better if the functionality provided in that patch could be implemented into this one.

The patch in #44 works perfectly for me. Awesome work guys :) See comment below.

I am seeing the same error as NWOM. I have a separate view for listing my events and since installing the patch I am getting "Broken/missing handler" error for the Total Slots field. Here is my view setup screen:

I rolled back the patch and the error disappeared. Other fields that are in registration settings seem to be ok (e.g. close date).

I don't have the patch installed mentioned by NWOM (#1949466: Add views filters for open date and close date) so it seems like an issue with this patch.

+1 for this feature request
would be extremely useful

So can we get the patch from 44 committed ?

Then open another issue to get the token's working ?

In the meantime until the token is fixed, and rather than replacing the default view, I created my own view and then put it on the Manage Registrations page as an additional tab.

1. Create a view page with a path of /[entity]/%/registrations/[yourpath] - it should be a subset of the main registration path
2. Choose Menu: Tab, and add the tab (I called mine "Details") to the Navigation menu.

Drupal figures out where it needs to go. When you view your registration info, now you have an additional tab that extends the default registration and can show all the fields you wish!

Agreed with #53 - it would be great to have this committed and then open another issue for any problems with tokens.

#44 works great for me and is a huge time saver for getting up and running. Much thanks jaypark and mrfelton

Just applied #44... works great!

Thanks a lot guys, you're amazing!

It's a really usefull feature!

I just tried applying the patch in #44 but I got the following error:

patching file modules/registration_views/includes/registration_handler_field_entity_capacity_total.inc
patching file modules/registration_views/includes/registration_plugin_access_administer_registrations.inc
patching file modules/registration_views/includes/registration_views.views_default.inc
patching file modules/registration_views/registration_views.info
Hunk #1 FAILED at 18.
1 out of 1 hunk FAILED -- saving rejects to file modules/registration_views/registration_views.info.rej
patching file modules/registration_views/registration_views.module
patching file registration.module
Hunk #1 succeeded at 478 (offset 7 lines).
Hunk #2 succeeded at 487 (offset 7 lines).

I'm using version 7.x-1.3 and not the latest dev. Is that what is causing my problem?

Oh and this is what was in the registration_views.info.rej file;

--- modules/registration_views/registration_views.info
+++ modules/registration_views/registration_views.info
@@ -18,3 +18,4 @@
files[] = includes/registration_handler_field_entity_datetime.inc
files[] = includes/registration_handler_field_entity_settings_link.inc
files[] = includes/registration_handler_field_entity_registration_status.inc
+files[] = includes/registration_plugin_access_administer_registrations.inc

It should apply to 1.3. I believe that's what I applied it to.

That said, it's only the .info file you're having issues with, so you could probably apply that manually easily enough. All the patch is doing to that file is adding this line

files[] = includes/registration_plugin_access_administer_registrations.inc

Is there a reason that the patch in #44 isn't being committed ?

Hi,

I used the solution as described in #54 in combination with the TAB TAMER module to disable the default tabs of the registration module.

Thanks!

Is there another maintainer that would be willing to apply this patch?

It's been 2 years and it's frustrating to have to apply this patch for new projects.

I am having the same problem.

I wants to export the registrants list in csv format.
I am using view export module to export registrants list.
But as the registration fields not same for all node i can not add a fix number of field to export.
I want to export all the registration fields for a node.

Thank you

Seeming Views are part of Core in D8 it would be great for this feature to be implemented in the D8 port.

Given that many people are using this successfully and the one reported failure concerns only the .info can we move this to RTBC in hopes of getting it committed?

Re-rolled patch against latest 7.x-1.x branch. Also applies cleanly against release 7.x-1.3:

[root@server registration]# patch -p1 < registration_views_7.x-1.x_1473714-66.patch
patching file modules/registration_views/includes/registration_handler_field_entity_capacity_total.inc
patching file modules/registration_views/includes/registration_plugin_access_administer_registrations.inc
patching file modules/registration_views/includes/registration_views.views_default.inc
patching file modules/registration_views/registration_views.info
patching file modules/registration_views/registration_views.module
patching file registration.module

FYI, after applying the patch and flushing all caches, the view "Registrations" at "node/%/registrations" is immediately active. So no need to enable it. It is working great! Big thanks to the authors. Hope this gets committed some day.

Thanks for the Re-roll. Though the view was active, I had to correct a typo in the path under Page settings on the view: it was missing a / between "/node/%" and "registrations/list". After that, it works swimmingly.

Strange. The page path was /node/%/registrations/list immediately (correct) after applying the patch! If you look directly into the patch, you will find the line
+ $handler->display->display_options['path'] = 'node/%/registrations/list';
so there is really no slash missing.

The contextual filter " Registration: Host entity ID" does not seem to work for me.

In response to paul53181, and to anyone else who is looking for a solution to this issue and found that the view generated by the patch has a problem with the Host entity ID contextual filter:
This patch/view appears to only work with Entity Registration, and NOT with Commerce Registration.

After starting with a fresh D7 site, downloading all the appropriate modules, and applying the patch with success, I found that applying it to sites that were already up and running, it did not work. After a lot of confusion and code-searching, I found that this view will only work properly with nodes that have a registration field. I was trying to use this with product displays nodes which contain a product reference field which in turn contains the registration field.

The Host entity ID the patch/view is looking for is the NID of the node which contains the Registration field. With Commerce Registration, the Host entity ID would be the product NID, as that is where the Registration field lives, but for my situation, I want it to be the product display NID. Thus, I had to created a Commerce Product view with relationships to the Registrations associated with the products. I have attached a sample view:

$view = new view();
$view->name = 'registration_view';
$view->description = '';
$view->tag = 'default';
$view->base_table = 'commerce_product';
$view->human_name = 'Registrations';
$view->core = 7;
$view->api_version = '3.0';
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */

/* Display: Master */
$handler = $view->new_display('default', 'Master', 'default');
$handler->display->display_options['title'] = 'Registrations';
$handler->display->display_options['use_more_always'] = FALSE;
$handler->display->display_options['access']['type'] = 'perm';
$handler->display->display_options['access']['perm'] = 'administer registration';
$handler->display->display_options['cache']['type'] = 'none';
$handler->display->display_options['query']['type'] = 'views_query';
$handler->display->display_options['exposed_form']['type'] = 'basic';
$handler->display->display_options['pager']['type'] = 'none';
$handler->display->display_options['style_plugin'] = 'table';
$handler->display->display_options['style_options']['columns'] = array(
  'product_id' => 'product_id',
  'registration_id' => 'registration_id',
  'anon_mail' => 'anon_mail',
  'mail' => 'mail',
  'name' => 'name',
  'name_1' => 'name_1',
  'count' => 'count',
  'created' => 'created',
  'state' => 'state',
  'view_registration' => 'delete_registration',
  'edit_registration' => 'delete_registration',
  'delete_registration' => 'delete_registration',
);
$handler->display->display_options['style_options']['default'] = '-1';
$handler->display->display_options['style_options']['info'] = array(
  'product_id' => array(
    'sortable' => 0,
    'default_sort_order' => 'asc',
    'align' => '',
    'separator' => '',
    'empty_column' => 0,
  ),
  'registration_id' => array(
    'sortable' => 0,
    'default_sort_order' => 'asc',
    'align' => '',
    'separator' => '',
    'empty_column' => 0,
  ),
  'anon_mail' => array(
    'sortable' => 0,
    'default_sort_order' => 'asc',
    'align' => '',
    'separator' => '',
    'empty_column' => 0,
  ),
  'mail' => array(
    'sortable' => 0,
    'default_sort_order' => 'asc',
    'align' => '',
    'separator' => '',
    'empty_column' => 0,
  ),
  'name' => array(
    'sortable' => 0,
    'default_sort_order' => 'asc',
    'align' => '',
    'separator' => '',
    'empty_column' => 0,
  ),
  'name_1' => array(
    'sortable' => 0,
    'default_sort_order' => 'asc',
    'align' => '',
    'separator' => '',
    'empty_column' => 0,
  ),
  'count' => array(
    'sortable' => 0,
    'default_sort_order' => 'asc',
    'align' => '',
    'separator' => '',
    'empty_column' => 0,
  ),
  'created' => array(
    'sortable' => 0,
    'default_sort_order' => 'asc',
    'align' => '',
    'separator' => '',
    'empty_column' => 0,
  ),
  'state' => array(
    'sortable' => 0,
    'default_sort_order' => 'asc',
    'align' => '',
    'separator' => '',
    'empty_column' => 0,
  ),
  'view_registration' => array(
    'align' => '',
    'separator' => '',
    'empty_column' => 0,
  ),
  'edit_registration' => array(
    'align' => '',
    'separator' => '',
    'empty_column' => 0,
  ),
  'delete_registration' => array(
    'align' => '',
    'separator' => '',
    'empty_column' => 0,
  ),
);
/* Header: Global: Text area */
$handler->display->display_options['header']['area']['id'] = 'area';
$handler->display->display_options['header']['area']['table'] = 'views';
$handler->display->display_options['header']['area']['field'] = 'area';
$handler->display->display_options['header']['area']['empty'] = TRUE;
$handler->display->display_options['header']['area']['content'] = 'List of registrations for <em>%1</em>. <strong>[count]</strong> are filled.';
$handler->display->display_options['header']['area']['format'] = 'filtered_html';
$handler->display->display_options['header']['area']['tokenize'] = TRUE;
/* No results behavior: Global: Unfiltered text */
$handler->display->display_options['empty']['area_text_custom']['id'] = 'area_text_custom';
$handler->display->display_options['empty']['area_text_custom']['table'] = 'views';
$handler->display->display_options['empty']['area_text_custom']['field'] = 'area_text_custom';
$handler->display->display_options['empty']['area_text_custom']['label'] = 'Empty text';
$handler->display->display_options['empty']['area_text_custom']['empty'] = TRUE;
$handler->display->display_options['empty']['area_text_custom']['content'] = 'There are no registrants.';
/* Relationship: Registration: Commerce Product to Registration */
$handler->display->display_options['relationships']['registration_rel']['id'] = 'registration_rel';
$handler->display->display_options['relationships']['registration_rel']['table'] = 'commerce_product';
$handler->display->display_options['relationships']['registration_rel']['field'] = 'registration_rel';
$handler->display->display_options['relationships']['registration_rel']['label'] = 'Registration';
/* Relationship: Commerce Product: Referencing Node */
$handler->display->display_options['relationships']['field_product']['id'] = 'field_product';
$handler->display->display_options['relationships']['field_product']['table'] = 'commerce_product';
$handler->display->display_options['relationships']['field_product']['field'] = 'field_product';
$handler->display->display_options['relationships']['field_product']['label'] = 'Node';
/* Relationship: Registration: Author entity author_uid */
$handler->display->display_options['relationships']['author']['id'] = 'author';
$handler->display->display_options['relationships']['author']['table'] = 'registration';
$handler->display->display_options['relationships']['author']['field'] = 'author';
$handler->display->display_options['relationships']['author']['relationship'] = 'registration_rel';
$handler->display->display_options['relationships']['author']['label'] = 'Created By';
/* Relationship: Registration: User */
$handler->display->display_options['relationships']['user_uid']['id'] = 'user_uid';
$handler->display->display_options['relationships']['user_uid']['table'] = 'registration';
$handler->display->display_options['relationships']['user_uid']['field'] = 'user_uid';
$handler->display->display_options['relationships']['user_uid']['relationship'] = 'registration_rel';
/* Field: Commerce Product: Product ID */
$handler->display->display_options['fields']['product_id']['id'] = 'product_id';
$handler->display->display_options['fields']['product_id']['table'] = 'commerce_product';
$handler->display->display_options['fields']['product_id']['field'] = 'product_id';
$handler->display->display_options['fields']['product_id']['exclude'] = TRUE;
$handler->display->display_options['fields']['product_id']['link_to_product'] = 0;
/* Field: Registration: Registration ID */
$handler->display->display_options['fields']['registration_id']['id'] = 'registration_id';
$handler->display->display_options['fields']['registration_id']['table'] = 'registration';
$handler->display->display_options['fields']['registration_id']['field'] = 'registration_id';
$handler->display->display_options['fields']['registration_id']['relationship'] = 'registration_rel';
$handler->display->display_options['fields']['registration_id']['label'] = 'ID';
/* Field: Registration: Anonymous e-mail */
$handler->display->display_options['fields']['anon_mail']['id'] = 'anon_mail';
$handler->display->display_options['fields']['anon_mail']['table'] = 'registration';
$handler->display->display_options['fields']['anon_mail']['field'] = 'anon_mail';
$handler->display->display_options['fields']['anon_mail']['relationship'] = 'registration_rel';
$handler->display->display_options['fields']['anon_mail']['label'] = '';
$handler->display->display_options['fields']['anon_mail']['exclude'] = TRUE;
$handler->display->display_options['fields']['anon_mail']['element_label_colon'] = FALSE;
/* Field: User: E-mail */
$handler->display->display_options['fields']['mail']['id'] = 'mail';
$handler->display->display_options['fields']['mail']['table'] = 'users';
$handler->display->display_options['fields']['mail']['field'] = 'mail';
$handler->display->display_options['fields']['mail']['relationship'] = 'user_uid';
$handler->display->display_options['fields']['mail']['alter']['alter_text'] = TRUE;
$handler->display->display_options['fields']['mail']['alter']['text'] = '[anon_mail][mail]';
/* Field: User: Name */
$handler->display->display_options['fields']['name']['id'] = 'name';
$handler->display->display_options['fields']['name']['table'] = 'users';
$handler->display->display_options['fields']['name']['field'] = 'name';
$handler->display->display_options['fields']['name']['relationship'] = 'user_uid';
$handler->display->display_options['fields']['name']['label'] = 'User';
/* Field: User: Name */
$handler->display->display_options['fields']['name_1']['id'] = 'name_1';
$handler->display->display_options['fields']['name_1']['table'] = 'users';
$handler->display->display_options['fields']['name_1']['field'] = 'name';
$handler->display->display_options['fields']['name_1']['relationship'] = 'author';
$handler->display->display_options['fields']['name_1']['label'] = 'Created By';
/* Field: Registration: Slots consumed */
$handler->display->display_options['fields']['count']['id'] = 'count';
$handler->display->display_options['fields']['count']['table'] = 'registration';
$handler->display->display_options['fields']['count']['field'] = 'count';
$handler->display->display_options['fields']['count']['relationship'] = 'registration_rel';
$handler->display->display_options['fields']['count']['label'] = 'Count';
$handler->display->display_options['fields']['count']['exclude'] = TRUE;
/* Field: Registration: Date created */
$handler->display->display_options['fields']['created']['id'] = 'created';
$handler->display->display_options['fields']['created']['table'] = 'registration';
$handler->display->display_options['fields']['created']['field'] = 'created';
$handler->display->display_options['fields']['created']['relationship'] = 'registration_rel';
$handler->display->display_options['fields']['created']['label'] = 'Created';
$handler->display->display_options['fields']['created']['date_format'] = 'medium';
$handler->display->display_options['fields']['created']['second_date_format'] = 'long';
/* Field: Registration: State entity */
$handler->display->display_options['fields']['state']['id'] = 'state';
$handler->display->display_options['fields']['state']['table'] = 'registration';
$handler->display->display_options['fields']['state']['field'] = 'state';
$handler->display->display_options['fields']['state']['relationship'] = 'registration_rel';
$handler->display->display_options['fields']['state']['label'] = 'State';
/* Field: Registration: View link */
$handler->display->display_options['fields']['view_registration']['id'] = 'view_registration';
$handler->display->display_options['fields']['view_registration']['table'] = 'registration';
$handler->display->display_options['fields']['view_registration']['field'] = 'view_registration';
$handler->display->display_options['fields']['view_registration']['relationship'] = 'registration_rel';
$handler->display->display_options['fields']['view_registration']['exclude'] = TRUE;
$handler->display->display_options['fields']['view_registration']['alter']['text'] = '[view_registration] | ';
/* Field: Registration: Edit link */
$handler->display->display_options['fields']['edit_registration']['id'] = 'edit_registration';
$handler->display->display_options['fields']['edit_registration']['table'] = 'registration';
$handler->display->display_options['fields']['edit_registration']['field'] = 'edit_registration';
$handler->display->display_options['fields']['edit_registration']['relationship'] = 'registration_rel';
$handler->display->display_options['fields']['edit_registration']['exclude'] = TRUE;
/* Field: Registration: Delete link */
$handler->display->display_options['fields']['delete_registration']['id'] = 'delete_registration';
$handler->display->display_options['fields']['delete_registration']['table'] = 'registration';
$handler->display->display_options['fields']['delete_registration']['field'] = 'delete_registration';
$handler->display->display_options['fields']['delete_registration']['relationship'] = 'registration_rel';
$handler->display->display_options['fields']['delete_registration']['exclude'] = TRUE;
$handler->display->display_options['fields']['delete_registration']['alter']['text'] = '[view_registration] | [edit_registration] | [delete_registration]';
/* Field: Registration: Delete link */
$handler->display->display_options['fields']['delete_registration_1']['id'] = 'delete_registration_1';
$handler->display->display_options['fields']['delete_registration_1']['table'] = 'registration';
$handler->display->display_options['fields']['delete_registration_1']['field'] = 'delete_registration';
$handler->display->display_options['fields']['delete_registration_1']['relationship'] = 'registration_rel';
$handler->display->display_options['fields']['delete_registration_1']['label'] = 'Actions';
$handler->display->display_options['fields']['delete_registration_1']['alter']['alter_text'] = TRUE;
$handler->display->display_options['fields']['delete_registration_1']['alter']['text'] = '[view_registration] | [edit_registration] | [delete_registration]';
/* Contextual filter: Content: Nid */
$handler->display->display_options['arguments']['nid']['id'] = 'nid';
$handler->display->display_options['arguments']['nid']['table'] = 'node';
$handler->display->display_options['arguments']['nid']['field'] = 'nid';
$handler->display->display_options['arguments']['nid']['relationship'] = 'field_product';
$handler->display->display_options['arguments']['nid']['default_action'] = 'not found';
$handler->display->display_options['arguments']['nid']['title_enable'] = TRUE;
$handler->display->display_options['arguments']['nid']['title'] = '%1';
$handler->display->display_options['arguments']['nid']['default_argument_type'] = 'node';
$handler->display->display_options['arguments']['nid']['summary']['number_of_records'] = '0';
$handler->display->display_options['arguments']['nid']['summary']['format'] = 'default_summary';
$handler->display->display_options['arguments']['nid']['summary_options']['items_per_page'] = '25';

/* Display: Page */
$handler = $view->new_display('page', 'Page', 'page');
$handler->display->display_options['path'] = 'node/%/registrations/list';
$handler->display->display_options['menu']['type'] = 'default tab';
$handler->display->display_options['menu']['title'] = 'Registrations';
$handler->display->display_options['menu']['weight'] = '0';
$handler->display->display_options['menu']['context'] = 0;
$handler->display->display_options['menu']['context_only_inline'] = 0;
$handler->display->display_options['tab_options']['type'] = 'tab';
$handler->display->display_options['tab_options']['title'] = 'Manage Registrations';
$handler->display->display_options['tab_options']['weight'] = '0';

This view will override the default Registration view, just like the patch does, but it instead uses the Product Display NID for its contextual filter. You can now do any views related manipulation you require. I hope this helps someone avoid aggravation.

@blackey5000 could your role this into a patch?

the count function in this doesn't seem to work - i always see "1" reserved - tested with aggregation settings but ended up using the group counter in the header field and exposing a filter on the registration state to select by state... need to get the "xx registrations out of yy spaces" part working now - the xx works from the result counter, but I don't know where to find the yy spaces available in the view

no longer applies cleanly to march 31 registration dev.

Yes, the patch from #66 no longer applies to release 7.x-1.4. It needs to be re-rolled.

Or, you can install Entity Registration 7.x-1.3, apply the patch, and upgrade to 7.x-1.4.

Well, I've tried both methods and am having trouble getting either to work. So, I come to you guys to help me figure out the silly thing I'm doing wrong.

I'm on Drupal 7, with both Entity Registration and Commerce Registration. The site itself works great! Good combination of systems. But as others listed above, I need to edit the Manage Registrations tab. I'd love to have it be a view and then I could head out.

So, here's what I've done. First, I used the view in #72 as it looked like a faster solution. It altered the Manage Registrations tab and made it a view! Sweet! But none of the registrations were shown. This was for both registrations using normal entity registration and registrations using commerce registration (I've got both on the site). I figure it's a contextual filter issue, but I can't figure it out. If I remove the contextual filter, all the Commerce Registrations for the entire site show up...so that's a plus but not really helpful.

Next, I wiped all that out with a backup/restore and tried to patch the module with the patch from #66. Never done that large of a patch before and had to set up NetBeans. Took a while, but got it configured and seemed to be working. When I applied the patch to Entity Registration 1.3, I got a message that it was partially patched. But I can't find any errors. So, I uploaded the patched version, cleared the caches, and went to the Manage Registrations tab....but it's not a view. 8-( Plus, I saw no errors in the error log.

So, I'm not sure which pathway to keep banging my head over. Any advice from you Drupal Ninjas?

Thanks!

Any chance any of you Ninjas could re-roll the patch for me? I can't get the older patch to apply, even using version 1.3 as suggested. Thanks!!!!

Can anyone explain how to get this patch to work in release 7.x- 1.4?
#76 confuse me a bit?
Question #76 - If upgrade from an earlier version, does it means that the "patch parts" from earlier versions "is following" up to the later versions - so "the patched small pieces" it is still there???
Else - how to make it as #76 means?

After study the code in the patch, it seams to be the last part of patch (for registration.module) who already has been change and are included in the code in Entity Registration version 1.4.
- Attached is the parts from earlier patch for version 1.3, - who will apply on 1.4, without any error.
!!!!- please try it on a copy of page before use it (examined on own responsibility) - and report HERE if there is any miss match OR if it work's fine (there is no author info inside the patch - ).
I did did try it with good result - but that's not good enough to be completely sure... I think

It's true that some of the changes added by #66 where added and not necessary, but not everything that the re-roll on #81 did, which is missing some important bits.

Attached is a re-roll from #66 with what's necessary and a bit of a cleanup of not needed hunks.

The latest patch is working pretty well. I found two problems:

• My site uses all custom text formats instead of the defaults. The header did not display until I went into the views config and changed the text format to one that exists on my site.
• The slots used count is still incorrect.

Here is an updated patch that adds a relationship to the host entity in order to get at the registration status and the total capacity used.

It doesn't look like the module provides a way to get at the total capacity available. That's going to be necessary to make this view as useful as it can be. I'll see if I can get that added in.

@cboyden it will definitely help if we start adding interdiff patches as well, so we can follow up changes, do you know how to make one and/or want to do it?

Right! Here's an interdiff between the patches in 82 and 84.

I have another updated patch and interdiff which adds a field handler for the capacity. The handler file in registration_views was there, but the code in it was an exact duplicate of the code for the access control plugin. I guess both of the files were loading without issue? But since the 2nd one called in the .info was the mis-named one, that caused me some issues when I changed the field handler file to actually be a field handler.

So if you apply this interdiff, you will need to rebuild your registry, otherwise the access control will disappear from the view. drush rr --fire-bazooka worked for me.

@cboyden nice rework, from my tests seems to be working fine, and finally with views_data_export a nice CSV out of it, do you think there's still work on it?

One thing I am noticing is that if the registration host entity has no registrations, the header displays like this:

[capacity_used] total slots out of [capacity_total] used for asdf. Registration is [registration_status].
There are no registrants.

Tokens are not replaced

Maybe worth setting the header to not be shown if no results are there.

I haven't tested the code, but here's some quick code review:

1. +++ b/modules/registration_views/includes/registration_plugin_access_administer_registrations.inc
   @@ -0,0 +1,145 @@
   +/**
   + * @file
   + * Definition of views_plugin_access_perm.
   + */
   +
   +/**
   + * Access plugin that provides permission-based access control.
   + *
   

   These comments need to be updated! They reflect the original handler that was copied and modified.

2. +++ b/modules/registration_views/includes/registration_plugin_access_administer_registrations.inc
   @@ -0,0 +1,145 @@
   +    if (FALSE && !$form_state['values']['entity_type']) {
   +      form_error($form['entity_type'], t('You must enter a valid entity type.'));
   +    }
   

   FALSE && makes this code a no-op. Maybe instead it should be removed or commented out? It easy to thing this code is doing something when reading the code quickly.

3. +++ b/modules/registration_views/registration_views.module
   @@ -16,6 +16,25 @@ function registration_views_views_api() {
   +        'help topic' => 'access-administer-registrations',
   

   I doubt there is really such a help topic! At least it's not being added in this patch. :-)

I just tested the patch, and for the most part it works great!

However, I was able to reproduce the issue that @hanoii found:

One thing I am noticing is that if the registration host entity has no registrations, the header displays like this:

[capacity_used] total slots out of [capacity_total] used for asdf. Registration is [registration_status].
There are no registrants.

Tokens are not replaced

Except for me, it wasn't necessary to actually disable registrations. If registration were enabled but there were no registrations yet, then I see it without the tokens expanded. This seems important to fix!

@dsnopek my same use case exactly, maybe It come out wrong, but it is with a registration and no registrations yet.

The tokens comes from the views result so probably not an easy fix. I think the best compromise is to just set the views header not to be displayed if no result sets are there.

OK, I've made the recommended changes in this patch:

• Set header to not display if there is no registration data
• Removed reference to missing help topic
• Updated comments in access plugin

On the last point, I could use a review of those comments.

I couldn't apply the patch in #94 (Hunk #1 FAILED at 508) to the 7.x-1.3+2-dev.

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 25545 100 25545 0 0 82229 0 --:--:-- --:--:-- --:--:-- 160k
patching file modules/registration_views/includes/registration_handler_field_entity_capacity_total.inc
patching file modules/registration_views/includes/registration_handler_field_entity_capacity_used.inc
patching file modules/registration_views/includes/registration_plugin_access_administer_registrations.inc
patching file modules/registration_views/includes/registration_views.views_default.inc
patching file modules/registration_views/registration_views.info
patching file modules/registration_views/registration_views.module
patching file registration.module
Hunk #1 FAILED at 508.
1 out of 1 hunk FAILED -- saving rejects to file registration.module.rej

@rwilson0429 patthces should always be applied against the latest dev.

The patch in #94 applies cleanly and works beautifully.

Thanks, hanoii, you are so correct. I thought that I had updated to the latest dev. Upon further review, I wasn't using the latest dev. Taking your advice to use the latest dev, I updated to the latest dev and the patch in #94 applied cleanly. Thank you.

This View is a significant improvement in the management of registrations. The manage registration functionality that this module initially implements does not allow enough flexibility for many use cases. This view overcomes this deficit and improves the usability of the registration module. Thanks.

The view is absolutely needed! Without it, the module is not really useful. However, chances to get the patch committed are low unless the issue status is RTBTC.

I applied the patch in #94 just fine but when i go to look at my list of registrants I get "There are no registrants." If I disable the view from the patch and go back to the original the list of registrants shows up fine.

I think it has something to do with the view filter, if I preview the view and enter the HID. I just don't know enough about views to figure out what could be wrong.

#94 applied cleanly for me, but can anyone provide a summary of the changes in this version to make review easier? Thanks for a lot of hard work -- we'd love to make the view more useful if possible.

Will this be commited? Would be nice.

Thx.

FYI: if you're using registration commerce, this view will not work for you.

OH! That must be why I've been banging my head trying to get this to work. Anyone know how to make the view work WITH Registration Commerce????? I'd be eternally grateful!

@WattDesigns you can use the same view, but you have to change the relationship.
Users are registered against commerce_products, not nodes, when using commerce registration.

Ah, that would explain why I got the view to show, but it was empty. I'll give that a try. Thanks!!!!

108 comments and no commit?

This is why someone has created a different registration module for D8.

#94 is working fine for me. Please commit, this functionality is needed.

#94 works for me too.

If the patch is working for all of you, feel free to mark it RTBC. (I can't, I posted the patch.)

cboyden, thanks a lot for your work!

Default settings for this view is to allow all logged in users to see it. Is this expected behaviour for others? I expected the list of registered persons to be private.

Is there any easy way to change this to only be viewable for persons who have access to edit registration settings for the current node (as opposed to the current setting of anyone with a certain global permission or anyone that is logged in)?

@Rustan, access to the view's path /node/%/registrations/list is controlled by the module's built-in permissions. You can only see the list if you can administer registrations of that type, or if you can both update your own registration and edit the entity it's attached to. So the built-in permissions take into account the specific node. I've tested the path with an unprivileged user and saw the Access Denied page as expected.

@cboyden thanks, sorry for my mistake. Yes, works as expected. If user cannot edit the node then the view is not accessible either.

I've got all permissions mentioned in #115 but my registration tab has disappeared.
I'm using registration_views 7.x-1.6. Do I need to use the dev version?

I am getting the following error:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'registration_node.user_uid' in 'on clause'

when I add the following relationship:
(node being the Registration) Registration: User

Hi this is very nice and worked, however I want some information to be available to ALL users (also anonymous) on the page of Events.
How can I do that? I thought people in here can tell me where the right spot in the code is to do that.

Like if I want following information on the main view of an event:
9 total slots out of 24 used for Modern Weekly - MaRo Games Basel. Registration is Open.

other thing: is it somehow possible to let everybody VIEW a new tab with registrations with another view where i show only number and lets say usernames

great stuff - just what I needed thanks!

#94 works, but i get an error:

Notice: Undefined index: entity type in views_handler_field_entity->init() (line 44 of /Users/nicjasno/Sites/linuksi.com/sites/all/modules/views/handlers/views_handler_field_entity.inc).

Does anybody know this patch can be successfully applied now on top of 7.x-1.6 ? Or must be applied on top of 7.x-2.0-beta1 ? Or not at all, because is outdated?
I have applied it now on 7.x-1.6 and it crushed my site. The update was made manually and it is very possible I have done something wrong. So, any ideas? Thank you.

Patch still applies. No errors here.

If you need a Drupal 8 solution the Webform module has a demo events registration sub-module. I currently have a website using it for 40 different events and all of the features from Registration Module have been added. Including the ability to customize a view with your submissions.

@kclarkson that's good to know! Do you have a link to the module?

Edit: I think you mean it's bundled with the main Webform module rather than a separate contrib module?

@littledynamo,

haha yeah. I guess that is tomahhto tomaaaato :)

Using Views Data Export, I tried to add a button to the view to download the table as CSV. This does work for users having the administrator role. However for normal users who are author of the node and may administer registrations of this node the button is not shown. The direct link to the CSV is however accessible.

This may be related: #2728609: Export buttons: OG permissions are ignored

Hi - is this patch still needed in the ? :
Development version: 7.x-1.x-dev updated 14 Feb 2019 at 00:03 UTC

I ask because the Readme promises :

### [Views](http://drupal.org/project/views)

Not happy with the default tabular list of registrations? No problem,
registrations and their fields are all Views friendly. You can override the
default event registrations list, create additional ones, etc.

Thanks for any guidance.

I guess so. The Readme was last changed five years ago.