Crop Plan Successions

[paul121]

Draft of ideas for crop plan successions

In general, a succession would be a way to manage plantings that are all of the same crop and follow a similar "timeline" (same days to transplant, days to harvest, etc.) This would make it easier to create plantings every X days, following the structure of the crop plan. This group of plantings could then be managed as one unit, separate of other plantings in a single crop plan, while still allowing access to manage individual plantings.

Data Structure

1. Would it make sense to make a succession entity (maybe an asset?) ? Thinking about linking crops, areas, etc... seems like it might be easier to do this by creating an entity, and allow for more options in the future?

OR

2. Succession (farm_crop_plan_succession table):
   • Plan ID (associated with 1 plan)
   • Succession Name
   • Crop(s)
   • Areas (?)

• farm_crop_plan_succession_plantings (is this table needed? or just a succession_id added to farm_crop_plan_plantings ?)
  • planting_id
  • succession_id
  • Succession # (to ID a planting as the 1st, 2nd, 3rd, etc planting of the succession) (or is it better to calculate this based on seeding date?)

Rough user flows + form design

• "Create a succession" form:

  • (plan ID is assumed)
  • Name
  • Crop(s)
  • Common seeding / transplanting / harvest "temporal" properties (days to transplant, days to harvest, etc)
  • Seeding locations: all in same area (specify now) vs individual (specify later)
  • Generate Plantings (different methods)
  • Create X # of plantings
  • Create plantings every X days
    • Limit to Y # plantings
    • Create until specified date
    • Limit by seeding date vs harvest date

• "Update succession":

  • Update name
  • Update crop(s) (?)
  • Update planting interval
  • Modify # plantings
  • individually delete
  • add X # plantings (append vs add at certain time? Tree view to re-arrange?)
  • extend succession start / end date, auto-adjust # plantings

• "Delete a succession"

  • Mass-delete plantings + logs

[mstenta]

Great ideas @paul121 !

One thought I've had is: "successions can be managed as a unit... until they can't". Meaning: at the beginning of the season you aim to have a really consistent and standardized set of successions, but reality inevitably messes it all up during the season.

So perhaps the ideal solution would be to allow you to "create a succession", which is essentially just a set of linked plantings, but also provide an option to split individual plantings out of the succession to be managed independently moving forward.

Although, to be honest, I have a feeling that will be more the rule than the exception, so maybe it doesn't even make sense to keep them linked after creation. eg: maybe the "succession form" is JUST a tool for creating individual plantings, but doesn't link them together after that. Just thinking: how often will plantings need to be "unlinked" from the succession. I have a feeling pretty often. So are we making it MORE work by forcing users to go through the additional step of "unlinking"? Or does keeping them linked provide enough value to outweigh that? This might be something we want to get more community feedback on before making any big decisions.

Assuming we do keep them linked, I think your second proposed database architecture makes sense (not entities). Summarized/simplified here (only including MVP data, I think):

{farm_crop_plan_succession}

• succession_id
• plan_id
• crop_id

{farm_crop_plan_succession_planting}

• succession_id
• planting_id

The first table defines each succession as a unique record, and the second table serves to link successions to plantings in the plan.

So then, "unlinking" would simply delete the record from {farm_crop_plan_succession_planting}, and the UI would then know to simply display the planting independently.