| [23:16:39] | * user123 has joined #farmos |
| [02:21:16] | * farmBOT has joined #farmos |
| [03:04:35] | * EMC has joined #farmos |
| [05:34:43] | * EMC2 has joined #farmos |
| [05:42:51] | * EMC has joined #farmos |
| [05:44:54] | * EMC2 has joined #farmos |
| [05:52:08] | * EMC has joined #farmos |
| [05:55:49] | * EMC2 has joined #farmos |
| [06:02:01] | * EMC has joined #farmos |
| [06:06:20] | * EMC2 has joined #farmos |
| [06:10:53] | * EMC has joined #farmos |
| [06:16:15] | * EMC2 has joined #farmos |
| [06:21:26] | * EMC has joined #farmos |
| [06:25:44] | * EMC2 has joined #farmos |
| [06:32:02] | * EMC has joined #farmos |
| [06:39:34] | * EMC2 has joined #farmos |
| [06:41:41] | * EMC has joined #farmos |
| [06:56:01] | * EMC2 has joined #farmos |
| [08:57:03] | <Greg[m]> | hmmm... yeah, I see the issue. I think at a minimum, it would be nice to list all files associated with a farm, and have some type of 'type' field, and have the ability to download them... that actually covers a lot. It looks like organization--farm already has a file relationship possible... so it's just a matter of creating the page at that point. |
| [08:58:07] | <Greg[m]> | <mstenta[m]> "> Another option is to store the..." <- ha me neither... but it feels almost inevitable. Talked with Serena and others about he workflow.. the crux is a quickform gives you a custom view to see and make things in a more intuitive way |
| [08:58:48] | <Greg[m]> | Greg[m]: but once it's submitted... it's hard to get that intuitive view of the quickform back... now you're in farmos db land with assets and logs and linkages that aren't very intuitive for, for example, a farmer who's interacting with this form once a year and doesn't have farmos |
| [09:00:23] | <mstenta[m]> | Greg[m]: Relevant issue: https://www.drupal.org/project/farm/issues/3336484 |
| [09:01:18] | <mstenta[m]> | Yea we're not far off |
| [09:01:19] | <Greg[m]> | mstenta[m]: So the workflow I'm considering is:... (full message at <https://matrix.org/oftc/media/v1/media/download/ARjjd95SNUA-PWfg-XJn-KRL...) |
| [09:01:23] | <Greg[m]> | Greg[m]: that'st he idea at this point, anyway |
| [09:01:24] | <mstenta[m]> | Two things: |
| [09:02:10] | <mstenta[m]> | 1) re: "type" we have mime type, but not a concept of "file bundles" (aka different fieldable bundles of the file entity type) |
| [09:02:22] | <Greg[m]> | Greg[m]: 100% - that is exactly the issue. I would propose it's too complicated to say 'I want to backwards load a quickform from something I did XXXX time ago'... that sounds like dependency hell |
| [09:02:49] | <Greg[m]> | Greg[m]: but at least having a draft-worthy format that may live for minutes-hours-days feels achievable |
| [09:03:41] | <mstenta[m]> | 2) the Files field on organization entities probably isn't what you want for that... instead it would be better to either a) show a list of all files attached to asset/logs associated with an org, or b) the ability to reference an org directly from file entities |
| [09:04:28] | <mstenta[m]> | The former would be possible with existing data model, but the latter would be nice for associating files with orgs without having an asset/log (yet) |
| [09:05:28] | <mstenta[m]> | Greg[m]: Ah so maybe a "draft" quick form concept? :-) |
| [09:05:37] | <mstenta[m]> | mstenta[m]: That's another idea that came up before |
| [09:06:58] | <mstenta[m]> | mstenta[m]: But yea it's probably going to be hard to load multiple records back into a quick form after submitting, because we don't currently have a way of knowing "these were all created from the same submission" (other than using the created timestamp on the records perhaps) |
| [09:07:36] | <mstenta[m]> | mstenta[m]: I've mostly been thinking about simpler quick forms I guess (with regard to reloading) |
| [09:08:19] | <mstenta[m]> | mstenta[m]: The core quick forms are pretty simple in that regard... only creating 1 record in most cases |
| [09:08:45] | <mstenta[m]> | mstenta[m]: Or multiple easily linkable records (like planting and birth forms) |
| [09:09:43] | <mstenta[m]> | mstenta[m]: But it sounds like you're thinking more about the "tabular" form idea, which makes a lot of loosely related records... harder to find/reload those probably |
| [11:32:48] | * user123 has quit () |
| [14:15:52] | <FredtheFarmOSBot[m]> | Mike — PR is up: https://github.com/farmOS/farmOS/pull/1079 (drupal.org issue #3590314). Same branch you skimmed, just amended the commit message with the issue ID. Note: the branch + PR were drafted by Claude with my direction and review. Ready when you are. |
| [14:16:44] | <FredtheFarmOSBot[m]> | @mstenta — PR is up on behalf of Greg: https://github.com/farmOS/farmOS/pull/1079 (drupal.org issue #3590314). Same branch you skimmed; commit message amended with the issue ID. Ready for review whenever you have time. |
| [14:18:59] | <Greg[m]> | <mstenta[m]> "2) the Files field on organizati..." <- yes... that makes sense... show list of assets logs associated with an org. ... that's a bit counterintuitive... but honestly I think there's an intuitive need to have more logs for 'interactions' (similar to a traditional cms), certainly for these multi-farm instances the need is there. Then in an interaction, you can associate it with a farm, attach files, etc. Then the accumulation of |
| [14:18:59] | <Greg[m]> | all documents 'up' to the org automatically feels realistic. |
| [14:21:13] | <Greg[m]> | Greg[m]: do you / did you ever create the concept of an... interaction? Or whatever it's called in a cms? Looked it up... says "customer interaction data" |
| [14:21:15] | <Greg[m]> | Greg[m]: icky |
| [14:21:21] | <Greg[m]> | Greg[m]: maybe we can find something better |
| [14:28:43] | <mstenta[m]> | <Greg[m]> "maybe we can find something..." <- Ah you mean like a CRM? |
| [14:28:53] | <mstenta[m]> | mstenta[m]: (Contact relation manager) |
| [14:29:32] | <mstenta[m]> | Thanks Fred 😆 |
| [14:30:24] | <Greg[m]> | mstenta[m]: yeah, sorry crm |
| [14:30:53] | <Greg[m]> | Greg[m]: some of the feedback we got from the CP world was to store that kind of interaction data in farmOS as well... which in theory is a very simple log |
| [14:31:00] | <mstenta[m]> | Greg[m]: Interaction log makes sense for that! |
| [14:31:27] | <Greg[m]> | mstenta[m]: probably a custom one, just for sorting sake, but very simple. And you can link files (like the transcript or mp3 or whatever) there... associate that with the farm |
| [14:31:35] | <mstenta[m]> | Greg[m]: Natural next step. We talked about Orgs being the first step for CRM functionality potentially |
| [14:31:43] | <Greg[m]> | mstenta[m]: 100% |
| [14:31:45] | <mstenta[m]> | Greg[m]: Also need a Contact entity probably |
| [14:31:53] | <Greg[m]> | mstenta[m]: (?) what's that? |
| [14:32:13] | <mstenta[m]> | Greg[m]: Representing an individual contact at an org |
| [14:32:21] | <mstenta[m]> | mstenta[m]: Most CRMs have that separation |
| [14:32:50] | <Greg[m]> | mstenta[m]: mmmm... right, so you can say "I talked to Bob" and Bob is an entity |
| [14:33:13] | <mstenta[m]> | Greg[m]: Yea |
| [14:33:22] | <mstenta[m]> | mstenta[m]: Relevant Drupal modules: |
| [14:34:03] | <mstenta[m]> | mstenta[m]: https://www.drupal.org/project/redhen |
| [14:34:16] | <mstenta[m]> | mstenta[m]: https://www.drupal.org/project/crm_core |
| [14:34:25] | <Greg[m]> | mstenta[m]: yeah... that's probably good info. I mean, it's all gravy at least in these first use cases, but I could imagine org > contact(s). Then the relevant contact list is on the 'customer interaction' (so it's already farm-filtered). |
| [14:34:30] | <mstenta[m]> | Greg[m]: https://www.drupal.org/civicrm |
| [14:34:47] | <mstenta[m]> | mstenta[m]: Not suggesting we use those... but for reference |
| [14:34:58] | <Greg[m]> | mstenta[m]: Also - we learned that without context, it's super duper hard for LLMs to understand or parse these open ended conversations. So having actual known contacts in the db actually helps interpretability and accuracy in a real way |
| [14:35:15] | <mstenta[m]> | Greg[m]: Interesting |
| [14:35:32] | <Greg[m]> | mstenta[m]: same for other lists (field names, planting names, crop names, etc. etc.) |
| [14:35:47] | <Greg[m]> | Greg[m]: if it can't look at the db and find what the hell someone's talking about, it just ends up way in left field |
| [14:36:17] | <mstenta[m]> | Greg[m]: Makes sense. Same as people talking about stuff :-) |
| [14:36:31] | <Greg[m]> | mstenta[m]: haahah, exactly. LLMs are almost as bad at making things up as actual farmers |
| [14:36:40] | <mstenta[m]> | Greg[m]: Like all the various acronyms for orgs 😆 |
| [14:37:08] | <Greg[m]> | mstenta[m]: oh god... the conservation planner space is a wasteland of acronyms |
| [14:37:24] | <mstenta[m]> | Greg[m]: All of ag seems to be haha |