Permission for viewing newsletters statistics

Yeah a seperate permission is a good idea.
Though you should put the new permission in the existing array.
like this:

  $items['admin/content/simplenews/statistics/%'] = array(
     'title' => 'Statistics Details',
     'type' => MENU_NORMAL_ITEM,
     'page callback' => 'drupal_get_form',
     'page arguments' => array('simplenews_statistics_admin_opens', 4),
     'access arguments' => array('administer newsletters', 'view all newsletters statistics'),
   );

Ill commit to HEAD this week

Regarding granular control over stats and newsletter info...

What I did, is build a view for "Sent Issues", since that function of simplenews also suffers from the same, all or nothing paradigm.

I then built a custom TPL off of the view, to add on the clicks/opens. Doesn't give all data/info, but this actually allows me to limit newsletter admins so they only see click traffic to their sent issues. It doesn't even allow them to see other newsletter submissions from other admins who can send to the same newsletter.

In my case that doesn't really matter, since for the most part it will be a 1 user to 1 newsletter, or 1 to few newsletter ratio. Not a many users to 1 newsletter ratio.

The other added benefit is I limit the admins to only see their sent issues. So it kind of kills 2 birds with 1 stone.

This may be a huge kludge, but it works. If the module maintainer has any suggestions or ways to make this more future proof or secure please advise away. I am all ears.

Here's the gist of what a did.
- Installed views as well as simplenews and simplnews statistics
- build a page view for Newsletter nodes, that are authored/owned by the currently logged in user.

My filters section looks like this:
Filters
User: Current Yes
Simplenews: Sent status = Sent
Node: Type = Newsletter issue

My fields section looks like this:
Fields
Node: Nid Nid
Node: Title Title
Taxonomy: All terms Newsletter
Node: Post date Post date
Simplenews: Sent status Sent
Node: Edit link Edit

(nid is hidden, when we output the view)

As much as I hate tables, I made the view style a table. I really want this system to have an easy upgrade path, so I stuck with the default garlin theme for now as well. This is a backend utility for me, doesn't have much curb appeal as they say I guess.

In the Theme section, under style output, create a views-view-table--NAME-OF-VIEW.tpl.php in the directory for the module, copy what it says the output should look like for that view template, and then rescan template files.

The code in that view for me looks like this:

<?php
// $Id: views-view-table.tpl.php,v 1.8 2009/01/28 00:43:43 merlinofchaos Exp $
/**
 * @file views-view-table.tpl.php
 * Template to display a view as a table.
 *
 * - $title : The title of this group of rows.  May be empty.
 * - $header: An array of header labels keyed by field id.
 * - $fields: An array of CSS IDs to use for each field id.
 * - $class: A class or classes to apply to the table, based on settings.
 * - $row_classes: An array of classes to apply to each row, indexed by row
 *   number. This matches the index in $rows.
 * - $rows: An array of row items. Each row is an array of content.
 *   $rows are keyed by row number, fields within rows are keyed by field ID.
 * @ingroup views_templates
 */
?>
<table class="<?php print $class; ?>">
  <?php if (!empty($title)) : ?>
    <caption><?php print $title; ?></caption>
  <?php endif; ?>
  <thead>
    <tr>
      <?php foreach ($header as $field => $label):  if ($field != 'nid') {?>
        <th class="views-field views-field-<?php print $fields[$field]; ?>">
          <?php print $label; ?>
        </th>
      <?php } endforeach; ?>
      <th>Opens</th>
      <th>Clicks</th>
    </tr>
  </thead>
  <tbody>
    <?php foreach ($rows as $count => $row): ?>
      <tr class="<?php print implode(' ', $row_classes[$count]); ?>">
        <?php foreach ($row as $field => $content): 
        if ($field != 'nid') {?>
          <td class="views-field views-field-<?php print $fields[$field]; ?>">
            <?php print $content; ?>
          </td>
        <?php }
        endforeach;                   
		  $sql = "SELECT * FROM {simplenews_statistics_opens} WHERE nid = ".$row[nid];
		  $result = pager_query($sql, 50, 0, NULL, $nid);
		  $rows = array();
		  while ($view = db_fetch_object($result)) {
		    $rows[] = array(check_plain($view->url),
		                    check_plain($view->email),
		                    format_date($view->timestamp, 'small'));
		  }
		  if (!$rows) {
		    print "<td>0</td>";
		  } else {
   			print "<td>".count($rows)."</td>";
		  }      
   $sql = "SELECT * FROM {simplenews_statistics_clicks} WHERE nid = ".$row[nid];
		  $result = pager_query($sql, 50, 0, NULL, $nid);
		  $rows = array();
		  while ($view = db_fetch_object($result)) {
		    $rows[] = array(check_plain($view->url),
		                    check_plain($view->email),
		                    format_date($view->timestamp, 'small'));
		  }
		  if (!$rows) {
		    print "<td>0</td>";
		  } else {
   			print "<td>".count($rows)."</td>";
		  }
        ?>
        
      </tr>
    <?php endforeach; ?>
  </tbody>
</table>

Sorry for the long post, wish the code output had a scrolling div on drupal.org, but it doesn't. The code is basically stolen from the simplenews module. Rather than modify the module itself, I just built this view with a custom template.

Hopefully this helps out someone until simplenews and/or simplenews stats gets more granular control over access.

Now this doesn't have the same full featured data as stats, but for the most part I just want the admins to be able to see how many people are actually looking at the messages. I might build a custom php snippet, that gives them the ability to see who opened at the least. For right now, even the opens and clicks are more data than they are getting at the moment.

This patch is broken.

'access arguments' => array('administer newsletters', 'view all newsletters statistics')

will make drupal call the function

user_access('administer newsletters', 'view all newsletters statistics');

However, the user_access function takes three arguments : the permission, an optional user account, and an optional reset flag. In this case, drupal will try to use 'view all newsletters statistics as an user object. This will generate a warning and the function will always return FALSE. It makes statistics page hidden for all users (user #1 included). I will work on a functional patch soon.

Here is a new patch.

Bumping this to 3.x. No features are being added to 2.x release anymore. Granular permissions are a great idea and I will be looking at this patch!

Permissions have been comitted. There are 2 permissions available: "View all newsletter statistics" and "View own newsletter statistics".

Sorry, had to change this back to 1 permission. It was giving ma painfull headaches to get a secure Views integration...