| [21:55:35] | * AnthonyWycoff[m] has joined #farmos |
| [09:43:52] | <symbioquine[m]> | <mstenta[m]> "OK this is ready for review..." <- Sorry it took so long. Left a couple comments 🏸 |
| [10:52:17] | * farmBOT has joined #farmos |
| [11:06:52] | <gbathree[m]> | Hey mstenta is it true in the organizations module... if I have a plant asset w/ seeding movement (thus associated with a land asset) that this plant asset with inherit the organization from the land asset even if it wasn't explicitly set? |
| [11:06:52] | <gbathree[m]> | If that's true... what happens if I explicitly set it... do I override it? |
| [11:07:26] | <gbathree[m]> | * Hey mstenta is it true in the organizations module... if I have a plant asset w/ seeding movement (thus associated with a land asset) that this plant asset will inherit the organization from the land asset even if it wasn't explicitly set in the plant asset? (I'm testing and this seems true) |
| [11:07:26] | <gbathree[m]> | If that's true... what happens if I explicitly set it... do I override it? |
| [11:07:53] | <mstenta[m]> | No. There's no inheritance logic in the current PR. The expectation right now is that each asset is explicitly assigned to a farm. |
| [11:08:41] | <mstenta[m]> | We could consider adding some kind of logic like that... in the current PR or (more likely) in follow-ups. but it doesn't exist in the current proposed implementation. |
| [11:10:34] | <gbathree[m]> | ok, yeah I think I must have messed up and looked at the wrong thing. That makes sense, all assets must be explicitly set to a farm |
| [11:12:47] | <mstenta[m]> | As for logs, if we don't add an explicit farm reference field to them, then my assumption is they will "inherit" the farm of the asset(s) that they reference. But there is no logic to do that yet either. |
| [11:13:16] | <mstenta[m]> | My thought is that could simply be a computed field on logs, which looks up the explicit (non-computed) reference on assets. |
| [11:13:27] | <mstenta[m]> | That would allow for filtering logs by farm, for instance. |
| [12:31:19] | <mstenta[m]> | symbioquine: Thanks for the comments! I addressed them and left another question regarding the `[Unreleased]` link |
| [12:34:49] | <gbathree[m]> | <mstenta[m]> "My thought is that could..." <- we've been kicking this can down the road w/ Pedro, but yes I think that's the right way to do it if we can. There are definitely cases where there won't be explicit connections to an asset. |
| [12:38:16] | <mstenta[m]> | gbathree[m]: Yea I know you and I have talked about this too. The computed field would need to look at both the asset and location reference fields of the log. |
| [12:39:16] | <mstenta[m]> | mstenta[m]: So as long as the log is associated with an asset in at least one of those (and the asset(s) are associated with a farm), then the log can be associated with a farm. |
| [12:40:20] | <mstenta[m]> | mstenta[m]: But this is important to figure out, because once we go the route of NOT explicitly referencing a farm from a log, it would be hard to change that (and vice versa) |
| [12:41:18] | <mstenta[m]> | mstenta[m]: So if there are specific use cases where a log does NOT reference an asset (or location) we need to consider those |
| [12:41:52] | <mstenta[m]> | mstenta[m]: Even so, if there are, we may still need to weigh the costs/benefits of supporting that |
| [12:42:19] | <gbathree[m]> | mstenta[m]: One such type of log that we're hearing a lot of interested in is just a basically a communication log with a producer. So if I'm a technical assistance provider and I talk with a producer I want to be able to log that discussion and farm OS associated with the farm |
| [12:42:47] | <gbathree[m]> | gbathree[m]: And then attached for example my speech notes or do text to speech translation in the notes field. Certainly it would be cool to like associate that or automatically associated with the topics but it's not really guaranteed it could just be a loose log |
| [12:43:08] | <gbathree[m]> | gbathree[m]: Also I'm curious if plans are assets I forget |
| [12:44:23] | <mstenta[m]> | gbathree[m]: Hmm that's an interesting one. It strikes me as maybe more of a CRM feature... we've talked about adding a Contact entity to compliment the Organization entity in the future... so it might be a better fit to reference the contact than the farm |
| [12:44:59] | <mstenta[m]> | mstenta[m]: Plans are not assets. They are plans (their own type) :-) |
| [12:45:45] | <mstenta[m]> | mstenta[m]: We haven't covered that yet, but IMO a plan would reference a farm directly. |
| [12:46:08] | <mstenta[m]> | mstenta[m]: (So still no need for logs to reference Farms IMO) |
| [12:46:59] | <mstenta[m]> | mstenta[m]: We really should try to document all these points in the forum topic... this chat is ephemeral |
| [12:47:57] | <mstenta[m]> | * the farm. And the contact would reference the farm (organization). |
| [12:48:20] | <mstenta[m]> | * the farm. And the contact would reference the farm (organization)... or vice versa. |
| [13:12:11] | <gbathree[m]> | <mstenta[m]> "Hmm that's an interesting one..." <- Agreed it is. Maybe there's a better way to do this open to ideas. But it keeps coming up. |
| [13:37:57] | <mstenta[m]> | <gbathree[m]> "Agreed it is. Maybe there's a..." <- Yea - it feels to me like a proper CRM implementation in farmOS would need a Contact entity and a new log type (eg: "Communication" logs). |
| [13:38:46] | <mstenta[m]> | mstenta[m]: Although even then, using logs might be a little problematic, simply because they would also include a lot of other default log fields that might not make sense in a "Communcation" |
| [13:39:01] | <mstenta[m]> | mstenta[m]: (eg: location, quantity, is movement, inventory, etc etc etc) |
| [13:39:51] | <mstenta[m]> | mstenta[m]: Feels like this needs its own whole scoping process tb |
| [13:39:54] | <mstenta[m]> | mstenta[m]: tbh |
| [13:40:31] | <mstenta[m]> | mstenta[m]: There are also existing CRM modules available for Drupal... paul121 and I looked at some of these before ultimately deciding to create our own `organization` entity |
| [13:41:11] | <mstenta[m]> | mstenta[m]: https://www.drupal.org/project/redhen |
| [13:41:15] | <mstenta[m]> | mstenta[m]: https://www.drupal.org/project/crm_core |
| [13:41:35] | <mstenta[m]> | mstenta[m]: There's also integrations with third-party CRMs like CiviCRM: https://www.drupal.org/project/civicrm |
| [13:42:07] | <mstenta[m]> | mstenta[m]: So it's also a question of: do we want farmOS to maintain it's own CRM features, or better to just integrate with another system that specializes in that? |
| [17:45:41] | * KevinKendrick[m] has joined #farmos |