I've created a custom rule_set that fetches an email address from a field in a custom content. I've given the role "editor" permission to use VBO and that specific action.

As admin, when I go to my VBO view, I see the button/dropdown list with the action listed. I can execute the action properly.
When I log in as my editor, the button is gone/dropdown list empty.

In desperation, I've given my editor all permission possible, but still no go.

I've flushed the cache, rebuilt permission... nothing helps.

Thanks for helping! I need it!

CommentFileSizeAuthor
#8 guild_tasks.tar_.gz5.87 KBlarowlan

Comments

infojunkie’s picture

* Does this happen with other actions too?
* Is actions_permissions.module enabled?

odegard’s picture

Thanks for replying!

* If I enable the other actions available in the VBO view, they show up fine for editor. It's just the ones I created.
* Actions_permissions is enabled and configured.

It's so weird, that 1) the actions work for admin, so there's nothing wrong with the rule, and 2) they show up in the permission table along with all the others, but still they don't show up in the view.

Perhaps there's a bug when VBO checks for permissions when it *renders* the form? I gave editor all permissions available, but that didn't work.

lewie6’s picture

i have the exact same problem.

any suggestions?

odegard’s picture

I ended up making my own module based on one of the existing rules. I have 3 content types and an additional problem was showing and sorting three cts in one view. The module below fetches emails from one ct at a time.

Here it is, hope it is of help:

(hent epost = fetch emailaddresses)

hent_epost.info

; $Id$
name = Hent Epost
description = Henter epostadresser i opplistingsbilder
core = 6.x

package = "Other"

version = "6.x-0.1-dev"

hent_epost.module

<?php

/**
 * Implementation of hook_node_operations().
 */
function hent_epost_node_operations() {
  $operations = array('hent_epost' => array(
    'label' => t('Fetch email addresses'),
    'callback' => 'hent_epost_msg',
    ));
  return $operations;
/*
  return array(
    'export' => array(
      'label' => t('Fetch email addresses'),
      'callback' => 'hent_epost_msg',
    ),
  );
*/
}

/**
 * Returns emailaddresses
 */
function hent_epost_msg($node) {
	$personer = array();
	$avdelinger = array();
	$organisasjoner = array();
	foreach ($node as $person) {
		$result = db_query_range ('SELECT n.field_person_epost_value FROM {content_field_person_epost} n WHERE n.nid = %d', $person, 0, 10);
		while ($epost = db_fetch_object($result)) {
			$personer[] = $epost->field_person_epost_value;
		}
	}
	foreach ($node as $avdeling) {
		$result = db_query_range ('SELECT n.field_avdeling_epost_value FROM {content_field_avdeling_epost} n WHERE n.nid = %d', $avdeling, 0, 10);
		while ($epost = db_fetch_object($result)) {
			$avdelinger[] = $epost->field_avdeling_epost_value;
		}
	}
	foreach ($node as $organisasjon) {
		$result = db_query_range ('SELECT n.field_organisasjon_epost_value FROM {content_field_organisasjon_epost} n WHERE n.nid = %d', $organisasjon, 0, 10);
		while ($epost = db_fetch_object($result)) {
			$organisasjoner[] = $epost->field_organisasjon_epost_value;
		}
	}
	$personer = implode(",",$personer);
	$avdelinger = implode(",",$avdelinger);
	$organisasjoner = implode(",",$organisasjoner);
	
	if (!empty($personer)) {
		drupal_set_message('<h3>Personer</h3>' . $personer . '<br /><br />');
	}
	if (!empty($avdelinger)) {
		drupal_set_message('<h3>Avdelinger</h3>' . $avdelinger . '<br /><br />');
	}
	if (!empty($organisasjoner)) {
		drupal_set_message('<h3>Organisasjoner</h3>' . $organisasjoner);
	}

return;
}
bojanz’s picture

Version: 6.x-1.10 » 6.x-1.x-dev
Status: Active » Postponed (maintainer needs more info)

Is this still a problem with latest 6.x-1.x-dev?

larowlan’s picture

Status: Postponed (maintainer needs more info) » Active

Yes, also affects 7.x-3.0-beta2. Do you want me to create a new issue against D7 branch or move this one?

I've got a feature that will reproduce this if that helps.
Happy to go debugging if you can point me in the right direction.

bojanz’s picture

Hello larowlan,
I'm looking forward to finally catching this bug :)
Please do post the feature.
Are you using actions_permissions? Does this happen only for core actions? Rules are fine?

Access (whether the action gets shown at all in the dropdown) is determined by the "access" method of the operation plugin. So for core actions that's ViewsBulkOperationsAction::access() (action.class.php).
The body of the method is small so you should be able to get a lot of insight with a few dsm()s.

larowlan’s picture

StatusFileSize
new5.87 KB

Hi
It's only for rules, and no I don't have actions_permissions enabled.
If I modify the rules component class as follows:

class ViewsBulkOperationsRulesComponent extends ViewsBulkOperationsBaseOperation {
  /**
   * Returns whether the provided account has access to execute the operation.
   *
   * @param $account
   */
  public function access($account) {
    return TRUE;//rules_action('component_' . $this->operationInfo['key'])->access();
  }

ie so it only returns TRUE, then it works - so it's in the rules_action function where the issue exists.
Feature attached, hopefully it's stand alone.
Lee

bojanz’s picture

Status: Active » Postponed (maintainer needs more info)

Then the bug is on the Rules side, let's continue in the Rules queue: #1217128: limiting Rules components to specific permissions.

Restoring status for the 6.x-1.x bug.

hnln’s picture

same problem (D7 with both action_permissions enabled and disabled), the rules issue suggest that VBO bypasses rules access for the moment.

bojanz’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

I've committed a workaround for D7 rules (made access() always return TRUE).

Closing the D6 issue since there hasn't been any info since february.