Copy or Clone a Plan

[mstenta]

One of the things we've been thinking through is how to allow for the ability to save a copy of a plan that can remain unchanged at the beginning of a season, and then change/modify the real one throughout the season. This would allow you to look back and compare the two (plan vs actual). The only problem is that right now when you create rotations in a plan, it also creates movement activity logs that are linked to them. This means you would have a clutter of duplicate logs - some for the "plan" plan and some for the "actual" plan.

A simple solution to this (and maybe just a nice general feature to have) would be to make the log creation process optional. We could add a button to the effect of "Create logs" that you would press ONLY when you are done planning and want to put your plan into affect.

Once this is done, we could also add a general "Clone Plan" feature, so that you can create a plan, clone it, then generate logs from the second one. So as you go through the season you have your plan and your actual stored separately.

I am still interested in exploring more elaborate (and generalized) "plan vs actual" features in farmOS - but this is an easy step we can take which would allow for those comparisons in the grazing module right now. And would help to inform some of the more generalized design and planning.

[mstenta]

I say this is "easy", but that is in comparison to, for example, adding full-blown entity revision support in farmOS. There are still a lot of little details to cover in this, so it will take a bit of time to develop and separate the logs out cleanly into an optional step.

[mstenta]

I also don't see this as a "perfect" solution - but it might be "good enough" to be useful.

I'm thinking about scenarios where you create a plan, clone it, then want to update the plan AND the actual for whatever reason. You would have to update them separately - it would be difficult to replicate changes from one to the other automatically. Not impossible, of course, but difficult.

I don't think we should try to solve that now (or ever). It can be a known limitation until a more complete solution exists, in my opinion. And it will encourage being more deliberate about when you decide your "plan" is finished and you're ready to start the "actual".

[woodbri]

It doesn't sound like you can use this method to snap-shot a plan or to revisit that plan at the snap-shot point. I think it comes down to how would this feature be used? If the goal is to create 3-4 initial plan variations and then to select one of them and move forward, then this sounds like it would work. But if the use would be something like, I have a working plan that I have been implementing and things don't seem to be going well so I want to clone the current working plan and replan based on it as the starting point. The original plan has the original assumptions and plan and the actions that were taken and we want to save that state for later analysis, and build new plan moving forward that will be more viable at its conclusion than the initial plan, I'm not sure this scenario will work. Thoughts?

[woodbri]

How hard would it be to do a deep clone of a plan? For example:

• create a new plan_id and give it a new name
• copy the database tables and records replacing the plan_id with the new plan_id
• copy all log records to a new set of logs related to the new plan_id
• herd_ids are unique to a plan_id so they could stay the same
• paddock_ids are unique to the site and would not need to change
• rotation_ids are unique to a plan_id so they could stay the same
• consideration_ids are unique to a plan_id so they could stay the same
• other stuff???

[mstenta]

It doesn't sound like you can use this method to snap-shot a plan or to revisit that plan at the snap-shot point.

That's true. The main use-case this proposal would solve is the ability to have a "plan" separate from an "actual". And it would only be a workaround solution for that - the better "complete" solution would be to build a system around entity revisions so that every change is tracked. The difficulty, though, is how to summarize those changes in a simple way to the user.

I've heard requests for the ability to compare "plan vs actual" a number of times (both in the grazing module and elsewhere in farmOS), but in reality it is never as simple as just two ("plan" and "actual"). A plan may (will) change many times, and in many different ways. So if we want to capture all of that, revisions are the best option, I believe, but it's still hard to then summarize them. The simpler approach, which provides a very easy ability to compare the two, is what I proposed here: create 2 plans in the beginning, and only act on one of them. So you have a snapshot of before and after.

But if the use would be something like, I have a working plan that I have been implementing and things don't seem to be going well so I want to clone the current working plan and replan based on it as the starting point.

I agree that would not be solved by this particular feature (make log creation a second step), but I think it could be part of that solution as well. The common issue in both cases is that logs are created automatically when you add a rotation to a plan. If you just want to sketch something up, you don't want logs to be created. So by making the "log creation" piece a separate step, it would open up some possibilities.

How hard would it be to do a deep clone of a plan? For example:

It wouldn't be terribly difficult. Some things to think through - but largely the same process as cloning assets or logs, which is already possible.

I DON'T think we would want to clone all the logs, though. Because it would create a clutter of logs that you may/may not need.

I say we split this discussion out to a separate thread... there are a lot of other details to think through... with plan vs actual, cloning plans, etc. I think those other features would depend on this one, in either case.

[mstenta]

Also remember: logs and rotations are two separate records in the database. They are inexorably linked in the module right now, so they are essentially the same currently. I'm proposing that we unlink them, so that first you create the rotations as part of the planning process (in the {farm_grazing_rotations} table), and then you say "ok i'm ready to put this plan into practice" and then you click a button to generate the logs (and link them to the rotations at that point).

[woodbri]

I DON'T think we would want to clone all the logs, though. Because it would create a clutter of logs that you may/may not need.

