It's running - what now?

[mstenta]

Thanks for this great write-up @ppetru! Always helpful to get detailed accounts of first time experiences/questions/ideas.

I’ll try to respond to specific points with suggestions/ideas for next steps…

@ppetru

The UI feels rather cumbersome. There’s a lot of clicking around and scrolling past fields I don’t use at the moment. The quick forms (I use the Eggs and Movement ones) help a lot, though.

This is true for a lot of use-cases, mainly due to the fact that farmOS is built to be as general as possible. It’s important to think about the current log/asset form UI as more of a “raw database editor UI” than a day-to-day data entry system. It’s a tradeoff, and assumes that over time folks will help to develop targetted UI/UX layers on top of the farmOS core server/data architecture. It’s an iterative and never-ending process, and we need your help!

Quick forms are a great place to start if you want to get your hands dirty with farmOS module development. We have some pretty good documentation for getting started with module development, and quick form development specifically, here:

farmOS module development

https://farmos.org/development/module/quick/

We’ve tried to reduce the amount of “boiler plate” as much as possible for quick forms. You can start with a single PHP file for your form, alongside the '.info.yml` file for the module itself. Ultimately, you will be working primarily with Drupal’s Form API, which requires some learning but is well documented around the web. Quick forms are basically just a thin wrapper around Form API. We automatically create routes/menu items/etc so you don’t need to do that.

Introduction to Form API

Another recent addition is the CSV importer framework. If you enable the CSV Import module, it will create some “default” importers for each asset, log, and taxonomy term type. These aim to hit 80% of use-cases. But you can also build completely customized importers yourself in your own module using Drupal’s Migrate API. This can be really helpful for bulk data entry if you find it easier to record things quickly in a spreadsheet and then upload it all at once less frequently. See our documentation here to get started:

CSV importers

Apart from Drupal/PHP module development, I want to emphasize that you can also build custom scripts/apps outside of farmOS, which communicate with it via API to push/pull data. We have Javascript and Python libraries to make this easier - so if you are more comfortable with those languages, the sky is the limit!

farmOS.js: Introduction | farmOS

farmOS.py: Introduction | farmOS

And of course, we always encourage sharing the things that you build, so that others can benefit or learn from them as well! I think there are a lot of custom solutions for farmOS data entry out there that no one sees because they haven’t been shared more widely. One of the reasons we created the farmOS Community Blog was to give the community a place to start sharing them! You can contribute your own blogs posts via this Git repository: GitHub - farmOS/farmOS-community-blog: Community blog posts hosted on the farmOS.org website

And if you want to chat with real folks using farmOS to hear how they are solving their own problems, jump into the chat room, or join the monthly community calls or weekly development calls.

This is all just to emphasize that we’ve not only invested a lot in the generalized data model and server architecture of farmOS to support building customized solutions on top, we’ve also invested a lot in community architecture and documentation to empower YOU to jump in! Now it’s up to you!

OK community plugs out of the way, back to some of your specific questions…

@ppetru

Here’s an example log entry where a clutch of ducklings were split into 3 groups (males to keep, males to harvest, females) – I wish there was some type and quantity checking to ensure no animals were lost, created, or turned into bags of feed:

and:

@ppetru

When logging inputs (bags of feed going to specific groups of birds), I wish the asset picker for the inventory decrement target would either filter or sort the asset list using the material type (i.e. don’t decrement the kilos of feed from an animal asset inventory or something equally absurd)

It sounds like you need a quick form (or other helper UI)! That is where such a layer of logic should live - not in the “raw” database edit forms themselves. There’s no way for the lower-level logs/assets to know what your intention is, but higher-level forms and UIs can provide more targeted workflows with the kinds of guardrails you’re imagining.

@ppetru

There’s no simple way to figure out how many animals I have. It seems like at least part of it is due to this issue. Ignoring the group inventory stuff, the only way I found was to go to the animal assets page and look for the “Displaying 1-X of Y” text at the bottom. Is there no better way to get a report?

Yea this is an annoying one, I agree, and would probably be really easy to add something to help do the calculation. Want to start a dedicated forum topic for this and we can start thinking through all the details? Some things we’ll need to think through include:

• Where would it be most useful to show this count?
• Should it be limited to animals, or would other asset types benefit as well?
• How does it work if the Group module is enabled/disabled?
• How does it work if the Inventory module is enabled/disabled?
• Does it make sense to figure out a “general” solution and include it in farmOS core? Or is this something that might be better off in an add-on module to start? farmOS core is more stringent (ideally has test coverage), and we need to make sure something for one use case doesn’t break someone else’s use-case. Custom/community add-on modules have more flexibility in that regard.

@ppetru

It looks like the group location logic only expands one level deep, so most of the birds end up with no location due to the nested group structure.

Ah interesting! It might make sense to open this up as a bug report, if you think it isn’t working the way that it should be. I forget exactly how that logic works, so I’d have to take a closer look. But certainly seems like it should work with multiple levels. Probably makes sense to split this off to it’s own thread. We usually reserve GitHub issues for bug reports, so feel free to open one and link to it here: Sign in to GitHub · GitHub

@ppetru

I suppose I could try to address some of the issues above – any advice regarding getting up to speed with Drupal development? There seems to be a nontrivial amount of boilerplate involved in even the simplest of modules.

Hopefully the farmOS module development documentation eases the learning curve for Drupal module development a bit. We’ve tried to focus on just the parts that are relevant to farmOS use-cases, without covering the full breadth and depth of what’s possible with Drupal (which is a lot)!

The other option, like I described above, is to build things outside of farmOS using whatever language you are most comfortable with, and communicate via the API.

@ppetru

What about running the more elaborate queries mentioned above? Is there some reporting module I should be using?
I suppose one could use the API or the database directly, although that seems overkill

Depends on what you want! I responded to the “animal count” one above, but if there are others let’s brainstorm! It might make sense to create dedicated forum topics for each, so they don’t get lost and we can stay focused.

I always like to think about things in a general way, so we can build features in farmOS core that are helpful to the most people. You can do anything you want in a custom module, though, including leveraging the power of Entity API to run queries and perform analysis within Drupal - or externally via API as you described.

If you have ideas for general purpose report building tools we can provide in farmOS core for users (UX) or even just for developers (DX), let us know!

@ppetru

Am I just holding it wrong? How do people use farmOS in practice? It would be useful to read about concrete case studies.

Not at all! We’re building this together, so I’m glad you’re part of the conversation now! Keep the ideas coming!