Started using V2. First thing I’ve run into is when multiple locations need to be selected for a given log entry each location has to be entered one by one with the “add another item” button. Wow, how incredibly tedious. This also looks to be the case for other selections like equipment. In V1, the list would open and a CNTRL Click of each item needed would bring the whole group in at once. Almost all my logs involve multiple fields (locations) or sets of equipment. This is really adding to the key strokes and clicking!! HELP
3 Likes
If I understand the problem correct, you can add multiple locations if you separate them with a comma.
But, it sees like a bug, because it’s only the last one that’s saved.
1 Like
Thanks for raising this @graffte - I see how that can be quite tedious. I’m curious what you think about the UI for adding assets to a log that opens a modal for searching and selection a few assets in bulk (this is called the “Entity browser” widget). It’s not exactly the same as V1, but do you think this would be an improvement over the “Add another item” UI?
As you described assets can be added to a log for different reasons (asset, location, equipment, parent…) @BOTLFarm raised a similar question in another thread early in the v2 lifecycle. I’m afraid we’ve let this slip through the cracks while working on the foundation of v2, but now is a great time to circle back to this (very!) important UI consideration.
I’d like to highlight the end of @mstenta response here: Adding assets to a log, 2.x - #3 by mstenta
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.
I tend to be in favor of making Entity Browser widget the default. I think it makes sense for most asset reference fields (asset, location, equipment) but I see how a simpler widget (text search + add another) can be sufficient for simpler asset references (parent, mother, group).
In the end I don’t think there is a right or wrong answer though, it likely comes down to the use-case and user preference. With that in mind I’m curious if we could make this choice configurable by users. Ideally such a configuration could be on a per-field basis - I don’t think the same widget is the best choice for all of these asset reference fields
1 Like
yes, I tried inserting a comma in a single entry string and only the last entry gets saved. Confirmed this for the equipment and location entry fields.
I’d still prefer getting the full selection list and being able to use CNTRL Click to select all that apply. This is much more time efficient. The manual data entry time is a killer.
1 Like
It sounds like you are thinking of a simple “select list”, right @graffte? (Basically a standard HTML <select> element). Counterintuitively, this kid of “widget” would require some additional development to add to farmOS v2, even though it seems like a simple one. The reason is: in farmOS v1, areas used to be taxonomy terms, but in farmOS v2 they have become full-blown asset types. Drupal provides a built-in select widget for taxonomy terms, but assets are bit more complicated… because they can be archived, made hierarchical (using our custom parent field), and they can be different types of assets (eg: land, structure, water, etc). It’s certainly possible, but not available “out of the box” like the “autocomplete” widget that farmOS v2 uses currently for Location and Equipment fields, or the “entity browser” widget like @paul121 described.
So “easiest” solution to your problem (without requiring new code) would be to use one of those two for the Location/Equipment fields. Neither of those choices are perfect though, I agree. Both are more tedious than Ctrl+click like you described @graffte.
The “best” solution, in my mind, would be to offer users the ability to “switch widgets”… so you could switch to a select field, or an autocomplete, or an entity browser, depending on which works best in the moment. This doesn’t exist, of course, but I’ve always thought it would make for a really nifty Drupal contrib module (not specific to farmOS, but used by farmOS).
That might be longer term (unless someone wants to sponsor or build it for us!) so maybe we should focus on a short-term solution first.
@graffte do you think changing the Location and Equipment fields to “entity browser” widget would be better for you? To see what that looks like, just look at how the existing Asset field works.
Maybe you’ll decide that “entity browser” is too complicated for those fields, and the existing “autocomplete” is the least bad existing option… that’s basically the decision I came to early on in the farmOS v2 development process, and left it at that. 
I do think having a “select” widget would be really useful - and maybe it does make sense for that to be the default for Location and Equipment fields, like it was in farmOS v1! I think in most cases that would be the best.
There are cases where it doesn’t work, though… and we have run into that with some users. Especially where there are LOTS of assets involved. That’s another reason why we went with “autocomplete” as the default in v2. But I agree, it might be a bit of a step backwards for most users (again why a “widget switcher” would be awesome!)
Lots of considerations to balance! 
There are a lot of terms and options being thrown around. So for the most part, I’m trying to read through the message string and figure out “what are they talking about”. "the UI for adding assets to a log that opens a modal for searching and selection a few assets in bulk (this is called the “Entity browser” widget) “Entity” what? So it’s tough to provide specificity in my response because I’m trying to mentally picture the various scenarios that I don’t have terminology to describe or sufficient familiarity to compare.
At a high level for any situation where I need to pick out several items (3 to 5) from a list of many (say 50+), I want the list to “pop up” or otherwise be visible, within which I can select the few items in one entry operation. The list view needs to be presented in a way to allow scrolling or other means to find the items that are probably not going to be visible in one screen. Click “enter” and have them show up in my log entry in the correct field. In V1, a list popped up, I scrolled through the list, I could CNTRL Click to select multiple items on the list, hit enter(or whatever the button was called), and 2, 3, 4, 5… items got entered into my log entry. The Owners and Catagory selection boxes kind of work like this although the tiny scroll window maybe not good for big lists. In V2, I have to cycle through the “Add another Item” one at a time log entry input loop while I wait through a couple seconds of network/server response lag time for each. I can’t tell you what the technical solution should be, but I do know that the current implementation is really slow and inefficient. Multiple this by 10 or more log entries, and you see hours of your life go by.
Digression… Considering the Owners selection box above… In V1, it just defaulted to me and no selection required. In V2, I now have to select myself every time I make a log entry. It’s just another log entry field to manage, that constantly gets forgotten, and requires me to come back and edit/fix. Is there some sort of way to set up a default for this field other than NONE?
I’ll keep coming back to this. It takes a lot of hours of time to keep the database fed. Time is my most valuable and scarce commodity. Getting the log entry time and effort much lower needs to be a constant development priority. Not sure how to accomplish it. Every database system fights the problem. User time efficiency could be a FarmOS differentiator. I’m convinced it is the number one adoption issue for most rank in file non-techy farmers.
Yea sorry about that @graffte - we’re all a bunch of nerds here who dive right into the nitty gritty details. So you’re coming with us ha! 
Real quick intro to “entities” and “widgets” because that might help: “entities” are basically any kind of “record” in farmOS. Assets and Logs are different types of entities. Logs have “entity reference” fields on them, which are basically just a way to say “this log is linked to these other entities”. The “Assets”, “Equipment”, and “Location” fields on Logs are all entity reference fields. Different “field widgets” provide different ways to select the entities you want to reference. Currently the “Assets” field uses an “entity browser” widget, and the Equipment and Location fields use an “autocomplete” widget.
So when we ask “should we use an entity browser for all entity reference fields?” we mean: “should the Assets, Location, and Equipment fields all work the way that Assets currently does?”
It sounds like maybe the “entity browser” would be worth a try. That is basically how it works. You can see for yourself how it would work by adding assets to the “Assets” field. Give that a try (if you haven’t already) - what do you think about that solution? Would it help?
Oh this sounds like a bug… it should be automatically filling in the current user when you are creating a new log, just like it did in v1. I will take a look at this and open up a new bug issue if it’s not working correctly. Thanks for the heads up.
Couldn’t agree more! And we are tasked with the impossible challenge of solving this.
Appreciate the time you’re taking to think this stuff through. 
I took a look, and we do in fact have logic to automatically set the “Owner” of logs to the user who created it… but it happens when you save the log, and only if there are no other Owners assigned. So if I go to “Add log” and just scroll down to the bottom and click “Save”, I can see that I have been assigned as an Owner.
In other words: if you just leave that field blank when you create a log, it should assign it to you automatically. If that’s not happening, let me know.
Maybe if the field was prefilled with the current user, it would be easier to know this.
2 Likes
Yea we talked about a similar thing w/ the auto-population of log geometry, which currently happens when a log is saved as well (but doesn’t show in the form UI). The logic that exists now works for both UI-generated and API-generated records. If we want to pre-select in the UI as well that will need to be added in addition to the existing logic, so that API-generated records still get them auto-assigned.
My mistake on the Owner default. I ran a few test log entries. Appears to work as you describe. Which leaves me scratching my head a bit because I’d swear I had log entries where the owner didn’t get assigned. Will monitor and see if I see a situation.
1 Like
Beneath the owner selection it says:
Owner
1 a
2 b
Assign ownership to one or more users.
Maybe something like could work:
Change owner
1 a
2 b
Assign ownership to one or more users.
Current user is default.
1 Like