Just to be clear @graffte the pull request I created JUST adds a Seed asset type, with two fields: Crop/variety, and Season (both identical to the fields on the Plant asset type, which is what @Symbioquine used as a reference). The Seed asset will have all the default properties/relationships that assets have (described here). But the PR I created does NOT address the broader list of features that @mbomford listed in the original drupal.org feature request issue.
But, for the sake of comparison, here’s that list along with some notes/thoughts:
Crop - Use existing Crop/variety reference field.
Variety - Use existing Crop/variety reference field.
Botanical name - No dedicated field currently.
Family - Use existing Crop Family reference field.
Functional group - Not sure what this was for.
Supplier - Seeding log has a field for this. Might make sense to add one to Seed asset as well. Could also be recorded in “Seller” field of Purchase logs that reference the Seed asset.
Lot number - Seeding log has a field for this. Might make sense to add one to Seed asset as well. Could also be recorded in “Notes” field of Purchase logs that reference the Seed asset.
Date received - Record in a Purchase log probably.
Quantity received - Record in a Purchase log probably.
Date of last use - This could be recorded in Seeding log that references the Seed asset to adjust it’s inventory perhaps.
Quantity remaining - If you use inventory management on the seed management this is calculated for you.
Certified organic? - Use flags provided by the Organic module.
Sources checked for organic - No dedicated field currently. Recommend using Notes.
Seed treatment - Maybe a dedicated field would be useful for this, or just use the Notes field, if seed was purchased pre-treated and that is necessary to document. Or, if you are applying the treatment yourself I would use an Input log to record that personally.
Notes - Core field on all assets
Some of these things could be handled in different ways, depending on the use-case. For example, Supplier and Lot Number… I could see a case where you have a single “Corn Seed” asset, that tracks ALL your seed inventory, which actually comes from multiple suppliers with multiple lot numbers. In this case, it wouldn’t make sense for those fields to be on the Seed asset itself, but instead recorded with each Purchase log that increments that Seed asset’s inventory.
If that makes sense!
Lots of ways to slice these things… which is both an advantage (flexible data model allowing you to develop your own conventions), and a challenge (building higher-level features requires limiting the use-cases, which is why I also like to see that happen in UI modules, not at the data model layer).