| [23:21:40] | * svenn_ has quit (Read error: Connection reset by peer) |
| [23:22:04] | * svenn_ has joined #farmos |
| [23:37:47] | * svenn_ has quit (*.net *.split) |
| [23:42:16] | * svenn_ has joined #farmos |
| [23:45:15] | * JulianF has quit (Ping timeout: 246 seconds) |
| [23:45:25] | * linus0[m] has quit (Ping timeout: 268 seconds) |
| [23:45:26] | * ramses[m] has quit (Ping timeout: 240 seconds) |
| [23:45:36] | * rocoroc[m] has quit (Ping timeout: 246 seconds) |
| [23:45:36] | * symbioquine[m] has quit (Ping timeout: 246 seconds) |
| [23:45:40] | * calbasi_matrix has quit (Ping timeout: 260 seconds) |
| [23:45:57] | * jolau[m] has quit (Ping timeout: 246 seconds) |
| [23:45:57] | * spiffyman[m] has quit (Ping timeout: 240 seconds) |
| [23:45:57] | * mstenta[m] has quit (Ping timeout: 246 seconds) |
| [23:45:57] | * jcalonso[m] has quit (Ping timeout: 246 seconds) |
| [23:45:57] | * generalredneck[m has quit (Ping timeout: 246 seconds) |
| [23:46:05] | * abinash[m] has quit (Ping timeout: 240 seconds) |
| [23:46:08] | * abugida[m] has quit (Ping timeout: 260 seconds) |
| [23:46:08] | * paul121[m] has quit (Ping timeout: 260 seconds) |
| [23:46:09] | * todrobbins[m] has quit (Ping timeout: 260 seconds) |
| [23:46:09] | * kunigunde[m] has quit (Ping timeout: 260 seconds) |
| [23:46:15] | * gabriel_renoir[m has quit (Ping timeout: 265 seconds) |
| [23:46:15] | * zedrckr[m] has quit (Ping timeout: 265 seconds) |
| [23:46:15] | * munjoma[m] has quit (Ping timeout: 265 seconds) |
| [23:46:19] | * wombat83[m] has quit (Ping timeout: 272 seconds) |
| [23:46:24] | * dazinism has quit (Ping timeout: 240 seconds) |
| [23:46:26] | * trishlatalera[m] has quit (Ping timeout: 240 seconds) |
| [23:46:36] | * dge[m] has quit (Ping timeout: 260 seconds) |
| [23:49:44] | * jgaehring[m] has quit (Ping timeout: 240 seconds) |
| [23:56:16] | * linus0[m] has joined #farmos |
| [00:06:29] | * dge[m] has joined #farmos |
| [00:07:04] | * kunigunde[m] has joined #farmos |
| [00:09:26] | * paul121[m] has joined #farmos |
| [00:09:27] | * todrobbins[m] has joined #farmos |
| [00:09:27] | * abugida[m] has joined #farmos |
| [00:09:30] | * calbasi_matrix has joined #farmos |
| [00:09:32] | * wombat83[m] has joined #farmos |
| [00:10:55] | * JulianF has joined #farmos |
| [00:11:03] | * rocoroc[m] has joined #farmos |
| [00:11:06] | * ramses[m] has joined #farmos |
| [00:15:21] | * dazinism has joined #farmos |
| [00:15:26] | * symbioquine[m] has joined #farmos |
| [00:16:46] | * zedrckr[m] has joined #farmos |
| [00:16:46] | * munjoma[m] has joined #farmos |
| [00:16:58] | * gabriel_renoir[m has joined #farmos |
| [00:17:14] | * jolau[m] has joined #farmos |
| [00:17:17] | * mstenta[m] has joined #farmos |
| [00:17:17] | * jcalonso[m] has joined #farmos |
| [00:17:27] | * generalredneck[m has joined #farmos |
| [00:17:52] | * spiffyman[m] has joined #farmos |
| [00:18:23] | * abinash[m] has joined #farmos |
| [00:19:05] | * trishlatalera[m] has joined #farmos |
| [00:19:12] | * jgaehring[m] has joined #farmos |
| [02:33:46] | * DirtyGiraffe has joined #farmos |
| [07:32:29] | * xouskO has joined #farmos |
| [07:32:33] | * xouskO has quit (Connection closed) |
| [07:55:12] | * funnel has joined #farmos |
| [07:55:17] | * funnel has quit (Connection closed) |
| [07:59:28] | * Chew has joined #farmos |
| [07:59:31] | * Chew has quit (Connection closed) |
| [08:08:21] | * robotrollYk has joined #farmos |
| [08:08:26] | * robotrollYk has quit (Read error: Connection reset by peer) |
| [08:11:03] | * Razielxp has joined #farmos |
| [08:11:34] | * Razielxp has quit (Remote host closed the connection) |
| [08:12:40] | * floogulinc has joined #farmos |
| [08:13:13] | * floogulinc has quit (Remote host closed the connection) |
| [08:16:20] | * promotevG has joined #farmos |
| [08:18:10] | * promotevG has quit (Remote host closed the connection) |
| [11:34:17] | * farmBOT has joined #farmos |
| [11:42:03] | * naveenls[m] has joined #farmos |
| [11:42:41] | <naveenls[m]> | How to setup and use Oauth2.0 for making rest api calls |
| [11:44:11] | <paul121[m]> | Try these docs: https://farmos.org/development/api/#oauth2-details |
| [11:44:30] | <paul121[m]> | Specifically the Password credentials authorization flow: https://farmos.org/development/api/#password-credentials-grant |
| [12:09:38] | * DirtyGiraffe has quit (Ping timeout: 264 seconds) |
| [12:36:55] | * botlfarm[m] has joined #farmos |
| [12:41:07] | * DirtyGiraffe has joined #farmos |
| [13:58:58] | <generalredneck[m> | skipping this month. I'm pretty behind on billibles and can really use the time to catch up. |
| [14:01:57] | <mstenta[m]> | My internet cut out at exactly 2 haha |
| [14:02:02] | <mstenta[m]> | Be right there... |
| [14:56:37] | <jgaehring[m]> | oh I meant to ask symbioquine more about the seed asset too... is that module in a public repo somewhere? |
| [15:05:19] | <symbioquine[m]> | Not yet, I was preparing to publish it a while back with my PR https://github.com/farmOS/farmOS/pull/285 but didn't go farther once that didn't pan out. |
| [15:05:44] | <mstenta[m]> | Oh yea I've been thinking about the trait idea again recently... |
| [15:05:56] | <symbioquine[m]> | My hope now is to build/share a seed asset for 2.x |
| [15:07:09] | <paul121[m]> | Interested in the traits too! |
| [15:08:41] | <symbioquine[m]> | Internally, I'm using code very similar to what's in that PR as part of building a seed asset - but I relaxed some of my constraints when I realized it wasn't going to be as straight-forward to share it as-is. e.g. there's some code in the view for transforming "externalIds" matching 'PI \d+' into links to USDA GRIN |
| [15:09:22] | <symbioquine[m]> | Ideally, there'd be extensible and not part of the core seed asset if i were maintaining a contrib version. |
| [15:09:48] | <symbioquine[m]> | * Ideally, that'd be extensible and not part of the core seed asset if i were maintaining a contrib version. |
| [15:12:18] | <symbioquine[m]> | jgaehring: I'd be happy to publish a rough copy of the current seed asset code I'm using if it would be helpful as an example - with the caveat that I haven't really been maintaining it for external consumption :) |
| [15:47:47] | <paul121[m]> | the ability for users to create these pseudo-fields on assets would just be soo cool. |
| [15:48:36] | <paul121[m]> | wrapping them in a "trait" system supported by core would be great |
| [15:49:33] | <paul121[m]> | basically a controlled & supported alternative to opening up the Field UI module to users & allowing them to create fields as they please... |
| [15:49:47] | <symbioquine[m]> | Yeah, for our use-case having a way to store arbitrary characteristics in a structured way is pretty important. e.g. Whether wheat is Winter/Spring/Facultative or whether beans are bush/pole/intermediate |
| [15:50:28] | <symbioquine[m]> | In my opinion the structure of those fields should be such that it doesn't wreck the UI for them to be very sparsely populated. |
| [15:51:57] | <paul121[m]> | ah yea - and thats a benefit of a "trait" system, right? |
| [15:52:09] | <symbioquine[m]> | yeah |
| [15:52:17] | <paul121[m]> | that alternative being that fields are created on ALL assets, no matter what |
| [15:52:39] | <symbioquine[m]> | <paul121[m] "ah yea - and thats a benefit of "> Yeah. Though, there's lots of ways to achieve something similar... |
| [15:52:57] | <symbioquine[m]> | <paul121[m] "that alternative being that fiel"> At least at the UI layer it works that way. |
| [15:54:06] | <symbioquine[m]> | It's also kind of clunky to create so many new tables/joins by modeling such things as Drupal fields. |
| [15:56:36] | <paul121[m]> | yeah |
| [15:57:41] | <paul121[m]> | Drupal fields just get a lot for "free" too - like API integration, revisions, etc |
| [15:57:51] | <paul121[m]> | but doesn't mean it doesn't come without baggage! |
| [15:57:53] | <mstenta[m]> | I wonder if something like the key value module would be worth considering |
| [15:58:16] | <mstenta[m]> | https://www.drupal.org/project/key_value_field |
| [15:59:36] | <mstenta[m]> | I've never tried it... |
| [15:59:51] | <symbioquine[m]> | Yeah, that looks pretty promising |
| [16:00:24] | <mstenta[m]> | Maybe a `trait` field on all asset types by default, as a key value field? |
| [16:00:38] | <mstenta[m]> | Worth dropping it in and playing around perhaps |
| [16:00:56] | <symbioquine[m]> | Yeah |
| [16:01:32] | <mstenta[m]> | Might serve the egg module needs to "this asset lays eggs" |
| [16:01:41] | <mstenta[m]> | * Might serve the egg module needs too "this asset lays eggs" |
| [16:02:09] | <mstenta[m]> | Can we migrate the "castrated" field to it? 😅 |
| [16:02:31] | <paul121[m]> | a way to standardize the keys... such as taxonomy terms |
| [16:02:53] | <mstenta[m]> | Yea that's the trade-off |
| [16:03:00] | <paul121[m]> | maybe the keys could have logic to determine if they apply to certain assets (like an animal) |
| [16:06:27] | <paul121[m]> | and different value types... so you could store a "string" trait, "number" trait, perhaps an entity reference trait.. |
| [16:06:47] | <paul121[m]> | similar to the quantity type |
| [16:07:54] | <paul121[m]> | traits that are derived from logs... like location or group membership |
| [16:08:32] | <paul121[m]> | not sure if these are sufficiently related :) |
| [16:09:10] | <paul121[m]> | but some kind of "trait" feature & abstracting out the "asset property derived from logs" would be great to chalk up for 2.1 maybe?? |
| [16:10:40] | <mstenta[m]> | > traits that are derived from logs... like location or group membership |
| [16:10:40] | <mstenta[m]> | I was just going to bring that up |
| [16:11:02] | <mstenta[m]> | Are traits a field on the asset? Or will they need to change via logs? |
| [16:11:19] | <mstenta[m]> | Will you need to track the change itself (beyond asset revisions) |
| [16:13:24] | <paul121[m]> | hmm yea. maybe these should be separate |
| [16:13:56] | <paul121[m]> | thinking in terms of JSONAPI... its almost "intrinsic_attributes" and "derived_attributes" |
| [16:14:58] | <paul121[m]> | both under the `resource.attributes` umbrella |
| [16:16:18] | <symbioquine[m]> | At least for my use-case, I believe asset revisions are sufficient tracking for traits. |
| [16:17:08] | <symbioquine[m]> | <paul121[m] "a way to standardize the keys..."> This could just be handled on the input side via a field validator and maybe a custom form input... |
| [16:17:56] | <mstenta[m]> | > Can we migrate the "castrated" field to it? 😅 |
| [16:17:56] | <mstenta[m]> | this is one that would benefit from log tracking |
| [16:18:11] | <symbioquine[m]> | yeah, that makes sense |
| [16:18:49] | <mstenta[m]> | i could imagine a `trait` field on logs, which basically means "set these traits on referenced assets" |
| [16:18:49] | <symbioquine[m]> | <paul121[m] "but some kind of "trait" feature"> Seems like unnecessary abstraction... |
| [16:19:16] | <symbioquine[m]> | <mstenta[m] "i could imagine a `trait` field "> That would be nice :) |
| [16:19:20] | <mstenta[m]> | or `asset_trait` (to be more specific) |
| [16:19:33] | <mstenta[m]> | would that fit your use-cases too symbioquine and paul121 ? |
| [16:20:05] | <mstenta[m]> | (i saw you said revisions would fit your symbioquine - but would logs work as well?) |
| [16:21:40] | <mstenta[m]> | and then maybe a `trait` computed field on the assets themselves? |
| [16:21:49] | <mstenta[m]> | (like `location`) |
| [16:21:58] | <paul121[m]> | <symbioquine[m] "Seems like unnecessary abstracti"> maybe. I might be thinking more like "utilities" for creating other fields computed by logs. For example the "Destroyed harvest" use case... maybe a "total harvest" computed field could help with this? |
| [16:22:37] | <mstenta[m]> | oh you mean from the "Loss of Product" forum topic? |
| [16:22:50] | <mstenta[m]> | cool yea that could be a way to handle it |
| [16:22:57] | <mstenta[m]> | (as a convention anyway) |
| [16:23:05] | <symbioquine[m]> | <mstenta[m] "(i saw you said revisions would "> Yeah, either way can work |
| [16:23:18] | <mstenta[m]> | so... this also makes me think about the "asset life cycle/growth stage stuff" |
| [16:23:23] | <mstenta[m]> | are those just traits as well? |
| [16:23:33] | <mstenta[m]> | * are those just `trait`s as well? |
| [16:23:58] | <paul121[m]> | requiring a log to assign the traits seems like a bummer. like a UX/DX thing |
| [16:24:18] | <paul121[m]> | basically the same argument for not requiring movement logs |
| [16:24:22] | <mstenta[m]> | yea that's certainly a drawback |
| [16:24:52] | <mstenta[m]> | `intrinsic_trait` ;-) |
| [16:25:04] | <mstenta[m]> | (not suggesting that haha) |
| [16:25:23] | <paul121[m]> | if its "intrinsic", and I have 200 assets that need the same thing, it gets annoying. although one log that can assign multiple would help |
| [16:25:30] | <mstenta[m]> | right |
| [16:25:42] | <mstenta[m]> | that's where logs are useful... same with movements and group membership (and weight) |
| [16:25:44] | <paul121[m]> | > thinking in terms of JSONAPI... its almost "intrinsic_attributes" and "derived_attributes" |
| [16:25:45] | <paul121[m]> | I already did suggest it - ha! |
| [16:25:48] | <mstenta[m]> | so weight...... |
| [16:26:04] | <mstenta[m]> | related? |
| [16:26:17] | <mstenta[m]> | (should weight be a trait (hey that rhymes) |
| [16:26:22] | <mstenta[m]> | * (should weight be a trait (hey that rhymes)) |
| [16:28:12] | <paul121[m]> | hmm |
| [16:28:31] | <mstenta[m]> | (also not necessarily suggesting it... but all these things feel very similar) |
| [16:28:51] | <paul121[m]> | thinking about quantities in general. a trait's value could be a quantity |
| [16:29:08] | <mstenta[m]> | we might want to open a forum topic or issue to map out all the various pieces here... i'm really hesitant to add another subsystem without giving it holistic thought |
| [16:30:00] | <mstenta[m]> | (and unless we come up with some elegant and simple answer in the next month or two, it'll probably have to be 2.1+) |
| [16:30:15] | <mstenta[m]> | (which means also writing migrations, for eg: castrated, weights, etc) |
| [16:31:25] | <paul121[m]> | yeah |
| [16:32:08] | <mstenta[m]> | migrating weights off of quantities will be tricky either way |
| [16:32:35] | <mstenta[m]> | hmmmmmm |
| [16:32:46] | <mstenta[m]> | what about: a `trait` quantity type? |
| [16:32:56] | <mstenta[m]> | 🤔 |
| [16:33:23] | <mstenta[m]> | (maybe not... that would imply traits are always numbers) |
| [16:34:47] | <paul121[m]> | it does seem similar, where a trait entity + trait bundles would be useful |
| [16:38:00] | <mstenta[m]> | ah hmm |
| [17:03:44] | <symbioquine[m]> | Even finer than the bundle level, it would be nice to have some traits only appear in the UI for certain cross-sections of varieties. e.g. "awed-ness" should only apply to grains... 😁 |
| [17:03:56] | <symbioquine[m]> | * Even finer than the bundle level, it would be nice to have some traits only appear in the UI for certain cross-sections of varieties. e.g. "awned-ness" should only apply to grains... 😁 |