I have a question, right now in quantities there are 4 main fields:
measure
value
units
label
I’m finding that measure is not very useful, as I don’t have the need to compare across all volumes or all distances. If I do want to do that, I would use other libraries to merge common units together (in, cm, m, etc.) as needed, and in that case specifying a measure is kind of redundant. Basically, I think units covers the needs intended by measure.
Also, label is really nice, but it seems confusing given that almost all other objects in the system use name rather than label for basically the same type of information.
So I guess the questions are:
Why label and not just name? I would think that’s more consistent throughout the system
Is it possible to give another space for general tags? In my case, I am creating stir ratings in quantity, and want to also include the implement type (coulter_caddy for example) associated with each unique rating. I could have done a single activity with 3 implements, and want 3 stir ratings associated with each implement. This isn’t a material, so it doesn’t really work there. There’s better long term solutions (like storing stir ratings w/ the implement as a piece of equipment, and referencing the equipment), but something like tags would give a lot of flexibility to solve this and potentially other problems.
Not sure if discussions have happened around this, and I know exchanging label with name is kind of picky, but just posting to see what others think.
I think this is similar to the fact that for me, most of the time when I use label, I actually/also want a machine-readable value for collating/disambiguating the data.
Agreed, a robust unit system largely obviates the need for measure. Perhaps a big unit/quantity refactor could remove measure, but for now it’s there because it was there historically, and there is saved data in users’ databases.
It’s up to you whether or not you want to use measure in the meantime. All quantity fields are optional, so you can just leave it blank.
This is also somewhat historical (see the link in my previous comment) from when Quantities were “field collections” in farmOS v1, and this label carried through to farmOS v2 when we created the new quantity entity type. I personally think “label” makes more sense than “name” for quantities.
Anything is possible in a custom/contrib module!
A module can add new fields to any entity type, including quantities.
Proposing a new field to the core quantity entity type would be a bigger decision, but nothing’s stopping you from experimenting in the meantime!
I’m curious about the use-case for 3 stir ratings. My understanding is that most activities in a field would result in a single stir rating. But perhaps it is possible that you are pulling multiple implements or performing multiple steps in a singe pass eg: cultivating and transplanting. I see the value in recording each stir rating but maybe could be simplified to the “highest” stir rating? Could you clarify this use-case?
If these are separate activities, 3 separate activity logs would more accurately represent this.
@mstenta thanks for the context - I think it all makes sense in terms of how things got here. The system isn’t bad at all, just small things. I’ve considered pushing things to measure that aren’t int he dropdown list, technically possible via the api, but I think it kind of breaks the intent of that field. So now I’ll jsut leave it alone.
@Symbioquine yes - I think a label and name where one is machine and one is human readable is just always a plus.
@paul121 Pasa (as an example) wants to see the total rating - so 3 implements in a single pass could produce 3 stir values. This is actually super common - a single tractor pulling 2 or 3 implements in a row in a single pass (thus a single activity). IMO it’s valuable to the producer and to pasa to see each separately, so I’m not actively summing them - that’s easy to do later on. In a perfect world, I could tag each one associated with the implement… thus the tags :).
