It could be used to automatic add a term to all nodes of a specific content type, or to automatic add information about the user; any information that you don't want the user to be able to choose themself, for any field. It could be made in a way that you simply get the same widget as the user, and then you can fill it in, and then hide the field from the user.

I guess this would a very big change, but I wonder if it is possible, and the amount of work that would need to be done for it?

Comments

bforchhammer’s picture

bforchhammer commented

Yes, I had the same thought a while ago. It definitely could be done, and it does sound like a logical way to move forward...

As far as the AEL module is concerned, I think it would be a rather big change and therefore should probably go into a new module; mostly because it would be rather confusing to existing and new users of this module otherwise. :-)

I haven't thought this through completely, but my feeling is that some use case are already well covered by existing modules, so imo the first step should be to clearly identify the purpose and scope of the new module. Some thoughts:

  • The Field permissions module can be used to hide fields from certain users.
  • Each field already has a "default value", which is assigned when the field is left empty, e.g. because it was hidden from the user. What's missing here afaik, is a) support for tokens on textual fields, and b) support for custom logic to set the value (e.g. php). Related issue on token support: #1070878: Allow tokens to be used in the default value of a field.
  • There's also the computed field module, which doesn't work on existing fields (so it won't be able to help with the title property of course), but gives you a new field type for dynamic/computed values. Not sure whether it supports tokens.
  • The rules module can also be used to set field values during creation of a new entity; in a lot of cases, this may be overkill though, and, from what I remember, rules comes with a fairly steep learning curve.

And there's probably other modules as well...?

I guess this would a very big change, but I wonder if it is possible, and the amount of work that would need to be done for it?

Not sure how much work it would be, depends on the scope and required functionality. It should at least be able to replace the AEL module, I guess.

matsbla’s picture

matsbla commented
Issue summary: View changes

Maybe also the "alt" and "title" field for images, would be great to automatic generate them for different content types.

What other porperties/attributes could take advantage of this improvement?

nithinkolekar’s picture

nithinkolekar commented

this feature makes AEL almost similar to Field default token but I prefer AEL because it provides additional options like
1. when should replacement has to be done.
2. hiding field (which prevents installing another module field permissions).

I propose another feature request for providing fallback value if
Any one of the token replacement fails.
All the token replacement fails.

If this is implement then module can be renamed like Auto Entity Fill/Auto Entity Inject or any other , instead of label which is for title only.

nithinkolekar’s picture

nithinkolekar commented

also another module provides same functionality but for commerce product is Commerce AutoSKU with a another option called "Always regenerate SKU" which is not in AEL and can be implemented too.

geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented

@Jaesin wrote in #2272127-11: Drupal 8 support

I am working on fixing the plugin part of the entity_labels module here: https://github.com/jaesin/autovalue as more of an API module. I see auto_entitylabel as just one use case for the auto label plugin.

vladimiraus’s picture

vladimiraus
Primary language English
Location Brisbane 🇦🇺
commented
Status: Active » Closed (outdated)

Drupal 7 is end of life and no longer supported.
Closing the issue as outdated.