Provide an action for modifying entity values

+1

+1

+1

I see why it's not appearing but don't know how to fix it.

Line 9 of fields_actions.inc checks to be sure that the "content" module is installed. Now that CCK is in core, D7 doesn't have a "content" module installed... or at least I cannot find it.

Subscribe

subscribe

subscribe

This will need to be rewritten for scratch.
What you're seeing is D6-era code.

Yep. And this might be the most important part of VBO remaining to be done.

subscribing

subscribing

subscribe

Subscribing

sub

subscribe

+1

subscribe

Since people have been asking about the status of this, the status is that I don't see myself working on this for at least a month more.
Plenty of VBO issues still need attention (in my limited free time), and this issue has the least priority (since it's essentially about new functionality, not bugs in the existing code)

sub.

Sub

sub

Subcribing

subscribing

sub

Subscribing

Subscribing

Hello, everyone. Wanted to give you an update on where we are on this.

The D6 version of this code used the following approach:
1) For CCK fields, embed the widgets
2) Hardcode a list of node properties (title, published, etc), so that they can also be edited. Allow other modules to extend the list (I'm guessing none ever did).

The D6 code was node centric. For D7 we want / need this to work for all entity types.
And thankfully, the Entity API gives us a way to fetch metadata about entity properties (#2 in the list). Entity API provides the metadata for core entities, and other modules do so themselves (Commerce, Og, etc), so we can use it to find out the right columns and do our thing. This was a big part of my decision to make VBO depend on Entity API.

However, there's currently no code that maps the metadata information to specific form elements. Rules has code that does this, so I've started an effort to generalize it, extend it, and get it into Entity API: #1192120: auto-generate entity forms. Once that issue gets resolved, making entity properties editable should be a snap.

On the other hand, I don't really expect the Field API widget embedding to go easy or fast. Might be easier to try and handle it through the same generic mechanism that we'll use for properties, though there are various corner cases there as well (handling unlimited fields, file uploads, etc).

So, that's the current state of things. Since VBO D7 is still pretty much a one-man operation, and than one man is me, doing this on my free time, this might not be done for another month if nobody else jumps in.

Thanks for the update and thanks for your continued work on this module!

PS: I'm learning drupal 7 module development (just beginning - and in my spare time) so I'm hopeful that I'll be able to pitch in more on projects like this in the future.

Thanks so much @bojanz

All: If you need this capability, you can create a rules component that takes two arguments, the entity and the value you want to change something to. A condition should check that the field you want to change exists, and then you can set the value of that field. Then VBO can execute that rule.

I plan to do a screencast on this intermediate technique this week.

For those of you who need this capability right now, I did a screencast on how to use a Rules component with VBO to do exactly what we will do with fields.inc when it comes out.

Thanks Randy, the screencast is awesome (and very helpful). Added a link on the module page.

Further to #30, here's a rules export for batch setting a taxonomy field that works with D7 VBO.

Note, to work on your site, prior to import, you'll need to change one line in the exported code.
Change the the taxonomy term reference field name, from
node:field-sport
to your own taxonomy field, e.g
node:field-section
and also probably the rules component label and machine name.

Note there's a remaining issue where the tid select is a text field, not a select box, so you need to enter tids manually, but it works and is better than nothing for now.

cheers,

DT.

P.S VBO rocks!

subscribing

Tagging.

Subscribing.

You know the saying, can't teach an old dog new tricks ;) Seriously though, news will gradually filter through.

Back on topic, I understand that this is a big task... any progress updates?

I haven't worked on this since the beginning of august, and I haven't worked on VBO itself the whole september. Hence the delay.

During the previous few days, I went through the queue, addressed about 35 issues (the number of open issues should drop to about 80 in the next two weeks, based on the current "fixed" and "postponed (maintainer needs more info)" numbers), released 6.x-1.12 and 7.x-3.0-beta3.
I also removed #1207348: Integrate multi-page selection from the list of blockers, so this issue is the only thing separating us from the first stable release.

Will try to get a patch up as soon as I find more VBO-time, since I have a half-half-baked version running locally.

good news. thanks for your work bojanz.

This half-half-baked version sounds stable enough to be tested :) and i'm sure a few people out there will help testing and debugging.

Is there anything going on here? What is the scope of this issue?

Current status: @bojanz has done a partial rewrite, but has not posted it. He's buried, as usual. Thanks for all you've done on this, @bojanz!

I shoud have it up in the next few days. This is my week to release all the half-done stuff I have laying around (this action, affiliates, etc...)

Could you post what you have so far so that someone else can maybe finish it?

Hi there !

@bojanz, any news on this ?

I have some work to do on the code I made to Port taxonomy term operations to d7 , but would rather help debugging/finalizing this issue.

Half-done stuff is better than nothing, and i'm sure we can help :-)

Thanks

I'm out of the country, on location for a client project.
I'll try to have it up on the weekend.

I need this for a current project, so once the work so far is posted I can see what I can do to help taking it forwards.

willing to test :)

