Still on Drupal 7? Security support for Drupal 7 ended on 5 January 2025. Please visit our Drupal 7 End of Life resources page to review all of your options.Fetch form view mode dynamically to render to restrict the form fields.
views_bulk_edit module is using bulk_edit form mode to render the form fields. Problem here is we are getting all fields including url alias field, some restricted fields... So suppose user wants to update only field, then in our bulk edit form if we are showing all the fields unauthorized user can do mischievous actions. So if fetch form mode dynamically through UI we can control the form fields.
| Comment | File | Size | Author |
|---|
Issue fork views_bulk_edit-2950665
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 2950665-fetch-form-view
changes, plain diff MR !13
Comments
Comment #2
graber commentedHi, are you willing to provide a patch for that? Would it require an additional step in the configuration form or can it be done easier, in the view admin settings form?
Comment #3
dwwI think the heart of this issue is this line in Drupal\views_bulk_edit\Plugin\Action\ModifyEntityValues::getBundleForm():
That 'bulk_edit' form mode isn't created automatically. Site admins have to manually do so. However, if they do, then
getBundleForm()will honor the view mode (sort of) and only provide checkboxes for the fields that are visible in that view mode. When I say "sort of", I mean that the field order isn't honored, if you use field_group, that's ignored, etc. You just get a single checkbox for each field, ordered alphabetically.Perhaps no code is needed here, other than a patch to the README to explain how this works and encourage site admins to configure a specially-named form mode for their site if they want to restrict what fields are available via this action.
Alternatively, the machine name of the form mode to use for this could be a configuration option in the view config, during the buildPreConfigurationForm() step. Then it wouldn't have to be hard-coded magic, but you could potentially configure different view modes for different bulk edit scenarios, and each VBE view could point this action to a different view mode.
Comment #4
dwwOh yeah, and it's also grabbing "fields" like Language and Revision log message which aren't fields as such that you can configure in your form mode. :( I'd love to hide those, too, but even defining my own 'bulk_edit' form mode doesn't seem to let me. So yeah, it'd be great to be able to somehow control the entity properties (that's what we call this special-sauce fields, right?) that are displayed on the bundle form. Not exactly sure the cleanest way to do that.
Comment #5
dww(minor edits to the summary to clarify)
Comment #6
dwwInitial update to the README. This should probably be further clarified and wordsmithed, but it's a start. ;)
I agree it'd be even better to allow this to be configured dynamically, instead of being hard-coded, but until that happens, maybe an update to the README is a good start.
Comment #7
graber commentedThanks for the README update dww, to address this properly we need a form mode selector in the
buildPreConfigurationForm()method though. About the extra fields that can't be configured - may be related to #2920721, a different issue in general.Comment #9
dwwThanks for committing the readme fix. We can further clean that up to talk about the config knob with whatever new patch happens in here.
Meanwhile, I had started briefly looking into how to make this happen. The problem is that at the
buildPreConfigurationForm()phase, we still have no idea what entity types, much less which bundles, we'll be operating on. So, I don't know how to provide an accurate form mode selector. I suppose we could have a selector that finds every form mode on all entities, and add some help text about it, but that seems a bit ugly. Am I missing something? Any bright ideas on how to do this in a clean way?Thanks,
-Derek
Comment #10
graber commentedBut we do, see
Drupal\views_bulk_operations\Service\ViewsBulkOperationsViewData::getEntityTypeIds(). The VBO data service is already injected in the action constructor and used in thegetViewBundles()method.Comment #11
dwwSweet, thanks! That's exactly the kind of info I was hoping you'd have an answer for. ;) I've got to deal with other things in the short term, so I'm not going to be able to work on this soon. I'll assign to myself when I've actually got time to work on this again. But that's very helpful, either for future me, or anyone else who wants to tackle it in the meanwhile.
Cheers,
-Derek
Comment #12
mlzrHello Graber, ddw,
Is it possible I ask a question about the above conversation?
There is a piece where you want rid of "Language" field. And that's just what I am looking for, to bulk change the language field.. :-}
Is it not possible to edit this language field this way?
Tanks,
Marchello
ps. I installed Drupal 8 and create a website, non- multi language. Now it turns out the site has to move to a multi- language website. But now the problem is all content is labeled (a sort of 'standard?') 'en'. So I want to bulk edit all nodes from 'en' to my language ( 'nl' ).
All is working correct, also VBO/VBE. Also try'd 'bulk_edit' edit-form layout. Works, no problem. The only field there is 'Language' bud it don't appear in the list of possibilities in the "Modify field values".. :-|
Comment #13
mlzrOk.... update on my comment yesterday.:
I managed to set all content labeled 'uk' to my own language (in my case to Dutch 'nl'). First I tought I have to set the 'langcode' in the database to, in my case 'nl'. Bud with a little investigation it tuns out all content is 'normalized' so verry mutch 'spead' all over the databse. It is not enough to set the nodes to the new langcode, all related fields and connected files has to change too. So a lot of work and not a verry safe way... for me a 'avoid if possible' way to do this.
I had tried to activate my language as second, then put that as my default language. Bud I got stuck in that path.. all kind of things get broken.
Now I did it this way - just for someone who wants to archive this:
1. enable module language and all translate modules
2. enable the 'new' language (in my case Dutch - nl)
3. set the new language for all the content (/admin/config/regional/content-language) as standard to the new language, and enable 'language switch' on the edit page (not for the site 'as default' not yet!).
4. For each node: open it, set te language to the new language, and save. Do this for all content nodes, and other content if you have.
5. Now set the new language to default for your site (/admin/config/regional/language).
6. Clear the cache. And see the results.
All is in the new language now.
To be save I disable the module 'pathauto' (I use this on every site) before I begun, and enable when all is in the new language. This becorse I see this modules has some issues with some language switching. Don't know if in this case it was necessery bud I dit it just for safety (don't search the problems). And I leave the 'old' language stay configured for the user interface.
For my this was some work, bud for so far on this moment I think this is the only way to to this. Yes, it is some work. For a site with some hundred nodes I think it is 'to do'.
For sites larger than this I hope the guys form this module VBE somehow enable the 'language' as an option to bulk- generate to an new language :-P ..
Marchello
Comment #14
pianomansam commentedI'm not sure when it occurred, but form modes now require the entity type id as part of their name. This is true at least for me on Drupal 9.4.6. So for nodes, the form mode forbulk_editnow needs to benode.builk_edit. I'm going to create an issue branch shortly.Please ignore. I determined that I was doing something wrong.
Comment #16
pianomansam commentedThe issue branch pull request is ready for review. Yes, the tests failed, but that's not unique to my PR. It looks like they all are.Please ignore. I determined I had something wrong.
Comment #18
pianomansam commentedComment #19
dwwRestoring the status. I believe this is still something this module could provide.
Comment #20
pianomansam commented