I’m developing a tool using Node-Red to synchronize my cattle assets with the DAFM through an API provided by ICBF. These are Irish entities but I’m sure it could be easily modified for other similar databases using an API.
Importing new animal-assets and archiving old ones which have left the herd is working and now I’m working on a way to generate new logs to match these movements, the idea is to create either a birth log or purchase log for new animal-assets and either a sale log or death log for archived animal-assets.
@mstenta , I’ve a question on recording animal parentage of purchased animals which I should probably get straight before committing too much more code, how are parents of purchased animals or AI bulls recorded in farmOS? or are they? Basically I’d like to add parents which are not my assets to assets that are.
Create animal assets that represent the parents, and reference them in the child’s “Parents” asset reference field. These assets could be immediately archived, so they are only in the system for reference.
Simply record their parentage information in the child animal’s “Notes” field.
It may depend on what you want to be able to do beyond that… if there is any value in being able to record additional information about the parents (documents etc), then having separate assets might be useful. It also allows you to go further backwards, if you wanted to keep some kind of local record of lineage (parents’ parents etc). Of course, most of the time this is probably overkill.
This was my first thought but archived animals are important to me too for tracking sales or on farm deaths, not sure I’d want to add these additional animals in this way. I suppose they could be filtered with a “for reference only flag”.
I was also considering this and it may be the simplest option, but it lacks consistency between animals born to on farm parents and imported animals or animals sired by an AI bull.
I suppose the biggest issue is that I may not know yet all that I’d like to do with this, but I know getting it right in the beginning may be easier than trying to retrospectively fix it. The ICBF database contains a lot of detail on each of my animals including weights, generations of lineage and genomic data as I send samples from all breeding animals to them. Ultimately it may be easiest to leave the lineage data with ICBF and use Node-Red to pull data from both farmOS and ICBF when generating any reports that require that level of detail but I thought I’d check if anything similar was already delt with.
Separate Assets? as in a custom Asset like asset–reference_animal? That could be a nice solution, would there be much of an issue with allowing the parents field to use 2 types of asset? as in asset–animal and asset–reference_animal using a custom module without interfering with the core?
Oh probably, I think I’ve gone way past that already for the size of my farm anything past a notebook and pen is probably overkill.
I would be curious to drill into this a bit. Can you accomplish “tracking sales or on farm deaths” in a more specific way, I wonder? If so, having the additional archived animal assets wouldn’t interfere with that. Perhaps that’s the right nut to crack… ?
Creating a new asset type works too! Acknowledging that this will probably always be a custom solution you need to maintain moving forward…
I might just create new “ ICBF parents ” field
FWIW the parent field on assets can reference any asset type - not just assets of the same type as the child. So you don’t necessarily need a separate reference field, unless you find having it separate is helpful.
I created a new Asset type Reference Animal and 2 new log types Animal Sales and Animal Deaths. I know I could just have used a Harvest log, but I wanted clearer log types for any Department of Ag inspections.
I also discovered a typo can really break the site , I presume there is a way to uninstall a module if you loose access to the UI? I presume drush pm-uninstall [modulename]? Thankfully my test environment is a VM with a snapshot taken before I made changes.
Yes generally drush pm-uninstall [modulename] and drush cr will fix things - but it’s a good lesson: never test changes on production! I’ve spent too many hours cleaning up messes that could have been prevented with proper process.