Provide VBO support for issue management

Indeed, this has been on my wish-list/mental-roadmap for ages. A few additional thoughts:

You can define a VBO action to be "multi-step" or something (I forget the exact details). We want that. We want to click a bunch of checkboxes on an issue queue view, select "update these issues" as the action, submit, and land on another page where you define what changes you want to happen to the issue. This 2nd page should be much like an issue followup form, only instead of current issue values as the defaults, all the form elements default to "Don't change" (or whatever). So, you could set a new project, status, priority, or category.

Only if all the selected issues are in the same project should it give options for version, component, and assigned, since those are specific to a single project, and it makes no sense to move issues from multiple projects.

In fact, on d.o, we might only want to VBO-ify per-project issue queues, instead of the site-wide views.

Furthermore, we probably want separate views for doing VBO so we can access control them differently (so as not to invite disaster in the common case).

Yay for seeing this move forward!

Thanks,
-Derek

This sounds worse than it is. VBO calls these "configurable" actions. I wrote one of these for signup_status a long time ago and it's pretty easy. Sadly, the then-maintainer of signup_status committed it along with a bunch of other changes in a single commit:

http://drupalcode.org/project/signup_status.git/commit/ed0e38a618a7e576d...

See #357565: Port signup_status to Views2 for history.

But, basically, it's this:

/**
 * Implementation of hook_action_info().
 */
function signup_status_action_info() {
  return array(
    'signup_status_alter_action' => array(
      'type' => 'signup',
      'description' => t('Alter signup status'),
      'configurable' => TRUE,
    ),
  );
}

/**
 * Perform the action to alter the signup status of a given signup.
 */
function signup_status_alter_action(&$signup, $context) {
  if ($context['signup_status'] != $signup->status) {
    $status_codes = signup_status_codes();
    $signup->old_status = $signup->status;
    $signup->status = $context['signup_status'];
    db_query("UPDATE {signup_log} SET status = %d WHERE sid = %d", $signup->status, $signup->sid);
    watchdog('action', 'Set status of %signup_label to %status_name.', array('%signup_label' => $signup->label, '%status_name' => $status_codes[$signup->status]['name']));
    _signup_status_change('update', $signup);
  }
}

/**
 * Create the configuration form to select which signup status to use.
 */
function signup_status_alter_action_form($context) {
  $options = array();
  foreach (signup_status_codes() as $cid => $code) {
    $options[$cid] = $code['name'];
  }
  $form['signup_status'] = array(
    '#type' => 'select',
    '#title' => t('Signup status'),
    '#options' => $options,
  );
  return $form;
}

/**
 * Validate the form to select which signup status to use for the alter action.
 */
function signup_status_alter_action_validate($form, $form_state) {
  if ($form_state['values']['signup_status'] == 0) {
    form_set_error('signup_status', t('You must select a status.'));
  }
}

/**
 * Submit handler for the form to select which signup status to use.
 */
function signup_status_alter_action_submit($form, $form_state) {
  return array('signup_status' => $form_state['values']['signup_status']);
}

That should at least get someone started...

Subscribing. I could live with a one-off Drupal.org-specific update too for this, that would be better than what we had for D6, which was nothing (well, RSI isn't nothing).

Not related as such, but cross-posting #221510: Update contributors block for 8.x (and minor changes) which also needs doing.

I've neither used nor developed with vbo before, but gave some thought to how this should work, and trying to figure out what'd be ideal.

Since project issues are somewhat unique (in that the comment updates the node, and the history is tracked), we should try to keep that behaviour here.

So I think what would be best is this, whether the VBO architecture allows this I have no idea, it is not going to be simple, and as in #3, I'm more concerned with getting something in place (even if that's an update in drupalorg.install).

* VBO lists for mass issue updates are restricted per-project, since the project issue form has so many per-project values I don't see another way around it.

* This is useful for mass version changes, mass tagging, mass status changes, bulk moving issues from one project to another. To get that, the VBO form is going to end up looking like the comment form for project-issue.

* So, let's actually use that comment form - but remove node-specific stuff from it. Then on submit, take the list of nodes, put the nid (and etc.) back in, and submit the form for each node (or build a comment and call comment_save() if that's possible). The end result would be a comment on every issue with the status changes - just as if you'd posted it one-by-one.

@catch re #4: Yeah, that's basically exactly what I outlined in #1 and #2 above. VBO allows what you describe, and I even provided the example code that more or less does it. The per-project issue views are already separate views, so that much is easy. We only VBO-ify the project-specific views. When we do, we add this new configurable action that basically gives you the comment form so that you can compose an issue comment that will be posted to all the selected issues. VBO even automagically handles doing the updates via batch API if needed.

sun++
sun++
sun++
sun++

http://drupalcode.org/project/dreditor.git/blob_plain/refs/heads/vbo:/dr...

edit: but no support for issue tags so we're still in need of something for issues needing backport.

This sounds like an option to only grant to trusted users. I could see some Joomla troll going in and marking all of the Drupal issues as "won't fix" or something.

In addition, you could use the Poor Mans VBO addon for dreditor.

Hi! I just wrote an Action for D6 that works on VBO 6.x-1.10 which can be used to change the status of the selected issue to 'Closed - Fixed' (i.e. the issue status matching the literal I specified in the PHP code). I am Not Really A Contributor, but I thought it might be useful to whoever is addressing this issue or anyone else who wanted to create a VBO to manipulate issues. What I did was add the following new Action based off of the 'Execute arbitrary PHP' action, then made it accessible in the VBO view I created.

