| [07:48:18] | <lordeddi[m]> | hi, can one add a land type e.g. "terrace" |
| [07:49:13] | <lordeddi[m]> | https://farmos.org/model/type/asset/#land-assets |
| [07:49:13] | <lordeddi[m]> | and there's no way to add it through the administration>structure>... |
| [07:49:25] | <mstenta[m]> | https://farmos.org/development/module/fields/#land-type |
| [07:49:30] | <lordeddi[m]> | maybe "Field" would be close enoughthough |
| [07:49:41] | <mstenta[m]> | Land types can be added via modules |
| [07:50:00] | <lordeddi[m]> | ah, that's exactly what i am looking for thanks! |
| [07:50:30] | <mstenta[m]> | It's in a weird place in the docs |
| [07:50:47] | <lordeddi[m]> | i got stuck in that "model" place and was a bit confused sorry |
| [07:52:01] | <FarmerEd[m]> | mstenta: just read your post in the forum, does that mean I can make an API call and get a new token in a single request? |
| [07:52:47] | <FarmerEd[m]> | I've just about worked out the flow based on expiry time too anyway. |
| [07:53:27] | <mstenta[m]> | I dont think so, it would be two requests I think. paul121 has done more than I have with this |
| [08:00:19] | <FarmerEd[m]> | Ah OK, so using expires_in would be a better strategy if there are going to be a lot of requests together like uploading a CSV file one line at a time. |
| [08:03:33] | <FarmerEd[m]> | Presumably subrequests a better strategy for CSV uploads anyway, but that's a job for another day. |
| [08:06:19] | <mstenta[m]> | This has some good thoughts https://stackoverflow.com/questions/54719946/oauth2-best-practice-to-kee... |
| [08:07:26] | <mstenta[m]> | Oops meant to paste this one https://stackoverflow.com/questions/29170013/oauth-refresh-token-best-pr... |
| [08:07:31] | <mstenta[m]> | Both might have relevant ideas :-) |
| [08:08:01] | <mstenta[m]> | It is pretty use case dependent, so do what works best |
| [08:16:07] | <FarmerEd[m]> | I guess my issue is I'm trying to build some nodes that are flexible for a multitude of use cases not just my own so trying to not tie down any particular strategies while keeping them relatively simple to use. Anyway plenty to go on now cheers. |
| [08:17:33] | <mstenta[m]> | Yea! I like your refresh node idea. |
| [08:57:18] | * farmBOT has joined #farmos |
| [14:04:17] | <FarmerEd[m]> | Do Farmier users have any access to the consumer entity settings? |
| [14:04:35] | <mstenta[m]> | i don't think so |
| [14:04:49] | <mstenta[m]> | they just get a Manager role... I forget if that has access |
| [14:05:25] | <FarmerEd[m]> | Will they need it if password grant is done away it? |
| [14:05:30] | <mstenta[m]> | Farmier doesn't really restrict much specifically itself... it just creates a user with the Manager role for the original registrant |
| [14:05:55] | <mstenta[m]> | It also adds an "Account Admin" role to that user with some extra perms like the ability to create new users |
| [14:06:02] | <mstenta[m]> | good question Farmer Ed |
| [14:06:43] | <mstenta[m]> | i honestly haven't given this much thought... but it seems like it would make sense to give the "Account Admin" role access to consumers, eh? |
| [14:07:01] | <FarmerEd[m]> | can't very well set default client credentials |
| [14:07:09] | <mstenta[m]> | i wonder if there are any security considerations |
| [14:09:14] | <FarmerEd[m]> | I'm sure there are, maybe there is a good argument for keeping password grant after the module stops supporting it officially? |
| [14:14:49] | <FarmerEd[m]> | unless there is a way to enforce minimum security requirements? |
| [14:28:00] | <mstenta[m]> | if there are security considerations with exposing the full consumers UI, another option might be to keep that locked down, but expose a more simplified UI just for managing client credentials |
| [14:28:19] | <mstenta[m]> | (either in farmOS itself to make things easier for everyone, or if that feels like overkill then maybe just in Farmier) |
| [14:28:38] | <mstenta[m]> | i don't have enough experience with the current UI to know what would make the best sense |
| [14:29:45] | <mstenta[m]> | my general approach is wait for someone to ask for it... set it up manually for them... then wait for more people to ask for it until i'm sick of setting up manual stuff, then figure something better out :-P |
| [14:30:05] | <mstenta[m]> | but if there's reason to consider this in farmOS core first, might be worth doing |
| [14:30:31] | <mstenta[m]> | i suppose one question is: would there be a use-case for other users (eg: not just managers) to set these up? |
| [14:30:48] | <mstenta[m]> | maybe that's a box of worms |
| [14:31:01] | <mstenta[m]> | i try to keep the worms contained as much as possible in farmier ;-) |
| [14:36:00] | <FarmerEd[m]> | Just a thought I had, it's not going to effect me too much, but want to make sure what I develop for node-red works as easily for both Farmier and self hosted. I was considering dropping the password grant myself if it was likely to be dropped in the nearish future anyway but think now it would be simplest to keep it. |