Bulk operations operates on all nodes in nodes table when select all nodes in view is chosen

You're right! I will work on this right now.

Fixed in the latest 5.x-1.x-dev. Please try it and let me know. You'll need to wait for Drupal to refresh the dev release though. Thanks for this report!

A similar bug still seems to exist in the 6.x version.

I want to delete all 'biblio' nodes (1000 nodes), so
* I select the appropriate filter in VBO,
* click the all checkbox for selecting all nodes on the pager
* click the button "select all 1000 rows in this view"
* click execute
* ... and on the next page, the confirmation page does not only list 1000 nodes, but ALL the nodes of the Drupal site. Proceeding indeed deletes all the nodes on the Drupal site, unselectively...

A similar bug still seems to exist in the 6.x version.

I want to delete all 'biblio' nodes (1000 nodes), so
* I select the appropriate filter in VBO,
* click the all checkbox for selecting all nodes on the pager
* click the button "select all 1000 rows in this view"
* click execute
* ... and on the next page, the confirmation page does not only list 1000 nodes, but ALL the nodes of the Drupal site. Proceeding indeed deletes all the nodes on the Drupal site, unselectively...

Acknowledged. It's a tough one too :-)

Fixed in latest 6.x-1.x-dev (which should be available 12 hours from now). Please verify and let me know!

I verify that this is now fixed.

Thanks!

marked #384254: Delete operation not honoring selected filters selects ALL NODES! as a duplicate. i can also confirm that this is fixed in the -dev release.

By the way, to everyone who got bit by that nasty bug: I apologize for not making a new VBO release as soon as I found it. This is a critical piece of functionality that can really mess up a site. Sorry for wasting your time and your data.

Sorry to reopen this again, but you can reproduce this bug also when you are using a faceted view and VBO.
To reproduce:

1) Create a view with some operations (best to test is of course the delete action)
2) Create a faceted view, select the default view you created in 1 and add a block where you can select on content types.
3) Create 2 content types (page & story by default) and generate some content (devel generate!)
4) Select one content type, push select all and then the 'select all rows in this view' - you need paging of course ..
5) The confirm form will show more nodes than actually needed
The argument created by faceted, in this case something like 'content_type:page' seems to be ignored'

I'll be looking into this some more this week, maybe we should also create a config option on the bulk operations plugin to hide the 'select all rows in this view' button.
Not sure if this is faceteds fault or vbo, reporting back later this week.

@swentel, please open a new issue for this since it seems to be specific to faceted views. You can close this one when you're done.

@kratib, ok, created a seperate issue at #519692: Select all rows fails when using faceted views

Same problem still exists in current dev (rel. Aug 4).

Unfortunately, I don't know how to reproduce it! But let me describe what I did:
I've been using the demo page /admin/content/node2 just fine in batch mode in FFox for a few hours today. Then I wanted to start another batch, in a different browser (IE8), as the same user. I selected another content type I need to delete, applied, then selected deletion, clicked button to select all 59k nodes, and executed the task. At the verification summary I saw the process was going to delete all 153k pages on the website!
I cancelled this, and I cancelled the other batch running in FFox as well. Cleared all caches on Drupal using Devel, cleared browser caches.

But now when I try to delete any content type this way, even the one that did work earlier, the select all button still shows the right number, but after submit the summary screen indicates it wants to apply it on all pages on the website.
Tried in IE, Chrome, FFox. Restarted Apache. Always the same problem. Cannot get out of this mode.

P.S. Cleared all APC cache. Disabled VBO module, tried to uninstall it but it has no uninstall feature, then re-enabled the module. Edited the demo view /admin/content/node2 and saved it again. Ran cron. Cleared all caches again. ... All the same, I am still locked in the mode where all website pages are selected!

I am getting this in the latest dev...

Subscribing.

I am getting this in the 6.x-1.x-dev of 2010-Jul-17

Is this still happening with the latest dev?

Appears to work on 6.x-1.10 (without further testing)

Thanks inforeto. Fixed unless someone reports otherwise.

Reopening so we can have another look.
Got the error again on further test, as well as an out of memory error when working on all nodes.
Tested on both 6.1.10 and 6.x-1.x-dev from oct 12.

The memory error is being handled here: #869776: Batch API performance/memory Question/Suggestion.
Are you using any caching module? There's a known issue with caching modules: #361871: VBO loses selection with caching module.

@inforeto: Can you comment on whether the error you're getting is related to any of the issues mentioned in #23?

Head hurts, tested with cache on and off now and so far works with both.
I'm now trying to reproduce it not working. When it wasn't working turning cache off didn't fix it.

I believe it was related to running out of memory, but that doesn't seem related to the amount of nodes.
What i do still get is the max packet when doing more than 1000 nodes, but that's another issue.

Can someone else test this please?

Edit:
On a different test site it worked as well, so i'll just open a separate issue if there's anything new.

Still happens to me - but only with exposed filters!

Steps to replicate the problem:
Make a view for users, make exposed filter for username. Display the view. Click the "all" checkbox to see what number of objects would VBO operate on. Now, using the exposed filter exclude the first user name in the list and apply. You will see the username disappears from the list. Click the "all" checkbox to verify the number is smaller by one. All right. Select "delete users", submit. In the confirmation list you will see all usernames, even the one you had excluded!

I tried to do the same but with the defined filters hidden (not exposed). Then VBO operates only on the selection.

Hope this helps to solve this very old and critical issue.

Re #26: Thanks for the info. I'll try to reproduce your scenario.

The memory issue is being handled separately as per #23 above.

Re #26: I am unfortunately unable to reproduce your scenario on my environment. The excluded user remains excluded in the confirmation page.

If you want to give me access to your dev environment, I could take a look at the bug live. I will need Drupal admin access (or the admin role with Admin Role module) and possible SSH access. Contact me privately if you can do that.

Closed unless I hear back from OP.

I can confirm the same issue #26 is having.

I'm using VBO to change the author info for a bunch of nodes (the original author is no longer with us). When I create an exposed filter on the old user's e-mail address, the "select all" button seems to select all nodes in the table (570 nodes, instead of the 81 it should be selecting). But once I hide that filter, it behaves as it should.