Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Seed Units #7

Open
skalakm opened this issue Feb 27, 2015 · 5 comments
Open

Seed Units #7

skalakm opened this issue Feb 27, 2015 · 5 comments

Comments

@skalakm
Copy link
Contributor

skalakm commented Feb 27, 2015

Well, I've been messing with the .php in the Seeding / Order folder, and I can get the Order database to give me EACH in the dropdown menu of GRAM, OUNCE & POUND. But it's obvious there's a lot more to this, because it won't remember my inventory of broccoli. I can get it to remember my different varieties, but because GRAM is too broad of a term for how I'm planting--I need something much more fine-grained--I would like to count my seeds by # of seeds, not by grams. With seedlings and with large plants like brassicas, a market gardener on small acreage is thinking it terms of # of plants in the beds. Not sure how hard it would be to get that fine grained.

ALSO, it would be nice to be able to delete some default seeding tray units. I do soil blocks, and my tray numbers are completely different than the regular plastic trays that are discarded eventually.

Thanks.

Reported by: postcarbon

@skalakm
Copy link
Contributor Author

skalakm commented Feb 27, 2015

Adding another seed unit is MUCH more complicated than just adding it to the dropdown. FARMDATA stores seed inventory internally in grams, so everything gets converted to grams in the inventory, order and flats and direct seeding input forms. Adding EACH as a unit would mean adding to the conversions performed in all of those places. I'll put this on the list of requested features, but that list is getting a bit out of control at this point and I can't make any promises as to if/when we would get to it. As a workaround, you could use the seed calculator in the seed order and inventory input form to calculate the number of grams for whatever number of seeds you are working with. No problem to have that open in one browser window while you are using other FARMDATA features in another window.

On the seeding trays, it would be easier to add that feature. I'll put it on the list as well. If you are comfortable using something like phpMyAdmin, you could even connect directly to your database and delete rows from the flat table that way.

Original comment by: wahlst

@skalakm
Copy link
Contributor Author

skalakm commented Feb 27, 2015

Yes, peeking into the various phps, I can see that the GRAM is used everywhere, and you've got lots of calculations all over the place. I figured it was probably a big task, and certainly you wouldn't want to revamp the entire system. I still haven't quite figured out how the grams relate to the seeds--it seems that I have to decide on a number of seeds per gram for each type of vegetable, but in practice it's clear that even different varieties within a vegetable can vary greatly. Think beans. Even my broccoli has significant differences in # of seeds per gram between varieties.

I am comfortable editing the php, slightly. Tiny tweaks. Can you tell my which file has the flats info?

Thanks for your very fast responses to these tickets.

Original comment by: postcarbon

@skalakm
Copy link
Contributor Author

skalakm commented Feb 27, 2015

Yes, I understand the problem. You are right that FARMDATA wants a fixed number of seeds per gram for each crop. So it works if we are talking different crops, but it doesn't work if there is a lot of variation in seed size/mass between different varieties of the same crop.

If you want to hardcode a solution to the cells/flat problem, take a look at Seeding/gh_seeding.php around line 110. You could just hardcode in the options for the flat sizes that you want rather than retrieving them from the flat table. I think that will work as long as all of the sizes that you actually use are also in the table, and you are just doing this to "hide" the sizes that you don't want.

Original comment by: wahlst

@skalakm
Copy link
Contributor Author

skalakm commented Feb 27, 2015

  • status: open --> pending

Original comment by: wahlst

@skalakm
Copy link
Contributor Author

skalakm commented Feb 28, 2015

I had a few minutes this morning, so I added a form for deleting a flat size (and updated the download). Go ahead and try upgrading now - should also fix the problem with showing inactive fields.

Original comment by: wahlst

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant