IRC logs for #farmOS, 2020-11-20 (GMT)

[14:46:44]<symbioquine[m]>ACTION uploaded an image: 2020_11_20_seed_inventory_tool_and_image_stashing_demo.gif (7699KiB) < >
[14:55:04]<paul121[m]>neat way to upload images
[14:55:36]<paul121[m]>do you think the farmOS server could have that "stashing" functionality?
[14:55:51]<symbioquine[m]>I am using the farmOS server for that...
[14:55:54]<paul121[m]>(assuming this isn't all on a farmOS server)
[14:56:09]<symbioquine[m]>Depending how you think about it...
[14:56:25]<symbioquine[m]>It's at least "supported" by the current Drupal DB structure.
[14:57:13]<symbioquine[m]>I'm uploading the images to the `file_managed` table as temporary images.
[14:57:32]<symbioquine[m]>The images which are temporary and uploaded by the same user show up in the "stashed images" sidebar.
[14:58:35]<symbioquine[m]>The only fancy thing is using a websocket to make the new uploads show up in real-time.
[15:02:29]<paul121[m]>I tested the `entity_browser` module for D8 yesterday.. allows for advanced options/widgets when filling out Entity Reference fields in forms
[15:03:02]<paul121[m]>a QR code/stashed image widget would be neat for the File/Image reference on logs
[15:03:04]<paul121[m]>ACTION uploaded an image: entity_browser_example.png (60KiB) < >
[15:03:11]<paul121[m]>that is an example for the "asset" reference
[15:03:38]<symbioquine[m]>Yeah, it's best for "hybrid workflows" where most of the data needs to be entered from the computer, but photos or certain other measurements are easier to take from mobile...
[15:03:58]<paul121[m]>makes a lot of sense!
[15:04:02]<mstenta[m]>i don't quite understand what i'm looking at - but it looks AWESOME
[15:04:29]<paul121[m]>the phone gets the QR code so fast it's hard to notice :D
[15:05:16]<symbioquine[m]><mstenta[m] "i don't quite understand what i'"> It's a demo of the custom workflow I build for my organization to enter new "seed" assets including the source planting, inventory tracking, and a photo uploaded through a companion page from mobile.
[15:07:05]<symbioquine[m]>The most broadly applicable "innovation" is the way photos are taken, but the general concept of entering multiple data rows in a tabular format is one I've advocated for in the past when I demonstrated my custom "multi-planting tool".
[15:07:43]<mstenta[m]>so this creates a QR code, which you then scan with your phone, which opens a new page with a photo upload field, and then you can see that on the laptop again?
[15:07:48]<mstenta[m]>and link it to the log?
[15:08:40]<mstenta[m]>what information is contained in the QR code?
[15:09:10]<symbioquine[m]><mstenta[m] "what information is contained in"> Just a link to the companion page.
[15:09:31]<symbioquine[m]>The photos aren't linked to the seed asset until they are dragged onto the desired row and that row is saved.
[15:09:48]<mstenta[m]>ah cool!
[15:10:16]<mstenta[m]>great idea!
[15:19:04]<symbioquine[m]>ACTION uploaded an image: 2020_11_20_multi_planting_tool_geospatially_ordered_table.gif (1115KiB) < >
[15:26:17]<symbioquine[m]>ACTION uploaded an image: 2020_11_20_multi_planting_tool_tabular_planting_entry.gif (648KiB) < >
[15:29:48]<symbioquine[m]>Unfortunately a lot of this functionality is coupled to our concept of a seed asset for tracking specific accessions/varieties year-over-year, but bigger-picture I'd love to find a way to share it...
[15:33:13]<mstenta[m]>so cool
[15:33:49]<mstenta[m]>are you building any of these things in farmOS/Drupal modules symbioquine ? I forget if you said they were standalone apps
[15:36:26]<symbioquine[m]>Right now the "front-end parts" are written in Python Aiohttp + Vue, but the DB layer is compatible with farmOS/Drupal + a module or two to provide the custom asset types/fields.
[15:37:46]<symbioquine[m]>I've found it much faster to build/prototype that way, but I'm not opposed to trying to port the stuff back into the Drupal/PHP side eventually...
[15:37:54]<mstenta[m]>cool yea makes sense!
[15:38:29]<mstenta[m]>if you ever want a quick crash course in drupal module possibilities - happy to!
[15:39:15]<mstenta[m]>what does the python side do? database connection/queries mainly?
[15:39:33]<symbioquine[m]><mstenta[m] "if you ever want a quick crash c"> I'll definitely keep that in mind! :)
[15:40:05]<mstenta[m]>also: 2.x would be a fun place to start playing with decoupled apps like this... running standalone Vue.js app that just makes requests to the JSON:API
[15:41:17]<symbioquine[m]><mstenta[m] "what does the python side do? da"> Yeah, it is handling/authenticating/authorizing http requests, and returning the front-end pages/assets for the tools + DB query/CRUD results.
[15:43:27]<symbioquine[m]><mstenta[m] "also: 2.x would be a fun place t"> Makes sense.
[15:44:56]<symbioquine[m]>One the trickiest pieces in that seed inventory tool is the transactionality of acquiring/vending unique human-friendly primary identifiers for the seeds... which is one of the things that drove me to direct DB access even though I would have preferred to avoid it.
[15:47:26]<symbioquine[m]>That is, the ids which are like OISB###### referring to individual seed assets. That is modeled as a field on the seed asset with a unique constraint on the text column of the id.
[15:49:40]<symbioquine[m]>Unfortunately, the process of inventorying the seeds requires that the id be written on the packets. In some cases, one packet derives from another packet that are both being inventoried at the same time. e.g. this is the spotted off-type of a given bean. Together with the possibility of multiple people inventorying seeds simultaneously this necessitated a way to "claim or checkout" primary identifiers ahead of saving
[15:49:40]<symbioquine[m]>the associated seed asset.
[15:51:03]<mstenta[m]>wow that sounds like a well thought through system!
[15:51:26]<mstenta[m]>what does OISB stand for?
[15:52:01]<symbioquine[m]>The implementation currently works by writing to the primary id field table first independently in a way that "claims" the primary identifier for the person first, then when the asset is saved a transaction is used to update that field reference to point at the given seed asset.
[15:52:44]<symbioquine[m]>It's a prefix for our small local seed bank. The last two letters just stand for "seed bank" :)
[16:00:51]<symbioquine[m]>ACTION uploaded an image: image.png (66KiB) < >
[16:02:28]<symbioquine[m]>We just inventoried most of the collections this year so the historical data isn't necessarily totally representative of the pre-2015 seed bank, and we haven't inventoried a lot of the varieties we regenerated this year yet so that last green bar should get higher... :)
[16:02:45]<mstenta[m]>very cool!
[16:04:11]<symbioquine[m]>ACTION uploaded an image: image.png (31KiB) < >
[16:21:20]<paul121[m]>Really cool! Will there be a farmOS monitor on display in the orcas library?? :D
[16:44:18]<symbioquine[m]>Libraries would definitely be a great venue for some form of "aggregator kiosk" in communities with sufficient farmOS adoption.
[16:57:07]<symbioquine[m]><paul121[m] "Really cool! Will there be a far"> The [Orcas Seed Library]( is a separate smaller collection and is currently hand-managed. The varieties are curated to be those which are most successful and/or easiest-to-grow in the San Juan islands.
[16:57:39]<symbioquine[m]>I think the key question for having a farmOS monitor in a library would be what the objective of the data to be shown would be...
[17:04:25]<symbioquine[m]>Since it's public property there's a question of how it aligns with the ethos of libraries.
[17:05:02]<symbioquine[m]>I think it would be easy for it to become co-opted as an advertising space for for-profit entities.
[17:07:09]<paul121[m]>yeah interesting
[17:07:30]<paul121[m]>there would definitely need to be structure or else records would get messy very quickly