//find key so that value = 'Closed - Fixed'
$states = project_issue_state();
$desired_value = 'Closed - Fixed'; //TODO: This would be more useful as an argument or something.
$desired_key = 0;
foreach ($states as $key => $value) { //for each possible state, see if it's the one we want
    if ($value == $desired_value) { 
		$desired_key = $key;
	}
}

$currNid = $object->nid;  //nid of the object being acted upon
$changes = array('nid' => $currNid, 'sid' => $desired_key, 'comment' => t('This issue appears to be resolved and has been automatically closed.'), );
project_issue_add_followup($changes);

I'm not sure Issue tags could be integrated into this in a generic way since those are provided by comment alter taxonomy.

Here's a function I used recently to close out a bunch of issues:

/**
 * Fun times.
 * Takes all issues for a project $pid from a state $state_from to a state $state_to.
 */
function project_issue_issue_mover($pid, $state_from, $state_to, $comment = NULL) {
  // Set default values.
  if (empty($comment)) {
    $comment = t('Automatically updated.');
  }

  // Set query parameters.
  $result = db_query('SELECT pi.nid FROM {project_issues} pi INNER JOIN {node} n ON n.nid = pi.nid WHERE pi.pid = %d AND pi.sid = %d LIMIT 50', $pid, $state_from);
  while ($issue = db_fetch_object($result)) {
    project_issue_add_auto_followup(array(
      'nid' => $issue->nid,
      'sid' => $state_to,
      'comment' => $comment,
      'followup_no_mail' => TRUE,  // Temporary hack to get around sending of auto-close emails.
    ));
  }
}

Then I used Drush:

drush -l p.growvs.com php-eval "project_issue_issue_mover(8, 4, 17, 'Closing support site');"
drush -l p.growvs.com php-eval "project_issue_issue_mover(8, 14, 17, 'Closing support site');"
..... 

To move all "open" statuses to my state 17 (which was a brand new state created for this purpose.

It's basically a more generic version of what the comment closer in _project_issue_cron does.

Last night I made this video for a poor soul banging his head against VBO + Rules.
It has been concluded that Rules doesn't bring enough Really Useful functionality to be added as a dependency, but it might still be good to know how mass updates can be simplified using VBO + Rules (for future discussions).

Here goes: http://www.youtube.com/watch?v=C1xrlK2pCrA

Cheers!

Thanks for the link. Interesting stuff! However, that's not really the case we'd need for our issue queue VBO needs here. Instead, we'd need an issue update form (D6 issue comment form, D7 issue node edit form) and say "apply all these values to all the issues I selected in my view." In D6 it would post a comment to update the requested fields, in D7 it would just edit the nodes directly (which would in turn generate a comment automatically). From watching the video, it's not obvious how rules would help me with that. I don't want to do all the amazingly powerful stuff you're doing in the video of looking up values and conditionally setting others. Instead, I just need to let the human specify the values as part of a run-time configurable action and then just execute the "make the issue have these values" action. Make sense?

Thanks again for all your input and pointers to useful Rules info -- very helpful!

Cheers,
-Derek

Sorry – it wasn't very clear in the video that VBO allows manual input to complement the actions. That is more clear in this video: http://dev.nodeone.se/en/using-rules-componens-with-more-than-one-parameter

I probably seem pretty frantic about Rules. Sorry about that.
The point of this clarifying comment is *not* to try to push Rules into drupal.org (which I am far from certain is a good idea), but to show how the problem discussed above could be approached. I hope it can be of some use!

Cool, thanks. However, as far as I understand it, VBO handles "configurable actions" just fine and doesn't need Rules to implement those. I don't want to seem anti-Rules or anything, I'm just trying to understand what you're proposing Rules would actually help here. AFAICT, everything we need to implement this feature (both in D6 and D7) can happen with just VBO and core actions (or at least a fairly trivial custom action in D6 project_issue were our crap is so hard-coded and weird in the first place). ;)

FWIW, the PoorMansVBO feature for Dreditor mentioned in #6 still exists in https://github.com/sun/dreditor/compare/vbo and still works, but must be built manually.

Even though Dreditor is only used by a small subset of drupal.org power users, Dreditor can be installed by anyone. I never felt comfortable with merging the feature into the mainline, because any kind of misuse would have very negative effects:

I'm able to destroy the entire issue queue of any project in a few seconds, either willfully or unintentionally, up to the point of additionally moving all issues into a different project. — Absolutely no one here has any way to revert my bulk operation actions, without crafting a custom PHP/SQL script that tries to (1) figure out which issues were touched by the operation and (2) revert them to their previous state, but, of course, additionally accounting for potential manual corrections by other users (i.e., additional issue updates).

Of course, reality is also that anyone can re-implement this code at any time in a custom user script; the necessary code is publicly available, just copy it. As such, my above reasoning is a bit naïve, but at the very least it limits exposure + usage to more experienced people - or alternatively - blackhats with very malicious intentions.

Due to these considerations, my top-most recommendation for any kind of VBO implementation would be the following:

Ensure that every executed bulk operation can be reverted - i.e., the total effects of the bulk operation itself, not individual issues.

Theoretically that's a fundamental data security problem of VBO itself (and the entity revisioning system of Drupal core). However, PI has the benefit of tracking node changes on its own, so there ought to be a way to leverage that information to account for unintentional/worst case scenarios.

for following and unfollowing #2416513: Provide a UI for mass unfollowing and following of issues