Views Bulk Edit Version: 8.x-2.0-alpha2 module doesn't work nicely with multiple bundled views.

Tested with Content, Image and Taxonomy term reference fields, some lists and number fields and boolean field.

Bulk action attempt has deleted all values from edited fields leaving them empty although there were some vaues inside these fields before bulk edit attempt.

Marking this issue as bug and Critical since such bulk actions can result in huge data loss.

It works with Title, Body and some other basic fields... so not everything is broken.

Tested with:

Views Bulk Edit - Version: 8.x-2.0-alpha2
Views Bulk Operations - both Version: 8.x-1.0-alpha2 and Version: 8.x-1.0-beta2
Drupal Core - Version: 8.4.2

Comments

devad created an issue. See original summary.

devad’s picture

Title: Compatibility with Entity reference fields with multiple values » Compatibility with Entity reference fields
Issue summary: View changes
devad’s picture

Title: Compatibility with Entity reference fields » Compatibility with Entity reference and Lists fields
Issue summary: View changes
rajab natshah’s picture

devad’s picture

Title: Compatibility with Entity reference and Lists fields » Compatibility with many field types
Issue summary: View changes
devad’s picture

Issue summary: View changes
devad’s picture

Issue summary: View changes
benjy’s picture

Have you tried Views Bulk Edit 1.x? Wonder if it's the same there also.

devad’s picture

Re: #8

Tested. Views Bulk Edit 1.x works fine with Term reference field. This issue is about ver. 2.x only.

graber’s picture

I faced this issue before. The cause is in Views Bulk Operations (fixed by commit: Improved configuration form storage handling to allow submodules for storage operations). The strange thing is that you're using 8.x-1.0-alpha2 and that commit IS in alpha2. Check if you updated the module properly and better use VBO beta2 or the latest dev.

devad’s picture

@Graber

I have updated test site to VBO beta2. Problem remains the same.

Testing link at simplytest.me:

https://du1lh.ply.st/user
Login/pass: admin/admin

Test VBO form:
https://du1lh.ply.st/admin/content

Simplytest.me test site will last 4 more days.
You can use it and manage it for debug purposes as you like.
You can install Devel or whatever you need for testing purpose.
Feel free. I don't need this test instance.

graber’s picture

The problem is that I can't reproduce on a normal instance and I can't do anything without debugging the code.

Is anyone else facing the problem (excluding simplytest.me)?

graber’s picture

Status: Active » Closed (cannot reproduce)

The test site is suspiciously fast, as it was using Varnish or some other caching engine.

Also note the content view path on views page (https://du1lh.ply.st/admin/structure/views) is /admin/content, while on the view edit page (https://du1lh.ply.st/admin/structure/views/view/content) it's /admin/content/node. Why? *edit* I see that's the normal behaviour. Strange.

Anyway, I wouldn't rely on simpletest.me. Feel free to reopen this issue if you can reproduce it on a normal environment where you can actually look under the hood.

devad’s picture

Title: Compatibility with many field types » Modify entity values action works with single bundled views only
Issue summary: View changes
Status: Closed (cannot reproduce) » Active

I was able to track down the problem. The view was content view with all content types enabled. Adding content type filter (limiting view to show Articles only) resulted in valid VBO "Modify entity values" actions.

I have tested with other entities and their bundles (terms/vocabs) and it is the same behaviour. Only views with entities limited to one entity type (bundle) works fine regarding "Modify entity values" action.

Problematic behavior is kind of erratic since it seems that problem manifestation depends on bundles order/sequence as well. For example, if there are two content types available in the system (articles and basic pages) Modifying entity values of Basic pages inside multi-bundled view works fine, and Modifying entity values of Articles fail.

So, steps to reproduce:

1. Create view with all content - not limited by content type.
2. Add some articles with tags.
3. Try to edit article's tags using "Modify entity values" VBO action. - it fails.
4. Add tags field to Basic pages
5. Add some basic pages with tags.
6. Try to edit basic pages's tags using "Modify entity values" VBO action. - it works. :)
7. Add content type filter to view and limit it to display articles only.
8. Try to edit article's tags again using "Modify entity values" VBO action. - now it works!

I hope this will help to reproduce.

Changing issue title, changing status back to "active" and keeping it critical since it can cause severe fields data loss if broken "Modify entity values" action is applied to huge number of entities.

graber’s picture

Assigned: Unassigned » graber
Status: Active » Needs work

Thanks for this comprehensive analysis @devad, I'm on it.

graber’s picture

Assigned: graber » Unassigned
Status: Needs work » Needs review
StatusFileSize
new1.97 KB

Patch attached.

The problem was $form_state->set('form_display', $form_display); in a foreach for all possible bundles (overwriting the previous value for next bundles and leaving it at the last bundle value) and then getting that value in a loop for all bundles, expecting different values.

@benjy, this is also the case in 1.0-beta I'm afraid. See Drupal\views_bulk_edit\Form\BulkEditForm line 107 & 200, both in a foreach.

devad’s picture

Issue summary: View changes
Status: Needs review » Reviewed & tested by the community

Thnx @Graber

Tested patch #16. It works.

Working link:

https://dugse.ply.st/admin/content
admin/admin

benjy’s picture

Status: Reviewed & tested by the community » Needs review

Would be good to get some tests here?

graber’s picture

Version: 8.x-2.x-dev » 8.x-1.x-dev

Yes, after the weekend I'll create an issue to make some automated tests for 8.x-2.x. It's a critical so commiting the patch and making a new release as well. Changed issue version to 1.x, looking at the code it's also affected.

  • Graber committed 0ea3ce3 on 8.x-2.x
    Issue #2921735 by devad, Graber: Modify entity values action works with...
benjy’s picture

OK thanks, normally I never commit patches without automated tests because otherwise the same issues have a way of finding their way back into head. Similar to core, it should all happen in the same issue so lets add the tests and fix 1.x here.

devad’s picture

Status: Needs review » Patch (to be ported)

Thnx for 8.x-2.x-beta1. Tested on production site. it works.

Regarding 8.x-1.x ... I suppose it makes sense to change status to: Patch (to be ported).

graber’s picture

@benjy, I agree that is the right approach. 2.x doesn't have any automated tests so I created #2922964. The problem is that it happeneed so, that I'm relatively new to automated tests and it still takes me quite some time to write them. But no worries, I'll catch up :)

graber’s picture

Version: 8.x-1.x-dev » 8.x-2.x-dev
Status: Patch (to be ported) » Fixed

1.x is no longer supported.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.