IRC logs for #farmOS, 2026-05-26 (GMT)

2026-05-25
2026-05-27
TimeNickMessage
[09:23:15]<Greg[m]>ACTION uploaded an image: (208KiB) < https://matrix.org/oftc/media/v1/media/download/AW6xBrUxIunp93aJ1AhDWnkq... >
[09:24:31]<Greg[m]>I have a thought (maybe worth a forum post, maybe not...). I'm working on the quickforms and quickform plans work, nearing an update to share, but a small feature I felt may be worth just directly pushing upstream is to add Plans as a tab in the main Organizations page. See example image. Just imagine if next to Assets and Logs there was also Plans. This is helpful for my application (and maybe others) to see all active (or in process or
[09:24:31]<Greg[m]>whatever) plans associated with an organization. Is this an easy win to offer back to the organizations module? Or should I just implement myself and create an issue? or maybe forum post for more discussion if there's more to be said about it? Curious of thoughts.
[09:31:00]<symbioquine[m]>It seems like a good idea at a high level!
[09:31:00]<symbioquine[m]>Just to make sure I'm understanding: to build the contents of such a such a tab, it would need to look up which assets are associated with the organization, then look up the set up plans which reference those assets?
[09:32:31]<mstenta[m]>Greg: I actually needed something similar for the RCD module! My first inclination was a tab as well... but I ended up taking a simpler route...
[09:33:19]<mstenta[m]>ACTION uploaded an image: (103KiB) < https://matrix.org/oftc/media/v1/media/download/Af0X6kvY4EDla3I_W7hPD3PF... >
[09:33:35]<mstenta[m]>... of just creating a custom View and embedding it in the organization page itself.
[09:34:09]<mstenta[m]>I think a tab would be better... and I left that option open for farmOS core to consider providing...
[09:34:28]<mstenta[m]>The tricky thing is: there is no standard core data model that enables it.
[09:34:43]<mstenta[m]>symbioquine alluded to this above
[09:35:02]<mstenta[m]>In the RCD module, we have a custom plan type, and the plan references organization entities directly
[09:35:55]<mstenta[m]>But that is not a standard across plan types generally, so there's no way for farmOS core to provide a standard View built on that assumption
[09:36:29]<mstenta[m]>> Just to make sure I'm understanding: to build the contents of such a such a tab, it would need to look up which assets are associated with the organization, then look up the set up plans which reference those assets?
[09:36:29]<mstenta[m]>Even this isn't possible, because there isn't really a standard way for plans to reference assets...
[09:37:11]<mstenta[m]>There is a default asset field on plan entities, but modules that provide plan types can choose not to use that... Both the crop plan and grazing plan modules do not use that, for example.
[09:39:24]<mstenta[m]>Ultimately, I think the right approach would be for farmOS core to provide some way for modules to declare that records are related to plans, and then we could display something generic on those records, like a box that says: this record is part of these plans...
[09:39:48]<mstenta[m]>paul121 started working on that in this PR: https://github.com/farmOS/farmOS/pull/904
[09:39:52]<symbioquine[m]>Somehow I thought there was also a asset/log field on PlanRecord entities, but I'm not seeing that now... is that only on bundles thereof?
[09:40:46]<mstenta[m]>Nope - the only standard field on a plan_record entity is plan (to link it to a Plan)
[09:40:57]<mstenta[m]>It's up to downstream modules to provide bundles with additional fields
[09:41:15]<mstenta[m]>So for example, the Crop plan provides a crop_planting bundle with a plant asset reference
[09:41:29]<mstenta[m]>And the Grazing plan provides a grazing_event bundle with a movement log reference
[09:41:39]<mstenta[m]>All other relationships are inferred from those
[09:42:51]<mstenta[m]>Greg: Here is the code I use to embed the custom View into the Org page... in case you want to do something like that in the meantime... https://github.com/farmier/farm_rcd/blob/f58bbb670d1fc1591e3d9f23da9d579...
[09:43:18]<mstenta[m]>And here is the View: https://github.com/farmier/farm_rcd/blob/1.x/config/install/views.view.f...
[09:43:53]<mstenta[m]>That View is specifically configured to look for a farm field on farm_rcp plan bundles, though. So you would have to create your own based on your data model.
[09:50:19]<mstenta[m]>Curious if AI can create Views config... I would actually be pretty impressed if that worked, but I probably wouldn't trust it to do a good job. Views are easy enough to create manually through the UI so that would definitely be my recommendation.
[09:55:17]<mstenta[m]>(I wouldn't trust it because Views configs are essentially just huge YML files with a very specific schema. The schema itself is provided by many separate modules, and if anything is incorrect then it will be marked as "overridden" constantly at best, and completely broken at worst. My guess is the AI would do a great job at making YML that looked right, but all the little "gotchas" of it would create a long tail of things that needed to be
[09:55:17]<mstenta[m]>fixed. And creating the View via UI is just really fast and easy to do manually once you know what to do.)
[09:56:10]<mstenta[m]>(I don't even trust a human copying and pasting View YML config and modifying it manually.)
[09:56:43]<symbioquine[m]>On the other hand, you have a pretty good oracle to see if it did it correctly right?
[09:59:06]<symbioquine[m]>(At least for some of the cases that aren't too hard to create through the UI. That obviously wouldn't translate to correctness when used to produce more obscure configurations.)
[10:00:26]<mstenta[m]>What oracle do you mean?
[10:00:58]<symbioquine[m]>I mean you can make some configurations via the UI and compare/diff them with what "AI" creates.
[10:01:11]<mstenta[m]>Oh yea
[10:01:29]<Greg[m]>mstenta: well... we're about to find out :) would be great to get a review on this code once I'm done-ish. Those are the kinds of details I'm blind or ignorant to, and maybe we can add a lot of that in the agents.md file that we learn so we don't repeat those mistakes.
[10:01:39]<symbioquine[m]>I wouldn't actually be surprised if it's pretty good for simple configs, but I'd expect it to get subtly worse and worse the trickier they get.
[10:01:53]<mstenta[m]>I think it boils down to: Views config YML is very deterministically generated through the UI
[10:02:12]<Greg[m]><symbioquine[m]> "It seems like a good idea at a..." <- well, I think the plans are also directly associated with an organization (or at least in the modules I've created they are... that may be an add on I've done... not sure)
[10:02:18]<mstenta[m]>Yea, and Views configs are silly big
[10:03:05]<Greg[m]>mstenta[m]: Hmmm... yeah mike... maybe the right answer is just improving that org front page... that's probably right actually
[10:03:22]<mstenta[m]>> well... we're about to find out :)
[10:03:22]<mstenta[m]>Greg: Cool! Do you mean you're trying to create the "Plans" tab?
[10:03:46]<Greg[m]>Greg[m]: I think a 'landing page' per org is needed for many things... like "what are the current list and status of plans?", "what are the activities or tasks needed now", etc etc.
[10:04:03]<Greg[m]>Greg[m]: so maybe this is the first step in that... need more thought but yeah I like it
[10:04:15]<mstenta[m]>One caution there might be: if we do decide to add that in farmOS core, then your module will conflict with that. Although it probably won't "break" anything... it might just override the core route, or vice versa.
[10:04:32]<Greg[m]><mstenta[m]> "In the RCD module, we have a..." <- yes, that's what I do. I think it makes a lot of sense to do that
[10:05:01]<Greg[m]><mstenta[m]> "But that is not a standard..." <- Why? Since organizations is part of core now... is there a good reason now to do that? It seems that plans logically would very often (if not almost always) be by organization, no?
[10:08:21]<Greg[m]>Yeah... I'm realizing in this conversation that it would be cool to review the data structure I've created... because firstly... I know it at a conceptual level but haven't dove in as far as I should have, but also it needs to be reviewed more broadly as to the 'why'...
[10:08:46]<Greg[m]>maybe at a weekly call or something. Also, mike we do have some funding for review with Pasa, and this may be worth doing
[10:09:54]<Greg[m]>The repo is here btw... I have two major branches unmerged so maybe want till EOD if you want to see current, but just FYI at least. When I'm at a stopping point, I'll share so folks aren't looking at old or messed up stuff --> https://gitlab.com/our-sci/farmos-soil-health
[11:12:13]<Greg[m]><mstenta[m]> "> well... we're about to find..." <- I don't know... again, we're in this weird world where I don't know exactly the code I'm making... it'll be like inventing a new animal and then assigning a doctor to investigate what's inside. You can see it walk around... but does it have bones... nobody knows!!!! :) weird.
[11:45:21]<Greg[m]>Hmmm... did a little walk through on this issue, and indeed there is a big View which was effectively hard coded. Reviewed it (and other) items which aren't validated against the schema files for building Views and things, and... (full message at <https://matrix.org/oftc/media/v1/media/download/AcneloAanIzb0isigEgLuDRh...)
[11:55:24]<Greg[m]>(3 makes sense to me... but I'm not familiar enough with the background or history to be confident)
[13:26:49]<mstenta[m]>Option 4: build the View manually in the UI 😄
[13:27:26]<mstenta[m]>Not worth it to have an agent write it IMO
[13:28:41]<mstenta[m]>Redirect a little of the time spent honing agents into learning some basic Drupal site builder skills and you'll be unstoppable Greg!!