IRC logs for #farmOS, 2022-12-09 (GMT)

2022-12-08
2022-12-10
TimeNickMessage
[22:30:52]* farmB748 has joined #farmos
[22:33:14]* farmB748 is now known as farmB753
[22:33:14]* farmBOT has quit (Killed (NickServ (GHOST command used by farmB748)))
[22:38:14]* farmB753 is now known as farmBOT
[01:29:17]* farmBOT has joined #farmos
[08:23:32]<FarmerEd[m]>ACTION uploaded an image: (111KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/XGslKkCHhlc... >
[08:24:21]<FarmerEd[m]>Wouldn't make sense to display current inventory on this screen?
[08:25:02]<FarmerEd[m]>And the export csv
[08:31:13]<FarmerEd[m]>* Wouldn't it make sense
[08:32:13]<mstenta[m]>Yea! And actually this seems related to something we discussed on the call yesterday. I think if the inventory field were a "bundle" field it would automatically show up. But it's a "base" field, so it doesn't. Maybe we should make base fields that are added via `hook_entity_base_field_info()` as columns automatically.
[08:32:41]<mstenta[m]>(tbh I think I assumed that inventory was already showing up as a column...)
[08:35:28]<FarmerEd[m]>Maybe even a Dashboard widget for most commonly used materials?
[08:35:28]<FarmerEd[m]>Or select materials, if some are more relevant at different times of year?
[08:36:17]<mstenta[m]>Great ideas!
[08:36:27]<mstenta[m]>Maybe materials marked with a "Priority" flag?
[08:36:58]<mstenta[m]>(that wouldn't help with the seasonal priorities though - but it would be simple)
[08:37:31]<mstenta[m]>start simple and iterate from there maybe :-)
[08:39:19]<FarmerEd[m]>Well if you can nominate which flags are the displayed materials, then perhaps flags by season?
[08:40:37]<mstenta[m]>yea perhaps! or maybe the dashboard widget has some config that lets you define the filters more generally, so you could decide how it filters down to relevant asset
[08:41:16]<mstenta[m]>(i could see that functionality being useful for all kinds of dashboard widgets)
[08:41:17]<mstenta[m]>gosh maybe we just need a "dashboard widget builder" :-)
[08:42:01]<mstenta[m]>at some point we're basically just reinventing drupal though
[08:43:14]<mstenta[m]>if you are self-hosting you can create a View of exactly what you want, with a Block display, and then add it to the dashboard
[08:43:15]<mstenta[m]>currently adding to the dashboard requires implementing a hook in a module IIRC, but pcambra's module makes the dashboard use layout builder - which means you can place blocks via the UI too (no need for a module at all)
[08:44:06]<mstenta[m]>(as i understand it)_
[08:44:16]<FarmerEd[m]>Yea, was following some of that
[08:45:12]<FarmerEd[m]>of course widget plugins/modules would be nice too. :D
[08:45:34]<mstenta[m]>yes exactly... i think there's a balance, and providing some things "out of the box" is worth doing too
[08:45:49]<mstenta[m]>the material inventory widget is a great idea IMO
[08:46:31]<mstenta[m]>"Priority material inventory" perhaps as a very simple first step
[08:46:32]<mstenta[m]>that would be an easy View+Block to create
[08:46:55]<mstenta[m]>(without any user-configurable stuff to start is simple)
[08:47:34]<mstenta[m]>Want to whip that up together on the next dev call? :-)
[08:47:53]<mstenta[m]>Can get you started at least and then you can take it from there and make it into a PR if you want
[08:47:53]<FarmerEd[m]>Sure,
[08:48:07]<mstenta[m]>It really would only take a few minutes I think!
[08:48:21]<mstenta[m]>(unless we discover something I'm not considerring)
[08:50:07]<FarmerEd[m]>I haven't been too good at keeping inventory to date, but been keeping up with my bale inventory this year, really makes planning ahead a bit easier.
[08:50:26]<mstenta[m]>nice!
[08:50:37]<mstenta[m]>an inventory quick form is something else i've been thinking about
[08:51:16]<mstenta[m]>i whipped up a maple tapping quick form in the farm_maple module which tracks tap inventory - could use that as a guide
[08:52:52]<FarmerEd[m]>I've been using symbioquine asset link, which is working well for this
[08:53:23]<FarmerEd[m]>maybe I need the inventory displayed here:
[08:53:50]<FarmerEd[m]>ACTION uploaded an image: (123KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/qCunwuHmXnI... >
[08:57:01]<FarmerEd[m]>Also toying with the idea of installing Node-Red locally on an Android device in the tractor and link baler counter for incrementing bale inventories at the end of baling when tractor returns to WiFi coverage in the yard.
[09:36:25]<mstenta[m]>nice!
[10:01:23]<FarmerEd[m]>I just installed Node-Red on my phone and it works! Need to decide now between a tablet or Android head unit for tractor.
[10:01:23]<FarmerEd[m]>Could be developed into another offline field too! (for Android users only though)
[10:05:34]<mstenta[m]>HA!
[10:06:09]<mstenta[m]>You might be taking this node-red stuff too far Farmer Ed 😆
[10:06:10]<mstenta[m]>(j/k that's awesome)
[10:09:16]<FarmerEd[m]>You might think so.....
[10:09:16]<FarmerEd[m]>Maybe farmOS 3.0 gets built with low code 😆
[10:12:06]<symbioquine[m]>It kind of already is... if you count how much functionality is defined just with Yaml in 2.x
[10:15:59]<FarmerEd[m]>True, was kind of thinking that as I hit send
[10:17:29]<mstenta[m]>ACTION uploaded an image: (15KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/KjMIICSHNyI... >
[10:17:38]<mstenta[m]>Ah yea... I remember when YAML was the majority - in the early days of 2.x dev 😄
[10:18:31]<mstenta[m]>https://twitter.com/getFarmier/status/1313872008791416832
[10:18:57]<mstenta[m]>the automated tests really killed that dream 😜
[10:19:08]<FarmerEd[m]>Still pretty high though, but even yaml is more code than many Node-Red users would like.
[10:21:59]<FarmerEd[m]>The more complex my Node-Red flows become, the more the become more JavaScript than no code.
[10:23:25]<FarmerEd[m]>But then again I didn't know any JavaScript before I started using it.
[10:24:39]<FarmerEd[m]>s/the/they/
[10:58:57]<mstenta[m]>paul121: I'm trying to get back into https://www.drupal.org/project/farm/issues/3310286 - which basically only needs tests, but I'm finding a strange issue in my local dev environment... every kernel test i try to run fails with This test did not perform any assertions
[10:59:06]<mstenta[m]>have you encountered this?
[10:59:10]<mstenta[m]>i might just need to rebuild my local dev environment - not sure what's up
[11:12:02]<mstenta[m]>hmm. rebuilding local dev did not work.
[12:29:25]<mstenta[m]>works fine in github actions
[12:29:26]<mstenta[m]>bah this is frustrating
[13:32:01]<mstenta[m]>🤦 fixed it.
[13:32:02]<mstenta[m]>I don't know why exactly it wasn't working... but I found that I had both web/profiles/farm and web/profiles/profiles/farm (by accident) and deleting the latter made tests work again 🤷
[14:16:16]<mstenta[m]>symbioquine paul121 Do you remember where we landed on the `$timestamp` parameter data type?
[14:16:31]<mstenta[m]>My current branch has:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/db1587d61d...)
[14:16:50]<mstenta[m]>But if you recall that was one of the things I was looking for thoughts on when we talked about it a long time ago...
[14:17:26]<mstenta[m]>I think we landed on defaulting it to NULL instead, right? Does that sound familiar?
[14:18:18]<mstenta[m]>Because 0 is actually a valid timestamp :-)
[14:26:07]<mstenta[m]>(the only slight argument against that was that it's less type-strict...)
[14:26:20]<mstenta[m]>(int|null instead of always int)
[14:44:32]<symbioquine[m]><mstenta[m]> "I think we landed on defaultin..." <- I feel like this was definitely one of the top options...
[14:45:21]<symbioquine[m]>and the simplest of the ones which allows Jan 1st 1970 as an input
[14:50:10]<mstenta[m]>cool - i'll go with that
[14:50:19]<mstenta[m]>i couldn't remember if there was a third option
[14:50:25]<mstenta[m]>paul121 might
[14:51:27]<symbioquine[m]>One approach we talked about was having two methods one without the timestamp argument which just gets the current timestamp and invokes the second one which takes the timestamp.
[14:52:05]<symbioquine[m]>Another was having some other kind of sentinel value which would be more self-documenting in the calling code - i.e. "NOW" as a string.