| [20:09:13] | * mstenta[m] has quit (Ping timeout: 480 seconds) |
| [20:09:18] | * RobertDuncan[m] has quit (Ping timeout: 480 seconds) |
| [20:15:08] | * mstenta[m] has joined #farmos |
| [20:18:49] | * RobertDuncan[m] has joined #farmos |
| [08:28:35] | * tool172[m] has joined #farmos |
| [08:28:35] | <tool172[m]> | Is the Farm_bundle hooks with fields the same way to add to activity logs with the push hook for the old data on custom fields added to logs? |
| [08:28:49] | <tool172[m]> | basically per the page notes |
| [08:53:07] | <mstenta[m]> | Hi tool172 - just responded to your forum topic... :-) |
| [08:53:12] | <mstenta[m]> | https://farmos.discourse.group/t/proper-way-to-add-non-required-fields-t... |
| [08:54:10] | <tool172[m]> | i used the original way of declaring the field.field.log.activity.field_breeding_sire.yml |
| [08:54:57] | <mstenta[m]> | Oh ok, so not via the hooks described on https://farmos.org/development/module/ ? |
| [08:55:09] | <tool172[m]> | correct |
| [08:55:10] | <mstenta[m]> | Is this already deployed to a live databsae? |
| [08:55:18] | <tool172[m]> | the fields are there and verified |
| [08:55:27] | <mstenta[m]> | If not, I would recommend doing it the way described in https://farmos.org/development/module/ instead |
| [08:55:35] | <tool172[m]> | okay |
| [08:56:01] | <mstenta[m]> | There are two ways to define fields in Drupal... via config (like you did in the YML file) or via code. |
| [08:56:30] | <tool172[m]> | I did it via yml |
| [08:56:40] | <tool172[m]> | the display in the core on the hook is the problem |
| [08:56:42] | <tool172[m]> | the data is fine |
| [08:57:01] | <mstenta[m]> | farmOS has a bunch of special logic to automatically add expose fields in various places (lists of logs, csv importers, on the log view/edit pages, etc). But that only works if the fields are defined in code. |
| [08:57:46] | <tool172[m]> | which is through the field farm factory |
| [08:58:16] | <tool172[m]> | Basically I realized I can make a breeding module by adding two unrequired fields to activity logs and basically track everything through birth |
| [08:58:25] | <mstenta[m]> | Field farm factory is used to create fields in code (via the hooks documented in https://farmos.org/development/module/) |
| [08:59:00] | <mstenta[m]> | OK, you mentioned adding fields to an activity log... maybe you actually want to add fields to a birth log? |
| [08:59:10] | <tool172[m]> | nope |
| [08:59:14] | <tool172[m]> | I'm tracking gestation |
| [08:59:19] | <mstenta[m]> | OK |
| [08:59:34] | <tool172[m]> | I just want to add the bull, and the date |
| [08:59:43] | <tool172[m]> | the rest can be calculated automatically in a view |
| [08:59:56] | <tool172[m]> | then the view can point to the birth log |
| [08:59:58] | <mstenta[m]> | Maybe you want a new log type for insemination? |
| [09:00:13] | <tool172[m]> | drop down in the activity log for sire and one for type |
| [09:00:33] | <tool172[m]> | both activity logs to parent asset with breeding category |
| [09:00:39] | <mstenta[m]> | If you add those to activity logs, then they will appear on ALL activity logs... even ones that might have nothing to do with breeding |
| [09:00:45] | <tool172[m]> | saves all the headaches and keeps it tied to time/date and animal asset |
| [09:00:47] | <mstenta[m]> | That's why maybe a new log type is warranted |
| [09:00:55] | <tool172[m]> | but there not required fields so can be blank though |
| [09:01:20] | <mstenta[m]> | True. Just a suggestion. You can do it if you want. :-) |
| [09:01:23] | <tool172[m]> | I've gone back and forth with that in my head and read through the last 6 years or so of notes in the forums |
| [09:01:45] | <tool172[m]> | it would be easier with a new log type though |
| [09:01:47] | <mstenta[m]> | This is a good example where a new log type does make sense. |
| [09:02:09] | <tool172[m]> | i can drush clear it out and do that. It would be easier to make that contrib module :) |
| [09:02:13] | <mstenta[m]> | Curious how botlfarm handles this... |
| [09:02:29] | <mstenta[m]> | And others who breed |
| [09:02:54] | <tool172[m]> | I'm thnking too make a setup page in the module, then link species to asset to list and you could calculate some of the gestations automatically for a variety of animals |
| [09:03:02] | <tool172[m]> | I'm just cow/calf and small so i don't care |
| [09:03:09] | <mstenta[m]> | This describes how to add a log type: https://farmos.org/development/module/entities/ |
| [09:03:42] | <tool172[m]> | I'll keep working slowly |
| [09:03:49] | <mstenta[m]> | That also includes how to add a bundle field to the new log type |
| [09:03:52] | <mstenta[m]> | All in the same file |
| [09:04:04] | <tool172[m]> | I switched to cattlemax and they can't give me reports on grazing durations so I'm just starting to code it now |
| [09:04:24] | <tool172[m]> | can you add an option for dashed lines on mapbox as an option dropdown? I know it's in the api |
| [09:04:38] | <tool172[m]> | or where do you want the implementation request dropped. Github? |
| [09:04:45] | <mstenta[m]> | in what context? |
| [09:04:54] | <mstenta[m]> | "change ALL lines to dashed lines"? |
| [09:05:01] | <mstenta[m]> | or only in certain places/contexts? |
| [09:05:04] | <tool172[m]> | when creating a field |
| [09:05:12] | <tool172[m]> | choose dashed or solid and color |
| [09:05:14] | <mstenta[m]> | so only in the drawing tool context? |
| [09:05:27] | <tool172[m]> | yes so when you view it , it can be unique |
| [09:05:27] | <mstenta[m]> | or do you mean storing that choice somewhere as well? |
| [09:05:36] | <tool172[m]> | yes for rendering |
| [09:05:39] | <mstenta[m]> | geometries are not stored with any information about rendering |
| [09:05:58] | <mstenta[m]> | only the point/line/polygon information is saved |
| [09:06:16] | <tool172[m]> | so it would be a new field then since the api calls a wrapper i think. |
| [09:06:21] | <tool172[m]> | i looked at it last week |
| [09:07:28] | <tool172[m]> | // 2. Add the line layer with the dash pattern... (full message at <https://matrix.org/oftc/media/v1/media/download/AW2gUAImnaMQEY6ueuGIBIqR...) |
| [09:07:59] | <tool172[m]> | its an added layer.. don't know how hard that would be to add, but it would allow color with a drodown and dashed or not i suppose |
| [09:08:24] | <tool172[m]> | i would use something like that for overlays as I run poly cross fences and expand and contract as our summers dry up |
| [09:08:53] | <tool172[m]> | i just make new pastures with sub IDs. Like South 8, South 8.1, South 8.2, South 8.3 etc |
| [09:10:18] | <mstenta[m]> | Yea it's very easy to set the line style in OpenLayers... the problem is that farmOS doesn't have any way of knowing which geometries should be solid and which should be dashed |
| [09:10:37] | <tool172[m]> | I had another question too for the Grazing Plan module. Do I have to have the plan setup to just build a report on the movements? I care more about average report of Days of rest and days grazed than the rest of info. The goal is to stay out of the parasite lifecycle and the days grazed and rest periods show if I'm building forage |
| [09:10:46] | <mstenta[m]> | If you wanted to be able to select that when you were drawing, we would need some place to store that decision in the database |
| [09:10:57] | <mstenta[m]> | And then we could render it appropriately |
| [09:11:05] | <mstenta[m]> | But storing that would probably be tricky... |
| [09:11:19] | <mstenta[m]> | We use this module for geometry storage: https://www.drupal.org/project/geofield |
| [09:11:34] | <mstenta[m]> | That doesn't include any style information in its database storage... just geometry |
| [09:12:09] | <tool172[m]> | just food for thought, I know people have been looking |
| [09:12:14] | <mstenta[m]> | Question: instead of storing solid/dashed for every geometry... what if we rendered dashed lines just in certain contexts... |
| [09:12:42] | <tool172[m]> | That's kind of where I was thinking Like field vs paddock or use a flag that renders it |
| [09:12:55] | <mstenta[m]> | Maybe if we talk through your use-case a bit more, and why you want dashed lines, we could figure out a more general rule that could be applied automatically without needing to store the decision on a per-geometry basis |
| [09:13:08] | <mstenta[m]> | Feels like a good forum topic :-) |
| [09:13:24] | <tool172[m]> | I'm deep in making cattle module come to reality |
| [09:13:53] | <mstenta[m]> | tool172[m]: The Grazing Plan module is still "alpha" but you might find it useful, and it would be great to have more people testing and providing feedback! |
| [09:14:02] | <tool172[m]> | I'm testing it :) |
| [09:15:02] | <mstenta[m]> | The main thing it provides is a) data model (a grazing plan type with a grazing_event plan record that link to a movement log and stores: planned start date, days of grazing, and days of recovery), and b) a timeline visualization of the grazing events |
| [09:16:00] | <mstenta[m]> | So it just adds a bit more data model on top of the existing farmOS movement logs data model... specifically for keeping track of grazing days and recovery days (since that is not explicitly stored anywhere else in movement logs) |
| [09:16:03] | <tool172[m]> | that's the part I have a hangup with. I want to just move the assets there |
| [09:16:16] | <tool172[m]> | and it to update when I move em out |
| [09:16:22] | <tool172[m]> | then build the chart as the data comes in |
| [09:16:55] | <tool172[m]> | our plans our trashed already out here. we've had 37 inches of rain and where not into july yet |
| [09:17:35] | <mstenta[m]> | so you just want to be able to use it for reporting afterwards, not necessarily for planning ahead... am i understanding correctly? |
| [09:17:41] | <mstenta[m]> | it would work great for that! |
| [09:17:44] | <tool172[m]> | yea |
| [09:17:47] | <tool172[m]> | and a report |
| [09:17:54] | <tool172[m]> | with a list of fields/paddocks |
| [09:17:56] | <mstenta[m]> | you would just need to add the movement logs to it afterwards, and fill in the grazing days and recovery days |
| [09:18:21] | <tool172[m]> | why can't that be filled in if not null |
| [09:18:39] | <tool172[m]> | recovery is last used in time - moved back in |
| [09:18:45] | <mstenta[m]> | not sure i understand... can you describe more, or paste a screenshot? |
| [09:19:10] | <tool172[m]> | so if i made a table of pasture movement logs |
| [09:19:10] | <mstenta[m]> | grazing days is required for the visualization, recovery time is optional |
| [09:19:26] | <mstenta[m]> | (if i remember correctly) |
| [09:19:34] | <tool172[m]> | grazing days change based of forage. so If i pre put in 3 and it's 2.5 or 2 will it update? |
| [09:20:34] | <tool172[m]> | I'll draw it up in the forum once I get some time and traction. probably another 6 months. I want to get breeding reports and tracking finished -> then pastures. |
| [09:20:44] | <mstenta[m]> | let me try explaining the workflow i'm suggesting in a little more detail, then you can tell me if that fits, or why not... |
| [09:21:02] | <mstenta[m]> | at the beginning of the season, create a plan called "2026 Grazing Plan" |
| [09:22:26] | <mstenta[m]> | then move your animals to a paddock (in real life), and in farmOS use the grazing plan module w/ the movement quick form to record that as a movement, with anticipated grazing days and (optionally) recovery time. then, when you move them again, do the same thing... but you may have to manually adjust the previous grazing days/recovery based on what you experience in the real world |
| [09:23:08] | <mstenta[m]> | that last bit ("you may have to manually adjust the previous grazing days") could be a good feature request for automating that |
| [09:23:41] | <tool172[m]> | I saw that, I made a 2026 grazing plan |
| [09:24:08] | <tool172[m]> | I was just wondering if that report could be populated by the group movement logs between pastures/fields/paddocks |
| [09:24:53] | <tool172[m]> | it would be a report view i suppose. I see now why you did it that way |
| [09:24:57] | <tool172[m]> | it's faster to render the data |
| [09:25:17] | <mstenta[m]> | if you just want to generate reports after grazing, you don't necessarily need the grazing plan module... you could just look at the movements in the databasa and calculate the actual grazing days |
| [09:25:30] | <mstenta[m]> | you wouldn't have recovery time, of course... unless you were also tracking that with logs somehow |
| [09:25:47] | <mstenta[m]> | yea, another reason to use the grazing plan is to capture the "planned" vs the "actual" |
| [09:25:52] | <tool172[m]> | recovery time is the difference between movement into the same pasture |
| [09:25:58] | <mstenta[m]> | the grazing events record the "planned" grazing days and recovery time |
| [09:26:02] | <mstenta[m]> | but the logs capture the "actual" |
| [09:26:12] | <mstenta[m]> | tool172[m]: ideally |
| [09:26:22] | <mstenta[m]> | but it could be less too |
| [09:26:33] | <mstenta[m]> | eg: grass could recover before you move animals into it again |
| [09:26:50] | <tool172[m]> | valid. |
| [09:27:10] | <mstenta[m]> | eg: grass recovers in 15 days but animals aren't moved in until 30 have passed |
| [09:27:21] | <mstenta[m]> | that would be valuable information to have for future planning... |
| [09:27:26] | <tool172[m]> | ideally. rain changes that :) |
| [09:27:48] | <tool172[m]> | we get almost 40 inches by july, then we get like nothing until mid sept |
| [09:28:30] | <mstenta[m]> | yea... that's why we leave it up to you to fill in the "anticipated" recovery time in the module... veeeeery complicated to try to predict that 😆 |
| [09:29:15] | <tool172[m]> | good talk , I'm going to go continue cleaning up some storm damage |
| [09:29:52] | <tool172[m]> | i'll build a new breeding log then. I'll post my repo at some point |
| [09:36:36] | <mstenta[m]> | great! good luck with the cleanup! hope it wasn't too bad! |
| [09:36:45] | <mstenta[m]> | thanks for the good ideas and discussion |
| [09:46:56] | <symbioquine[m]> | According to my weather station, we're at just under 13 inches of rain for the year so far here and about 40 for the trailing 12 months. |
| [11:57:30] | <symbioquine[m]> | The farmOS weekly dev call starts in 3 minutes. All are welcome! https://meet.jit.si/farmos-dev |