| [03:21:51] | * EMC has joined #farmos |
| [03:27:20] | * EMC2 has joined #farmos |
| [03:35:26] | * EMC has joined #farmos |
| [05:28:29] | * EMC has joined #farmos |
| [09:25:04] | <mstenta[m]> | Greg[m]: This looks pretty good Greg! I haven't tested it, but looks good enough to start a PR. |
| [09:25:59] | <mstenta[m]> | mstenta[m]: Opening a PR will also run our other automated tests, along with the new one this change adds. |
| [09:26:26] | <mstenta[m]> | mstenta[m]: Looks like it followed the pattern correctly, though, at quick glance! |
| [09:32:46] | <mstenta[m]> | <mstenta[m]> "Looks like it followed the..." <- (And if you still have the prompt you used to generate this, please include that in the PR!) |
| [09:37:03] | <symbioquine[m]> | mstenta[m]: I suspect it would be more of a back-and-forth transcript than a one-off prompt... |
| [09:37:16] | <symbioquine[m]> | symbioquine[m]: I'd also love to see that though. |
| [09:59:06] | * EMC has joined #farmos |
| [10:00:55] | * EMC2 has joined #farmos |
| [10:14:37] | * EMC has joined #farmos |
| [10:21:29] | * EMC2 has joined #farmos |
| [10:25:40] | * EMC has joined #farmos |
| [10:33:53] | * EMC2 has joined #farmos |
| [10:42:11] | * EMC has joined #farmos |
| [12:01:50] | <symbioquine[m]> | farmOS dev call on now - all are welcome! https://meet.jit.si/farmos-dev |
| [12:01:53] | <mstenta[m]> | farmOS dev call right now - all are welcome! https://meet.jit.si/farmos-dev |
| [12:52:38] | <mstenta[m]> | Exciting discussion in the dev call today about a potential "file-first" approach to initial data capture in farmOS! (cc paul121) |
| [12:53:43] | <mstenta[m]> | I've been using an audio recorder app on my phone to take quick voice notes... thinking about workflows that start there and then spin off logs/assets in farmOS. |
| [12:53:58] | <mstenta[m]> | Very similar approach for photos, as well as machine data potentially... |
| [12:54:51] | <mstenta[m]> | An easy first step might be to add a "Records > Files" menu item, that shows all file entities, and allows you to add additional ones without linking them to assets/logs (yet). |
| [12:55:37] | <mstenta[m]> | We talked about adding a "Flags" field to file entities, so we could use the "Needs Review" flag perhaps - as a way of knowing which ones are "raw data" that still need to be processed/linked to other records. |
| [12:56:16] | <mstenta[m]> | Now that I'm investigating options, it may make sense to finally consider the Media module that is included in Drupal core: https://www.drupal.org/docs/8/core/modules/media |
| [12:56:52] | <mstenta[m]> | (paul121 talked about the Media module a long time ago...) |
| [12:57:48] | <mstenta[m]> | It would allow us to create "bundles" (eg: Image vs Audio) and add additional fields - and it provides more granular access control than the core File entity does, if I understand correctly... |
| [13:00:33] | <mstenta[m]> | Either way... the basic idea might be something like this: you capture files (images, audio) during while you're working and send them to farmOS (eg: via asset link or the farmOS UI itself), then "process" them later when you have time. The "process" step might be as simple as: go to "Records > Files" in farmOS, see a list of files that need review, bulk select related ones and select a bulk action like "Create log" that would drop you into |
| [13:00:33] | <mstenta[m]> | a log edit form with those file entities already referenced. |
| [13:02:00] | <mstenta[m]> | Of course, that's only the "simple" approach... there could be more complex processing, too... maybe outside of farmOS (via API). For example: voice to text or optical character recognition, parsing w/ LLMs, etc etc. |
| [13:02:35] | <mstenta[m]> | That's a whole world of discussion/experimentation itself... |
| [13:02:58] | <mstenta[m]> | But the "file first" data entry workflow would lower the barrier to getting "raw" data into the system as a first step. |
| [13:07:14] | <symbioquine[m]> | We do it today with a channel on our private matrix server where we write stream-of-consciousness records of what we're doing that I manually convert into logs. |
| [13:07:39] | <mstenta[m]> | I do it with voice recordings, emails to myself, and photos. |
| [13:08:09] | <mstenta[m]> | So really what we're talking about is just formalizing that part of the workflow inside farmOS itself |
| [13:08:37] | <mstenta[m]> | To make the initial capture as easy as possible, and then to provide tooling to "process" (aka create logs etc) |
| [13:10:30] | <mstenta[m]> | <mstenta[m]> "Now that I'm investigating..." <- Looks like media entities also store revisions |
| [13:11:00] | <mstenta[m]> | I'm testing out the module locally to see how it works... and if there is any weirdness... |
| [13:11:25] | <mstenta[m]> | (eg: Media entities have a "published" status, just like taxonomy terms... which is a bit weird and unnecessary in the context of farmOS) |
| [13:15:47] | <Greg[m]> | <symbioquine[m]> "farmOS dev call on now - all are..." <- awww shucks last meeting went long |
| [13:16:56] | <Greg[m]> | oh gee! This is part of what I wanted to talk about too, what a coincidence - crazy |
| [13:20:35] | <Greg[m]> | I wanted to allow for upload of documents, recordings, etc. to populate quickforms. I had questions about when and where those should be stored. I assumed relationships->file associated with every entity created when the quickform was completed. Another option is to store the quickform in it's own log (just to note that it was done and completed and a list of what it created). Another option is to store it at the farm level... and then a |
| [13:20:35] | <Greg[m]> | user can pick an item to pre-populate a form (like... a farmer loads 10 files / pds / etc when they onboard, and the TAP is filling out their records quickforms and selects one or more from those 10 files and then the auto-population pulls from them as context). Anyway, those are my thoughts so far but they are messy and probably would have been better listening to your conversation |
| [13:20:46] | <Greg[m]> | * etc. to auto-populate quickforms. |
| [13:32:40] | <Greg[m]> | <mstenta[m]> "So really what we're talking..." <- Mike - would you consider this also for storing information for the conservaiton planner? I know that document storage (mostly just 'having everything in one place' kind of thing). Seems like it would be useful |
| [13:32:47] | <Greg[m]> | Greg[m]: docs, pdfs, etc. |
| [13:33:39] | <Greg[m]> | Greg[m]: can you explain why Media versus just loading files and using the relationships -> files linkage? Like... what does the additional overhead or structure provide? |
| [13:34:28] | <mstenta[m]> | Greg[m]: These are all good questions that I don't have answers to yet :-) |
| [13:37:27] | <mstenta[m]> | mstenta[m]: I also want to be careful about becoming Google Drive (or trying to replace general purpose file storage) |
| [13:38:03] | <mstenta[m]> | mstenta[m]: If there is real widespread demand for that, maybe. But I haven't heard that from anyone yet. |
| [13:38:35] | <mstenta[m]> | mstenta[m]: But we can take some first steps that can be expanded on in the future if necessary |
| [13:39:53] | <mstenta[m]> | mstenta[m]: Re: Media entities... I'm just starting to explore this module... my initial gut is still that it's not what we need... but it might provide some things we do need, like access control... |
| [13:40:42] | <mstenta[m]> | mstenta[m]: The out of the box UI is a step backwards from what we have now though... it adds a layer of complexity that I would prefer to hide |
| [13:43:45] | <mstenta[m]> | > I wanted to allow for upload of documents, recordings, etc. to auto-populate quickforms. |
| [13:43:45] | <mstenta[m]> | Yea this would be cool - but would probably be very specific to certain quick forms, and it sounds like you're assuming some kind of external processing too... eg parsing voice and filling in form fields. That is outside the scope of what we talked about, but could certainly be experimented with1 |
| [13:44:12] | <mstenta[m]> | > I had questions about when and where those should be stored. I assumed relationships->file associated with every entity created when the quickform was completed |
| [13:44:12] | <mstenta[m]> | Yea that would be my recommendation. |
| [13:44:59] | <mstenta[m]> | > Another option is to store the quickform in it's own log (just to note that it was done and completed and a list of what it created). |
| [13:44:59] | <mstenta[m]> | I don't really like this idea, but maybe there are contexts where it would be useful. |
| [13:45:41] | <mstenta[m]> | Worth noting: there is a hidden quick field on assets and logs that references the ID of the quick form that created them (if applicable). So you can easily get a list of entities created by a quick form. |
| [13:46:10] | <mstenta[m]> | (Note this currently only gets populated if you use the entity creation traits that the core quick form module provides) |
| [13:47:09] | <mstenta[m]> | > Another option is to store it at the farm level... and then a user can pick an item to pre-populate a form (like... a farmer loads 10 files / pds / etc when they onboard, and the TAP is filling out their records quickforms and selects one or more from those 10 files and then the auto-population pulls from them as context). |
| [13:47:09] | <mstenta[m]> | Yea, that's an interesting idea too... and means there would need to be a "Farm" reference field on File entities I think |
| [13:49:25] | <mstenta[m]> | It seems like the immediate challenge is that File entities may be too simple right now. |
| [13:52:21] | <mstenta[m]> | If we want to create a View of them (eg: in a Records > Files menu), we need to ensure that there is proper access control for those entities. Right now it seems that it's sort of all-or-nothing... meaning you can either see all files, or you can't. |
| [13:53:51] | <mstenta[m]> | The Media module adds a media entity type, which is another layer on top of file entities, and provides bundles and granular permissions... but it also adds a lot of additional complexity and changes the way we would need to think about files generally, I think, so that would be a much bigger undertaking, and likely a breaking change |
| [13:54:42] | <mstenta[m]> | > Right now it seems that it's sort of all-or-nothing... meaning you can either see all files, or you can't. |
| [13:54:42] | <mstenta[m]> | Maybe this is still valuable, though? And maybe we can do some minor extending of the core entity type to suit our needs... |
| [13:55:05] | <mstenta[m]> | But I foresee it naturally spinning out into a lot of follow-up requests |