I was wondering if anyone had thoughts on handling variety information. For example in Apples:
Colour: Red
Bloom Time: Early
Bloom Colour: White
Brix: 25%
Usage: Cooking, Fresh Eating, Cider
This usually goes in taxonomy but I would need multiple custom fields essentially. Could this be done in a custom module? How might that be used in assets? Ultimately I’d like to be able to sort assets by that data.
The bigger picture here is that I’d like farmOS to be my Nurseries Inventory, Crop Planning and Log System. I think this would require a web app or many quick forms to make it happen.
Yes! But you can also just add fields to your own instance without putting them in a module.
The main reason to package them in a module is to share with others, or to integrate with other functionality.
The module would basically add the fields to the plant_type taxonomy terms, in the same way that the core harvest_days, maturity_days, etc are added.
These are added as Drupal “config entities” that define the field storage and field configuration. The process would basically be:
Enable the field_ui module.
Create the fields you want via the Drupal Field UI (there are plenty of tutorials on this on the web).
At this point, the fields exist on your farmOS instance. To put them in a module, you would:
Export the “field storage” and “field” configuration entities as YML files and remove the uuid information from them.
Place these files in a config/install directory in a module (add a [module-name].info.yml file if it’s a new module, as described here: farmOS module development | fa
Share your module!
Tips:
I always recommend doing stuff like this in a development copy of your instance first, and package changes into a module that you then install on your “live” instance. This avoids a lot of the risk of breaking your live database, which can be a pain to undo, or catastrophic if you aren’t keeping proper backups (you ARE right??? )
Think hard about what you are going to call the fields, so they don’t potentially conflict with future fields that farmOS core itself might add. A safe way to avoid future conflicts is to add a custom namespace to them. For example, instead of calling the field colour, call it mycustommodule_color (where mycustommodule is the name of your module).
It might make sense to define some of the fields you mentioned (eg: Bloom Time and Usage) as list_string type (where you define a set list of options to choose from), or taxonomy term reference fields (where you also provide a vocabulary and let users define their own list). There are advantages/disadvantages to both - I’d probably start with list_string to keep it relatively controlled, and only move to taxonomies if the extra flexibility is needed.
How might that be used in assets? Ultimately I’d like to be able to sort assets by that data.
Check this out - we recently added the ability to do this: Fields | farmOS
You basically just need to add a mycustommodule.module file with a single PHP function to tell farmOS about your new fields, and they will auto-magically be added to Views (the asset list with sort/filter). Note that it doesn’t support all field types, though… but text, number, and taxonomy term reference fields should work.
Cool! Documentation for quick form development is here: Roles | farmOS
)