Hi,
I wrote a plugin that grants access by users domain id. It only has the option to Negate the rule. It's very usefull in panels as selection rule. Does this module the same? According to the snapshot you have a select list of domains. If any interest, I will send it to you, but I will never touch cvs, sorry.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Ghostthinker’s picture

mymodule/plugins/access/domain.inc

// $Id$


/**
 * @file
 * Plugin to provide access control based upon domain membership.
 */

/**
 * Implementation of specially named hook_ctools_access().
 */
function mymodule_domain_ctools_access() {
  $args ['domain'] = array(
      'title' => t("User: domain editor"), 
      'description' => t('Control access by user domain.'), 
      'callback' => 'mymodule_domain_ctools_access_check', 
      'default' => array(
          'negate' => false 
      ), 
      'settings form' => 'mymodule_domain_ctools_access_settings', 
      'settings form submit' => 'mymodule_domain_ctools_access_settings_submit', 
      'summary' => 'mymodule_domain_ctools_acesss_summary', 
      'required context' => new ctools_context_required(t('User'), 'user') 
  );
  
  return $args;
}

/**
 * Settings form for the 'domain editor' access plugin
 */
function mymodule_domain_ctools_access_settings(&$form, &$form_state, $conf) {
  $form ['settings'] ['negate'] = array(
      '#type' => 'checkbox', 
      '#title' => t('Negate'), 
      '#default_value' => $conf ['negate'], 
      
      '#description' => t('User is domain editor of current domain') 
  );
}

/**
 * Compress the roles allowed to the minimum.
 */
function mymodule_domain_ctools_access_settings_submit(&$form, &$form_state) {
  $form_state ['values'] ['settings'] ['negate'] = $form_state ['values'] ['settings'] ['negate'];
}

/**
 * Check for access.
 */
function mymodule_domain_ctools_access_check($conf, $context) {
  // As far as I know there should always be a context at this point, but this
  // is safe.
  if (empty($context) || empty($context->data) || ! isset($context->data->roles)) {
    return FALSE;
  }
  $user = $context->data;
  
  //always access for uid 1
  if ($user->uid == 1) return TRUE;
  
  global $_domain;
  
  // user is assigned to current domain
  if (in_array($_domain ['domain_id'], $user->domain_user)) {
    return ! $conf ['negate'];
  }
  return $conf ['negate'];

}

/**
 * Provide a summary description
 */
function mymodule_domain_ctools_acesss_summary($conf, $context) {
 
  return t("Only users who are %not domain editors.", array('%not' => $conf['negate']?"not":""));
}

agentrickard’s picture

Category: task » feature

The current access filter is universal, not per-user.

http://drupal.org/patch/create

Please patch against HEAD.

Ghostthinker’s picture

I made a patch. It (should) simply add a new file plugins/access/domain_editor.inc

At the moment I am using my own module (that does the same than domain_ctools plus the ability to control access per user) but I would drop it if this goes into yours.

agentrickard’s picture

Status: Active » Needs review

Nice. Hopefully I can review and add this in.

hefox’s picture

Testing patch at the moment.

Initial thoughts: small detail, but in general patches are done via the root of the module, not the directory the file is in.

The views access plugin has these joined together, what are the reasons for having them separate in ctools, other than the added complexity? Perhaps domain_ctools and.. domain_views? could share some functions on checking access so to avoid duplication.

To the patch itself, eyeballing the patch looks good other than some random spacing, brief testing looks good :)

hefox’s picture

Status: Needs review » Needs work

Hm looking at the domain_views and domain_ctools, and looking at my own use case my preference would be

Create/move two functions into the main domain module for easy reusability:

  1. An access check function (rename of domain_views_access)
  2. A form generation form. Currently the forms contain slightly different settings for the two, but the keys for the shared setting (domain) are the same. domain_site is in the ctools, while the editor and strict settings are in views, so I guess merge the four fields togeaher into a form builder function.

(My use case is a custom field permission module that checks if the user and node is part of the current domain before letting em view certain fields, so I could use the first function using node's domains and member = true.)

hefox’s picture

Title: Access Plugin: "User: Domain editor" » Clean up access checks for external modules (domain views, ctools)
Project: Domain CTools » Domain
Status: Needs work » Needs review
FileSize
2.68 KB
11.55 KB

Throwing it to domain; throw it back here if prefer the earleir approach.

Patch 1 for domain/domain views puts 2 functions into domain module, and has the views access plugin use them; the second is for domain ctools.

agentrickard’s picture

Version: 6.x-1.0 » 7.x-2.x-dev

I think it's too late to clean this up for D6, and these modules are stand-alone in D7.

agentrickard’s picture

Version: 7.x-2.x-dev » 7.x-3.x-dev

Moving versions.

agentrickard’s picture

Status: Needs review » Needs work

This is totally out of date and I have forgotten the original use-case.