Adding assets to a log, 2.x

I’m getting a bit more into 2.x and noticing a consistency issue with how assets are added to logs. For example adding a birth log. The mother asset is added with just a search box. There is no way to filter or see a list of all possible assets to add. It just shows a list as you start typing of potential options to select. Directly under that the children asset brings up a popup with filtering abilities and displays a list to select from.

I do like the speed at which just the simple search bar adds if I know the asset name, but with a large list of assets I don’t find this always helpful and am often finding myself opening another window to search for the proper name of the asset I’m looking for, then going back to the log to enter the correct asset name.

Were these design choices to selecting assets differently though farmOS?

Additionally I’m having issues with the simple search box not working on mobile. I’m using chrome on android and using the same example above, when selecting a mother for a birth log I start typing and I don’t get a suggested list like I do on desktop. I have to know the exact asset name and type it out or I get an error when submitting the log.

Thoughts on if this is working as intended, or this is a bug?


On that same note when selecting an asset where you get the full popup to filter, the filter options in 1.x used to include location and group filtering. This really helped to narrow down what asset I was looking for.

1 Like

The mother asset is added with just a search box.
Directly under that the children asset brings up a popup with filtering abilities and displays a list to select from.
Were these design choices to selecting assets differently though farmOS?

Good question @BOTLFarm - it was more of a “default” design choice than an “intentional” one - and certainly one we can iterate on!

Jotting down some related history/considerations…

The mother field is added to birth logs here: farmOS/Birth.php at 8a562d673e59e8fd405bc2bcc40a257e649ff4d5 · farmOS/farmOS · GitHub

It uses the FarmFieldFactory class/service to build an entity_reference field definition. This service sketches up some default configuration for the field definition, based on the type. For entity_reference fields, the default “widget” (form element) is entity_autocomplete which is the “search box” you’re referring to.

Here is where that happens: farmOS/FarmFieldFactory.php at 8a562d673e59e8fd405bc2bcc40a257e649ff4d5 · farmOS/farmOS · GitHub

So in other words: by default, entity reference fields are rendered as autocomplete search fields.

As for the “Children” field on birth logs… this is actually the same asset entity reference field as all other log types - we just change the label of it from “Assets” to “Children” on Birth logs (idea being: birth is what’s happening to the children). This asset field is added to all log types (as a base field) here: farmOS/farm_log_asset.module at 8a562d673e59e8fd405bc2bcc40a257e649ff4d5 · farmOS/farmOS · GitHub

And by the same logic, by default, that field would have the same autocomplete search widget.

But… we override it to use the “Entity Browser” widget here: farmOS/farm_ui_views.module at 8a562d673e59e8fd405bc2bcc40a257e649ff4d5 · farmOS/farmOS · GitHub

The reason that happens in the farm_ui_views module is, well, because farm_ui_views is the module that provides the farm_asset View, which is what we see in the Entity Browser.

So… loooong story short… we could probably make all entity_reference fields (including “Mother” on Birth logs) use the Entity Browser by default, instead of the autocomplete search widget.

Or… make it an option that modules can decide between, via FarmFieldFactory.

If we made Entity Browser the default, we would want to review all the fields that would be affected by that (probably in both farmOS core and known contrib modules) to see if that would adversely affect any of them.

One that comes to mind: the “Location” reference field on Logs (for referencing location Assets) currently displays as an autocomplete search. Should that also change to Entity Browser?

This is something we should open feature requests for in the issue queue. (Side-note: maybe we need a “v1 parity” tag for issues to highlight them.)

I think the Entity Browser is the more thorough way of finding all assets weather it is land, animal, plant, sensor, etc. However it is an additional 3 mouse clicks for someone who knows the asset name off the bat, so I see the downside to switching all the autocomplete fields to Entity Browsers. This is just potentially extra work every time someone creates a log. Maybe there is a hydride version that starts with auto complete, but if you don’t know what your looking for you can open the Entity Browser?

Would you like me to open this issue?

This is something I’ve wanted to see (as a general Drupal module) for a long time! A “widget switcher”! Basically: allow a default widget to be configured as the first choice, but allow a user to swap it out for another if they wanted to. That would be the best of all worlds I think! And it would make a great general-purpose Drupal contrib module - wouldn’t need to be farmOS specific!

Would you like me to open this issue?

If you have a chance, please do! Thanks @BOTLFarm!