| [19:10:40] | * margeo[m] has joined #farmos |
| [15:15:29] | <paul121[m]> | Okay! I've learned more of the details for a research project our farm is hosting. We are looking at the benefits of fermented feed for chickens. For the study, there are 3 groups of birds that will get different treatments - dry, wet and fermented feed. Under this are 3 replicates (trials) of each group. In total there are 9 separate coops with 10 birds each |
| [15:16:48] | <paul121[m]> | Each bird is banded with a unique ID. We are collecting monthly bird weights, daily egg harvests from each coop, and measuring food and water both given and leftover each day. |
| [15:19:10] | <paul121[m]> | farmOS already provides a lot of this capability! woo! We can add all the individual birds, and group them hierarchically into their groups. Add observation logs (weight) and harvest logs (eggs) should be quite easy.. I'm looking for ideas for monitoring the feed/water information |
| [15:21:34] | <paul121[m]> | Could an observation log (or input log?) be added to a an area (an individual coop) or a group of animals? |
| [15:21:53] | <mstenta[m]> | paul121: Awesome! Yea I think most (if not all) of that is doable. |
| [15:22:05] | <mstenta[m]> | Re: monitoring feed/water info... I would suggest using Input logs. |
| [15:22:23] | <mstenta[m]> | Those can be associated with both areas and assets (the individual animals, or the group) |
| [15:22:42] | <mstenta[m]> | And they can have a quantity associated with them |
| [15:23:03] | <mstenta[m]> | So you can track quantitative data over time, associated with each group |
| [15:23:20] | <mstenta[m]> | You may also want to add a new log category, which you can use to flag logs that are part of the research project |
| [15:23:36] | <mstenta[m]> | So you can easily filter down to them in the future (if you are also using farmOS for non-research logging) |
| [15:23:55] | <mstenta[m]> | Although maybe that isn't necessary |
| [15:24:23] | <mstenta[m]> | I like to think of the "Input" and "Harvest" logs as general-purpose "ins and outs" for any asset |
| [15:24:50] | <mstenta[m]> | You put stuff in (food, water, fertilizer, fuel, etc etc) and you get stuff out (harvests, eggs, products, etc) |
| [15:26:03] | <paul121[m]> | Great - the input should work then. Quantities will be great for tracking |
| [15:27:26] | <paul121[m]> | Adding a special log type could be nice. Creating a quick form would be good too. These can both be done in one module, correct? |
| [15:28:13] | <mstenta[m]> | Yea |
| [15:28:31] | <paul121[m]> | Following the open source methodology I'm wondering if this could be abstracted. I was thinking of something like a 'Studies' module - perhaps like the 'Plans' module |
| [15:29:19] | <mstenta[m]> | Interesting idea... I've actually been talking with sudokita and @gbathree about a "Research farmOS"... thinking through some similar ideas. |
| [15:29:39] | <paul121[m]> | A study could be created, a link 'treatment groups' to groups of animals, or even planting. Perhaps other details of a study could be specified and create a 'dashboard' page for analysis |
| [15:30:01] | <mstenta[m]> | It might even make sense to use the existing "Plan" entity type - and create a "Research Plan" |
| [15:30:32] | <mstenta[m]> | Since "plans" are really just intended to provide a higher-level intentional organization of records around a particular goal |
| [15:31:44] | <mstenta[m]> | Although maybe a new entity type would be justified... |
| [15:32:00] | <paul121[m]> | Makes sense.. could a module create a "Research Plan" and add special things to that one plan? |
| [15:32:51] | <mstenta[m]> | Yea - that's the basic idea for plans... the farm_plan module just provides the entity type itself, but it relies on other modules to provide "Plan Types" (similar to asset types and log types), and additional UI+logic around them |
| [15:32:53] | <paul121[m]> | I know the answer to that question, yes. That is what Grazing does. |
| [15:33:02] | <mstenta[m]> | Yep :-) |
| [15:33:21] | <mstenta[m]> | "Research Plan" might be an interesting case to think through... |
| [15:33:26] | <mstenta[m]> | I wonder if a general purpose solution would work... |
| [15:33:37] | <paul121[m]> | What would the benefits be of a new entity type? |
| [15:33:38] | <mstenta[m]> | Or if you would find that "research" in general varies too much to really pin it down easily |
| [15:34:10] | <mstenta[m]> | The benefits of a new entity type would be complete control over how that entity type works... |
| [15:35:11] | <mstenta[m]> | That's also the disadvantage... you basically have to replicate everything that farm_asset and farm_plan do, and you would be responsible for maintaining that code moving forward |
| [15:38:18] | <paul121[m]> | So it's really a question of what features such a Research 'module' would provide. And what is (bare minimum) required to implement those features? |
| [15:39:37] | <paul121[m]> | Keeping the general aspects in mind. Perhaps it's almost an 'Analysis' framework |
| [15:39:54] | <mstenta[m]> | yea, and how those features would differ from the existing plan entity type |
| [15:40:24] | <paul121[m]> | A way to track specific inputs/harvests across groups of assets, and provide ways to analyze... also ways (quick forms) to collect the data |
| [15:40:48] | <mstenta[m]> | Yea that would be great |
| [15:41:09] | <mstenta[m]> | The other thing to consider, instead of new entity type, is just adding reporting/analysis features |
| [15:41:29] | <mstenta[m]> | Like creating a form that lets you generate a report based on certain criteria |
| [15:41:37] | <mstenta[m]> | That wouldn't need to be a separate entity |
| [15:42:58] | <mstenta[m]> | You only really need a new entity type if you want to leverage the stuff that Drupal's Entity system provides |
| [15:43:00] | <mstenta[m]> | https://www.drupal.org/docs/7/api/entity-api/an-introduction-to-entities |
| [15:43:21] | <mstenta[m]> | eg: the ability to create sub-types of the entity, with unique fields on each |
| [15:46:08] | <mstenta[m]> | It's also possible to simply create your own database tables and manage them without using the Entity stuff from Drupal |
| [15:46:08] | <mstenta[m]> | so there are levels of possibility, depending on what you need |
| [15:46:27] | <paul121[m]> | So a "Research Plan" would be a sub-type of the "Plan" entity? |
| [15:46:34] | <mstenta[m]> | Yea it could be |
| [15:46:43] | <mstenta[m]> | Similar to "Grazing Plan" |
| [15:46:48] | <mstenta[m]> | (on the same level, technically) |
| [15:47:33] | <paul121[m]> | Right. I saw you created tables for autofilling the soil disturbance information, yes? |
| [15:47:43] | <paul121[m]> | (But it just becomes another thing to manage) |
| [15:48:27] | <mstenta[m]> | Yea - a module can provide database tables that it is responsible for - so in that case, the farm_soil_nrcs module provides a table that comes prepopulated with STIR operations from NRCS |
| [15:48:45] | <mstenta[m]> | Which it then uses to auto-populate the disturbance quick form |
| [15:49:13] | <mstenta[m]> | (Notably, the module alters itself into the quick form, so if you turn off farm_soil_nrcs, the quick form still works, but doesn't have the STIR operation autocomplete) |
| [15:50:08] | <paul121[m]> | The Reporting/Analysis is interesting, too. I like the idea of a form to create a generate report. |
| [15:50:37] | <mstenta[m]> | Yea! That's always been something on the horizon in farmOS... reporting/analysis of data |
| [15:51:02] | <mstenta[m]> | I'd love to see more reporting features start to come together! |
| [15:51:29] | <mstenta[m]> | So maybe you could think through what the reporting requirements are for your purposes... and then think through what it would take to create those in farmOS |
| [15:51:42] | <mstenta[m]> | That will help to determine what the best approach is code-wise |
| [15:51:42] | <paul121[m]> | On a simpler level, could a "Research Plan" module let you create plans that create their own log type/flag you were talking about? |
| [15:51:52] | <mstenta[m]> | Maybe you'll find that you just need some general-purpose reporting |
| [15:52:04] | <paul121[m]> | Not only indicate that X asset is a part of research, but it is apart of a specific research plan? |
| [15:52:05] | <mstenta[m]> | That isn't even specific to research, but would be useful to anyone using farmOS |
| [15:52:35] | <mstenta[m]> | Yea... that's something that we're doing in the Grazing module... |
| [15:52:47] | <mstenta[m]> | But I have plans to make it more systematic in farmOS itself |
| [15:53:09] | <mstenta[m]> | Right now, the grazing module has a database table that it provides, which keeps certain areas and assets associated with a specific plan |
| [15:53:09] | <paul121[m]> | Certainly! Reporting has so many uses.. |
| [15:53:18] | <mstenta[m]> | But I want to move/generalize some of that logic |
| [15:53:34] | <mstenta[m]> | I have some notes/ideas for that jotted down somewhere... |
| [15:54:15] | <mstenta[m]> | Essentially: the farm_plan module could provide table(s) itself to maintain the link between a plan and other records |
| [15:54:35] | <mstenta[m]> | (And then the grazing module could migrate to using that general approach instead of providing it's own specific tables) |
| [15:54:38] | <paul121[m]> | Thats great. With that capability, I like the idea of using the Plan entity for "Research Plans" :D |
| [15:55:03] | <paul121[m]> | (easier to maintain!!) |
| [15:55:15] | <mstenta[m]> | yea! generalize and centralize! |
| [15:55:24] | <mstenta[m]> | the less code the better ;-) |
| [15:56:09] | <mstenta[m]> | Ah here we go... I actually started sketching up some of the code for the farm_plan module... |
| [15:56:10] | <mstenta[m]> | https://github.com/mstenta/farmOS/commit/609f3d1d455f230b1d958552a747f47... |
| [15:56:25] | <mstenta[m]> | That's just a wip (work in progress) commit in my personal fork of farmOS |
| [15:57:06] | <mstenta[m]> | It adds some new tables to the farm_plan module, as well as some code to enforce constraints on associated records (so you can't delete a log that's associated with a plan, for instance) |
| [15:57:48] | <mstenta[m]> | I believe I have an associated wip commit in the farm_grazing module too... |
| [15:59:03] | <paul121[m]> | So a "constraint" is a log/asset that is associated with a plan? The constraint is what protects these from being deleted? |
| [15:59:53] | <mstenta[m]> | A "constraint" is a bit more general than that... it's something I implemented in the farm_constraint module to help avoid people deleting records that are associated with other records |
| [16:00:10] | <mstenta[m]> | Drupal doesn't really prevent that on it's own |
| [16:00:51] | <mstenta[m]> | So if you, for example, have a log with an asset referenced, and you delete the asset: you end up with a log that doesn't reference anything |
| [16:00:51] | <mstenta[m]> | farm_constraint prevents that |
| [16:00:51] | <paul121[m]> | Oh, so farm_constraint is already in use |
| [16:00:57] | <mstenta[m]> | Yea |
| [16:01:56] | <mstenta[m]> | So that wip commit starts the process of adding some tables to the farm_plan module for maitaining links between records and plans AND enforcing a constraint so they can't be deleted |
| [16:02:31] | <mstenta[m]> | Right now, farm_grazing has similar (but more specific) code for doing that... with regard to areas and assets that are associated with grazing plans |
| [16:03:04] | <mstenta[m]> | https://github.com/mstenta/farm_grazing/blob/7.x-1.x/farm_grazing.farm_c... |
| [16:03:13] | <paul121[m]> | Right. Adding capability for a Plan to use constraints. Okay. I agree, this is important when you start cross referencing things... |
| [16:03:35] | <mstenta[m]> | Yea exactly |
| [16:03:57] | <mstenta[m]> | You COULD just implement your own constraints in your research plan module... |
| [16:04:07] | <mstenta[m]> | But ideally we could generalize that stuff into the farm_plan module |
| [16:04:31] | <mstenta[m]> | So neither Grazing nor Research would need to do it themselves |
| [16:05:06] | <mstenta[m]> | They would just use some general-purpose helper functions for creating the associations (eg: farm_plan_add_log($plan_id, $log_id) - this doesn't exist, but that's how i'm thinking about doing it basically) |
| [16:05:48] | <mstenta[m]> | (that's probably not what the function will be called - but you get the idea) :-) |
| [16:06:34] | <paul121[m]> | Makes sense! This sounds good. |
| [16:06:59] | <paul121[m]> | I'm going to keep brainstorming on "Research Plans" and what capability would be provided there. |
| [16:07:25] | <paul121[m]> | Also, think about reporting/analysis. That would be great, too. |
| [16:07:27] | <mstenta[m]> | Ok cool! Please feel free to create an issue in GitHub to brainstorm it! |
| [16:07:37] | <mstenta[m]> | I know that Ankita and Greg are very interested in similar ideas |
| [16:08:20] | <paul121[m]> | Ah yes. Good idea. Will be good to hear their input |
| [16:09:02] | <paul121[m]> | Are there any issues concerning reporting/analysis right now? |
| [16:09:33] | <paul121[m]> | Perhaps https://github.com/farmOS/farmOS/issues/48 |
| [16:10:25] | <mstenta[m]> | Yea that's a good list |
| [16:10:28] | <mstenta[m]> | Also just found this one: https://www.drupal.org/project/farm/issues/2399573 |
| [16:10:42] | <mstenta[m]> | Not a ton of details on any of those... |
| [16:11:25] | <mstenta[m]> | You could play around with writing some add-on modules if you want! |
| [16:11:40] | * Adam[m]7 has quit (Ping timeout: 268 seconds) |
| [16:11:40] | * zackmuma[m] has quit (Ping timeout: 268 seconds) |
| [16:12:08] | <mstenta[m]> | eg: modules that can be installed in farmOS, but aren't directly included in farmOS |
| [16:12:09] | <mstenta[m]> | Sometimes that's a good way to experiment/refine ideas - and then they can be pulled into farmOS core in the future if it makes sense |
| [16:12:59] | * zackmuma[m] has joined #farmos |
| [16:13:09] | * Adam[m]7 has joined #farmos |
| [16:13:15] | <paul121[m]> | Cool. Yes, that is what I was thinking |
| [16:13:43] | <paul121[m]> | Another question: how do you update modules? |
| [16:21:25] | <mstenta[m]> | You can see all the modules that are patched in drupal-org.make |
| [16:21:26] | <mstenta[m]> | https://github.com/farmOS/farmOS/blob/7.x-1.x/drupal-org.make |
| [16:21:27] | <mstenta[m]> | I generally try to make a release of farmOS whenever there is a serious security update to Drupal core or any of the contrib modules we include |
| [16:21:27] | <mstenta[m]> | But to answer your actual question: updating modules is simply a matter of replacing the module folder in the codebase, and then running /update.php to execute automated update functions |
| [16:21:28] | <mstenta[m]> | If you are developing a module, and you need to make updates to the database in between versions, you can implement hook_update_N() in your modules *.install file |
| [16:21:29] | <mstenta[m]> | https://api.drupal.org/api/drupal/modules%21system%21system.api.php/func... |
| [16:21:30] | <mstenta[m]> | Here is a very simple example of that that I just did today: |
| [16:21:31] | <mstenta[m]> | https://github.com/farmOS/farmOS/blob/7.x-1.x/modules/farm/farm_term/far... |
| [16:27:41] | <paul121[m]> | Okay. Starting to understand.. |
| [16:27:50] | <paul121[m]> | It will make more sense as I have to implement things! |
| [16:28:03] | <mstenta[m]> | Yea definitely :-) |
| [16:28:24] | <mstenta[m]> | There are lots of great tutorials for Drupal module development online |
| [16:28:36] | <mstenta[m]> | And farmOS provides a lot of examples of things to refer to |
| [16:28:56] | <mstenta[m]> | There's also a module called "Examples for Developers" for specific Drupal things: https://drupal.org/project/examples |
| [16:29:00] | <mstenta[m]> | Highly recommended |
| [16:32:38] | <paul121[m]> | That looks very helpful! Good to have many options to refer to |
| [16:34:00] | <paul121[m]> | Appreciate the help and ideas. Will follow up with further questions and findings... |
| [16:34:25] | <mstenta[m]> | Awesome good luck paul121 ! Happy to help if you have questions! |