| [02:48:40] | <andifi[m]> | Thx for recording and uploading 👍 |
| [04:48:54] | <skipper_is[m]> | And really excited to see the crop plan, looking forward to trying that! |
| [05:00:41] | * JustTB has quit (Quit: Leaving.) |
| [05:25:21] | * JustTB has joined #farmos |
| [08:00:18] | <mstenta[m]> | That makes two of us skipper_is !!! |
| [08:00:47] | <mstenta[m]> | I already have it installed and using it for my 2020 crop management, and even though it's just the first steps it's already helping |
| [08:01:22] | <mstenta[m]> | Right now the main thing it provides is conceptually organizing plantings into a group, and allowing editing the seeding/transplanting date/location quickly in one place. |
| [08:01:33] | <mstenta[m]> | Similar to the Planting quick form, but you can reuse it after the plantings are created |
| [08:01:48] | <mstenta[m]> | If you want to try it out, the repo is here: https://github.com/mstenta/farm_crop_plan |
| [08:02:25] | <mstenta[m]> | Just note that the database schema is actively changing, and we are not in "beta" yet so we are NOT including automated db update code |
| [08:03:36] | <mstenta[m]> | I'm going to be organizing the roadmap for it in that github issue queue soon |
| [08:04:06] | <mstenta[m]> | Note that our work on this is currently being funded by a grant, and we have some specific requirements to stick to, so that's going to be our main focus in this first phase of development |
| [08:04:32] | <mstenta[m]> | But we're designing it with future phases in mind - so all ideas are welcome :-) |
| [14:05:30] | <skipper_is[m]> | Yea, and the calendar organising view looked really good! If the plantings are clicked on, can you then make amendments to those plantings? |
| [14:09:17] | <mstenta[m]> | yea, the goal is to be able to edit directly from that timeline view |
| [14:09:32] | <mstenta[m]> | not possible yet... but that's the plan |
| [14:09:49] | <mstenta[m]> | right now there's a separate "Plantings" tab where you edit the individual Planting/Seeding/Transplanting details. |
| [14:10:01] | <mstenta[m]> | taking a very incremental approach... |
| [14:11:24] | <skipper_is[m]> | Oo, drag and drop as well? |
| [14:12:27] | <mstenta[m]> | Yea that's on the roadmap! |
| [14:12:39] | <mstenta[m]> | For moving timing and moving between areas |
| [14:24:46] | <skipper_is[m]> | Oh that is really cool |
| [14:25:07] | <skipper_is[m]> | And then having those options on the grazing plan? |
| [14:25:16] | <skipper_is[m]> | I've not used the grazing plan actually, I should give it a spin |
| [14:33:58] | <mstenta[m]> | I would love to update the grazing plan to be able to work the same way |
| [14:34:12] | <mstenta[m]> | It was built a few years ago, and is a bit clunky |
| [14:34:26] | <mstenta[m]> | But there may be some interest to give it a refresh soon... and this crop planning module work might give that a good boost |
| [16:00:36] | <paul121[m]> | I'm going to jump on to this LIVE OAuth Happy Hour! |
| [16:00:38] | <paul121[m]> | https://www.youtube.com/watch?v=E4msDjZMRZc |
| [16:01:04] | <paul121[m]> | Might ask a couple questions related to farmOS if anything comes to mind :-) |
| [16:01:37] | <mstenta[m]> | Awesome! |
| [16:01:46] | <mstenta[m]> | Wish I could join :-) |
| [17:06:25] | <paul121[m]> | Got a great answer!! Starts here: https://youtu.be/E4msDjZMRZc?t=3448 |
| [17:06:49] | <paul121[m]> | regarding self-hosted & open source OAuth |
| [17:07:03] | <paul121[m]> | the question following mine is quite relevant, too |
| [17:09:37] | <paul121[m]> | The gist is that public OAuth Client IDs are not great |
| [17:11:00] | <paul121[m]> | but a way to alleviate that is by making the client_id be an http URL and use DNS to verify the client ID |
| [17:13:53] | <paul121[m]> | so, 3rdparty.com wants access to farmOS harvests - their OAuth Client ID would be their DNS name. When they try to authorize, you just make sure the client_id matches the URL making the request |
| [17:14:16] | <paul121[m]> | (might not work in some scenarios, but is a cool concept) |
| [17:14:48] | <mstenta[m]> | Oh interesting! |
| [17:14:55] | <mstenta[m]> | I like that |
| [17:15:30] | <mstenta[m]> | But first party clients (eg field kit) would still work as they do now |
| [17:16:33] | <paul121[m]> | yes, but the issue is that anyone could try to authorize against a farmOS server and say they are "farm_client" (the oauth client_id for Field Kit, because this is public and well-known) |
| [17:17:42] | <paul121[m]> | so it would be better if Field Kit had a client_id tied to the domain it is running on |
| [17:18:22] | <paul121[m]> | but... not sure how that would work because Field Kit is a SPA |
| [17:19:19] | <paul121[m]> | and, Field Kit is open source itself which means it would be harder for someone else to host their own |
| [17:23:51] | <mstenta[m]> | Oh interesting |
| [17:23:59] | <mstenta[m]> | Right |
| [17:24:32] | <mstenta[m]> | But I'm a little unclear on what this approach is trying to solve/prevent |
| [17:25:06] | <mstenta[m]> | <paul121[m] "yes, but the issue is that anyon"> They still need a token to authenticate |
| [17:27:37] | <paul121[m]> | Ah, this is at the "Authorization" level |
| [17:28:42] | <paul121[m]> | So the phase when a 3rd party is requesting an access token |
| [17:29:34] | <paul121[m]> | (not as relevant for Field Kit because it doesn't use authorization flow) |
| [17:30:48] | <mstenta[m]> | Oh right ok |
| [17:31:21] | <paul121[m]> | but if a malicious app redirects the user to farmOS Server to login "on behalf of Field Kit" (when really they aren't) the user may grant access... to someone who isn't who they are saying they are... |
| [17:31:56] | <mstenta[m]> | Right makes sense |
| [17:32:22] | <paul121[m]> | Any 3rd party app could still trick the user into providing them their farmOS username and password :-) |
| [17:33:16] | <paul121[m]> | That's an unavoidable social (?) issue haha |
| [17:35:11] | <mstenta[m]> | Right |