Right now we have a situation where we have some 75 pages' worth of 7.x issues, all of which belong in 8.x now that it exists.
There are two ways of handling this situation:
1. Write a one-off SQL script to update all of the issues' version column.
2. Write integration to Views Bulk Operations so that we could perform this and other mass actions on-demand. Picture mass-moving all sandbox initiative issues to core once the initiative is rolled in, or selecting a sub-set of issues and assigning them all to one of your co-maintainers, or close (won't fix) ing all 5.x issues, or...
So yes. Let's doo eet! Grab a copy of Drupal.org Testing profile and go to town!
See handbook page: Develop on our server (preferred) https://www.drupal.org/node/1018084
Comments
Comment #1
dwwIndeed, 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
Comment #2
dwwThis 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:
That should at least get someone started...
Comment #3
catchSubscribing. 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.
Comment #4
catchI'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.
Comment #5
dww@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.
Comment #6
catchsun++
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.
Comment #7
cweagansThis 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.
Comment #8
pmitchell CreditAttribution: pmitchell commentedHi! 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.
Comment #9
gregglesI'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:
Then I used Drush:
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.
Comment #10
Itangalo CreditAttribution: Itangalo commentedLast 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!
Comment #11
dwwThanks 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
Comment #12
Itangalo CreditAttribution: Itangalo commentedSorry – 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!
Comment #13
dwwCool, 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). ;)
Comment #14
webchickThis would still be very cool to do. I see at #1243332-184: Deploy Project Browser Server and drupalorg_pbs on d.o that we now have a handy helper function for this if you write your own update path, but exposing a UI for project maintainers (or at worst, d.o site admins) would be WAY better.
Comment #15
sunFWIW, 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.
Comment #16
YesCT CreditAttribution: YesCT commentedComment #17
YesCT CreditAttribution: YesCT commentedfor following and unfollowing #2416513: Provide a UI for mass unfollowing and following of issues
Comment #18
webchickAnother data point in favour of this feature at some point: here are two core committers spending 30+ minutes setting sub-issues by a well-meaning but badly timed initiiatve to "duplicate": #2393329: Replace all drupal_render calls with the service, and inject it, if possible. :P