I would like to see the current state of the code as well.

Long time no see. Sorry for the delay. December was rough, and so was this code.

Attaching the first version of the patch.

Todo:
1) Token replace doesn't exist at the moment. Make it work for properties and Field APi fields of type "text".
2) "Add new value to %label, instead of overwriting the existing values." functionality is broken for properties and non-existent for fields (should work for all fields that have unlimited cardinality).
3) When configuring the action in VBO settings, there should be checkboxes to select which properties should be accessible to the user, and whether to allow editing fields or not (for more Field API granularity there's field access which this code should respect).
4) If the view has a filter (exposed or not) on the bundle, take its values and show only the fields for selected bundles (so if a node view only shows articles, only show fields attached to articles, forget about those attached to pages and product_displays)
5) Code needs comments and cleanup.

Here's a screenshot of how it looks like on nodes currently.
You will notice that even if several types have the same field (like the Body field, for example), it will get added once for each type.
No way around this without some ugly hacks and doubling the code, Field API really wants to do it per type, no sharing...
Plus, it's extremely hard to decide when a field is needed the same (I'd say same cardinality, widget, settings)

OMG!!

Looks awesome :)

Today's progress. Big code cleanup, with enough comments.

Made it use the entity wrapper for setting property values, avoiding problems when a property needs extra massaging by its setter callback.
Fixed the code that unsets the #required status of a field widget to actually work.
Fixed an error when the action form gets rebuilt via ajax (because the file is no longer included).
Made VBO changes to make 3. (from #52) possible, by having the action settings form get the entity type.

Noticed that imagefields don't work. Which is odd, since I think I remember them working at first (before I added all bundles. Maybe that's where it broke).

Still needs a ton of work, but we're moving.

Imagefields now work.

Hey bojanz. Thanks so much for your work on this. I used your latest patch, but after enabling the action in my view setup, I'm not seeing the action available to me when looking at the view displayed. I do see a separate rule action I previously set up, so I know I have VBO working. I feel like I missing something obvious.

Thanks.

Ah. I think I need to set up the action in config/system/actions, but I'm getting the following error when I select "modify entity values":

Warning: Missing argument 2 for views_bulk_operations_modify_action_form(), called in /path/to/site/modules/system/system.admin.inc on line 3023 and defined in views_bulk_operations_modify_action_form() (line 37 of /path/to/site/sites/all/modules/contrib/views_bulk_operations/actions/modify.action.inc).

Edit: The mention of line 3023 is for an older drupal version (~7.3). I decided to upgrade the core and try again, in version 7.10 it's line 3072.

Nope, it should just appear in the settings of your VBO field. Try patching -dev, not sure if it works with beta3.
In any case, I'll have a new patch up in a few hours, addressing more pain points from #52.

Thanks for the response. I did in fact patch against dev.

I do see the action available in the VBO field and I have it enabled, but nothing new shows in my operations dropdown when actually displaying the view.

Attached screenshots of the setup and problem.

Can you try logged in as admin?
This is a permission issue. I'm guessing you have actions_permissions enabled, but the role doesn't have the permission for the new action assigned.

Rookie mistake! I thought I was logged in as admin.

I see the operation now. Thanks!

New patch. Getting closer to a committable version.

1) In VBO field settings, you can now select which properties and fields you would like to be available to the user. This looks pretty much the same as it did in D6.
And yes, I managed to support choosing individual fields after all.
2) If the entity type only has one bundle, the "Fields" fieldset will have a less specific title.
So instead of "Fields for type Product" (commerce_product example) it will just say "Fields".
Also, won't show fieldsets for bundles that have no instances attached anymore.
3) If there is only one fieldset on the form (for example, only "Properties" since no fields were made available), both the fieldset and the title won't be shown, showing only the selectors and the widgets themselves.
4) If there is only one property or field enabled, it will be displayed right away, instead of being hidden behind a selector checkbox (like it is when there are multiple properties and / or fields available).
6) "Add new values instead of replacing existing ones" now works for both properties and fields. If you try to set 5 values for a field that has a cardinality (max number of values) 3, VBO will set a warning message (only once of course, won't repeat it for each entity).

What remains to be done:
1) Tokens
2) Validation for property types such as integer, decimal (#element_validate)
3) Any comments you might have.

There's also:

4) If the view has a filter (exposed or not) on the bundle, take its values and show only the fields for selected bundles (so if a node view only shows articles, only show fields attached to articles, forget about those attached to pages and product_displays)

But that can be done in a followup issue.

@bojanz. Awesome. Can't believe this patch was waiting here for me a few hours before I needed it! LOL

So I've done my little bit to help your awesomeness: Applied patch to latest dev and all seems good. Allows me to now expose and modify a field that contains a list of node references to other nodes and seems to work sweet.