I think I agree with this, maybe all we need is the current state of the logs and not all the history. It's hard to tell until we are asked to write specific reports and analysis to know what we may or may not need for them.

Regarding deep cloning, I think we should look into what this takes to do and maybe start with a shallow clone along the lines of your proposal. One concern I have is that I don't like the idea of the create logs button, that is a programmers convenience not something that users should have to worry about and adds a needless step. Maybe an initial step is a shallow clone that just copies the plan into a new plan without all the logs. This could use the separate create logs process as the final step in the clone process, ie: create a new plan and name it, copy the database tables to the new plan, then create the logs. All the existing code stays the same and doesn't need to worry about whether or not the logs were created because they will always be there.

Some smarts could go into the clone process to decide if we copy only the plan or we update the copied plan based on the current logs, for example adjust the head counts and weights to the current head count and weights based on the current log info. Likewise set the current herd locations based on the logs, etc. This would not copy the logs, just change or build the DB tables based on the current state of the plan being cloned and maybe when the logs are initialized, we need to set them up based on the current state, like locations, weights, head counts, etc.

[woodbri]

I'm thinking something like this, Under "Grazing Plans" page we have [+ Add grazing plan] and we add a button [+ Copy existing plan] which opens a form like the "Add Grazing Plan" form but starts with a select box to select an existing plan, that then populates the form with the values from the selected plan and allows the user to edit those values. Then below the "Add Grazing Plan" form we add the following questions about what to copy to the new plan:

• copy considerations
• copy paddocks
  • all paddocks
  • paddock selections
  • exclusions
  • productivity
  • recovery
• copy herds
  • ( ) as planned or
  • ( ) current in plan
  • projections
  • current locations
  • future rotations

[Save copy]

If the new plan has new dates, then some care should be taken to only copy data that is within the new plan dates. New logs would be created to represent the items in the new plan as copied.

[mstenta]

Had a call with Steve today where we dissected a lot of these thoughts. Still more to think through, but here's a quick summary of some points:

• We should make a more complete list of use-cases first, and work from that. Some use-cases that have come up include:
  • The general need to be able to see how a "plan" differed from an "actual" - and there are many different aspects to this. The "projections" data that was implemented recently covers some of this, but not everything.
  • The need to "replan" - ie: perhaps by cloning a plan, archiving the original, and continuing forward with the new plan
  • ... ?
• Plan cloning and separation of rotations/logs are two separate issues
• Deep clone vs shallow clone:
  • Shallow clone would clone everything BUT the rotations+logs
  • Deep clone would also clone rotations and/or logs, but this needs to be thought through more, at the risk of creating a bunch of duplicate logs.
  • As a first step, we could implement the shallow clone feature, then figure out the separation of logs/rotations, and then extend the cloning to allow for deep cloning

[mstenta]

With regard to implementing the ability to clone a plan (shallow or deep), we can use the existing "asset clone" and "log clone" features as a basis. This will keep things consistent. Currently those two entity type clone features do not provide settings during the cloning process, but we can add a settings form for plan cloning. Asset and log cloning are implemented as Drupal actions. Here is relevant code for the asset cloning, which can serve as an example:

Implementation of hook_action_info(): https://github.com/farmOS/farmOS/blob/7be4c7e19c15d7f33828d5b555961044d30391cc/modules/farm/farm_asset/farm_asset.module#L388

We would change "configurable" to TRUE to allow for a configuration form during the plan cloning process.

Here is the function that actually clones the assets: https://github.com/farmOS/farmOS/blob/7be4c7e19c15d7f33828d5b555961044d30391cc/modules/farm/farm_asset/farm_asset.module#L450

For an example of an action with a configuration form, refer to the farm_flags module: https://github.com/farmOS/farmOS/blob/7be4c7e19c15d7f33828d5b555961044d30391cc/modules/farm/farm_flags/farm_flags.module#L154

Once an action is defined, it can be added as a Views Bulk Operation button to the "All Plans" and "Grazing Plans" Views. Example: https://github.com/farmOS/farmOS/blob/7be4c7e19c15d7f33828d5b555961044d30391cc/modules/farm/farm_asset/farm_asset_views/farm_asset_views.views_default.inc#L155

One of the more complicated aspects of this will be handling different plan types. Plan entities themselves can be cloned easily using the examples above, but the Grazing-specific data will need to be handled by the Grazing module. The farm_plan module should provide a hook that allows other modules to add capabilities to the clone process - both to the cloning configuration form and to the cloning function itself.

I did something similar to this for Drupal's Ubercart system in the uc_order_clone module: https://www.drupal.org/project/uc_order_clone

https://cgit.drupalcode.org/uc_order_clone/tree/uc_order_clone.module

That was for Drupal 6, but it would work the same way in Drupal 7.

The way that worked is modules could define different "parts" of an Ubercart Order that could be cloned, and a callback function that performed the cloning. Then the uc_order_clone module simply displayed a list of checkboxes for each "part" of the order. So if another module added features to orders, it could implement that hook to enable cloning those parts as well during the general clone process.