One little thing. The field I use is set to have unlimited values so line 40:

          if ($field_count > $field_info['cardinality']) {

spits an unnecessary warning in that case (because $field_info['cardinality'] will be -1).

But thanks again!

Ah, right. I need to handle "unlimited" properly. Thanks for reporting.
Until the new patch, it's just a matter of modifying the if to:

if ($field_info['cardinality'] != FIELD_CARDINALITY_UNLIMITED && $field_count > $field_info['cardinality']) {

Confirm that #64 patch plus #66 modification is working well for me - I'm looking forward to a release :)

Hmm... With patch 64 I'm getting the following ajax error when I try to add a VBO field to my view.

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: http://localhost/admin/structure/views/ajax/add-item/user_work_orders/pa...
StatusText: OK
ResponseText: Notice: Undefined index: show_matching_tokens in views_bulk_operations_modify_action_views_bulk_operations_form() (line 472 of /path/to/drupal/sites/all/modules/contrib/views_bulk_operations/actions/modify.action.inc)

Thoughts?

Edit: Looks like $options is empty in the form function.
Edit 2: Manually setting the default value on line 472 and 478 to TRUE works as a work-around. I'm not sure how views_bulk_operations_modify_action_views_bulk_operations_form_options() is supposed to be called. Should it be called in the form function or should it be automatic?

Also line 492. Shouldn't $bundle_key be $bundle_name?

Edit: sorry, originally had the wrong line number.

Aside from my two previous posts, it's working great.

I know it would take a lot of work. But it would be great to be able to combine fields that overlap entity types. If that is possible, it might be better to list the fields with a "used in type1 and type2" wording rather than grouping by content type. Just a wish list item. I'm just glad it's working!

Created two issues regarding related fixes that I had in this patch, and committed them:
#1414680: Pass the entity type to action and action config forms
#1414696: Allow action forms to use #ajax

Rerolled the patch without the committed code (so you'll need a git checkout or tomorrow's -dev to apply it properly), and addressed #66 #68 #69.

I know it would take a lot of work. But it would be great to be able to combine fields that overlap entity types. If that is possible, it might be better to list the fields with a "used in type1 and type2" wording rather than grouping by content type. Just a wish list item. I'm just glad it's working!

I really wanted to do that, but it's just not feasible.
Same field on two different types is two different field instances. They can have completely different settings (think of an entityreference field referencing a different entity type, for example). So even with a ton of code added comparing the settings, you'd end up with some fields grouped and some fields not grouped, which is inconsistent and probably confusing, which means there's no real gain.

I really wanted to do that, but it's just not feasible.
Same field on two different types is two different field instances. They can have completely different settings (think of an entityreference field referencing a different entity type, for example). So even with a ton of code added comparing the settings, you'd end up with some fields grouped and some fields not grouped, which is inconsistent and probably confusing, which means there's no real gain.

Understood. Thanks for your hard work.

- Added property validation
- Redid the code that applies the changes to the entity, fixing a ton of bugs and crashes.

All we have left on the todo list are tokens, and then this can be committed.
Please test. It's now vital that we catch any remaining bugs.

And here's the (hopefully) final version.

Tokens now work. Tested "Title" properties, Body fields, "Alt" columns of image fields.
Removed the "Show matching tokens" option (that added the "Matching token: [node:title]" text to the node Title description, for example) because there's no way to do it nicely for Field API fields, so it would be inconsistent for it to only work for properties.
The complete token list that the Token module provides should be good enough for now.

Please test! Thanks.

EDIT: Also decided that the "Fields for @bundle_key %label" should just be "Fields for %label".
So when editing comments you don't get "Fields for node_type Article comment" ("Fields for Article comment" sounds better. Same for other entity types).
But no need to reroll for that.

subscribe.

I cant entirely follow, but this should also take on bulk operations on datetime fields right?

cheers,
derp.

Patch in #74 is working for me. Didn't test Tokens, though.

Okay, so amateescu did a review, found a problem with displaying available tokens (always showed the node type, instead of showing the ones for the current entity type, plus the site tokens), and a problem with ordering form elements (the "append" checkbox sometimes wasn't correctly placed).

Fixed those two issues, and committed the patch:
http://drupalcode.org/project/views_bulk_operations.git/commitdiff/86263...

Marking this issue as fixed.
Still unsure about the UI, so if you have any comments on that (or the code), feel free to open a new issue and let's discuss it.

Followups:
#1421666: The "modify entity values" action should respect the views bundle filter if it exists
#1421656: Extend the "modify entity values" action to add a delete mode for multiple-value properties and fields

Than you bojanz.

Hi
I have updated to the dev version but pulling terms from a taxonomy view I can t see the proper tokens displayed, it s only offering "Site information" tokens but not the term fields.
tx
Simone

Provide a short summary