"Date planted" in plant editor

[RoDuth]

Currently in the Plant Editor there is no way to store the date of planting.

In the Accession Editor there is Date Accessioned and Date Received but this does not necessarily reflect the day a plant was planted in the ground. With some accessions that can happily stay in their pots for a long time (e.g. Lomandra longifolia) we may receive a large quantity (say 300) from a supplier well ahead of the actual planting days. It would be accessioned at this point but no plants added. Then we may plant them in several locations over a period of potentially months. This, being one species from one supplier would be one accession with several plants attached to it for each of the different locations, all planted on different days.

This has concerned me from the start with Bauble, something I have had to work around with notes etc... I'm raising it now as I have been reminded of it again in issue #36.

[mfrasca]

if you think so, please add an extra note with category '' and value the iso-8601 representation of the intended date. I can implement this as a property for the time being, so you can refer to it from your report templates.

[RoDuth]

@mfrasca Its OK for now, I have been using Date Received as the first planting day and this kind of works but is a bit of a fudge as I mentioned. I would really like to see the field in the next milestone though and I guess date received would be its default value unless you alter it (so I don't have to go all my existing plant entries and enter it manually!). Things will be able to much more accurate after this. Thankfully this (financial) year isn't as big a planting year as it was last and will be next. So not such an immediate concern.

[mfrasca]

when this is implemented, it would be nice to include this information in the info pane and that it be linked to a search as plant where planting_date = |date|yyyy, mm, dd|

[mfrasca]

This issue was moved to Ghini/ghini.desktop#6

[brettatoms]

@RoDuth Sorry for not chiming in earlier on this issue but a "date planted" field is the job of the plant change system for maintaining a plants history. Whenever you edit a plant you record the change in the "Current change" section and it maintains a history of your changes. When you initially create a plant you're required to select a location and I'm pretty sure it records that initial change. It also comes with some nice features like when you duplicate a plant or divide a plant it maintains the plants change history.

[RoDuth]

@brettatoms thanks for this, but now how do I search it? Most of our new planting is done on community planting bee days, I need a way to be able to quickly and easily recall what was planted on those days as part of our reporting on community engagement.

Maybe there just needs to be a default reason like "initial planting date" that is visible when you first insert a plant? It would make it a lot more obvious, have used Bauble for years now and it never occurred to me that it was anything more than a way to track when the data was entered.

The only other concern I have is the fact that its not so easy to correct any mistakes with the changes functions (i.e. if you were to forget to set the date of planting when adding plants in the first instance and needed to change it). and then the risk of losing the correction in the results of any reports or searches. I guess you could just delete the whole plant and start again but that seems messy and if you had added photos and notes (not uncommon) at the time of entry...

In your opinion, would a separate field not solve any of these concerns or do you prefer the current method? I will have to trial it with the next set of entries I make at work.

[brettatoms]

@RoDuth I didn't realize there wasn't a way to search the plant changes. I'll admit I haven't used Bauble much over the past few years. It would be relatively easy to make the plant changes searchable.

Also, on a more technical note for someone that might want to add this, we could add a date_planted property to the Plant model that behind the scenes just queries the plant changes table. That way we wouldn't have the issue of two fields that means more or less the same thing but can have conflicting data.

[mfrasca]

I've added properties to models, like CITES and IUCN, but they are not searchable given the current search logic. they simply do not get considered by SQLalchemy. since these values are defined—SQLalchemy in the middle—on the opposite side as the database side, I would guess it is not possible to do what @brettatoms suggests. with pleasure I hear I'm mistaken. something that @RoDuth can answer is an other doubt I have, is it possible (as I would guess) that plant changes happen on a different date than the date_planted?

[RoDuth]

Yes, date of updating the record and date of actual planting can be quite different. Depending on my work load at the time. I guess I had always read the "change" as explaining why/when the user had up-dated or changed the record not why/when had the physical change occurred within the garden. Maybe this is just a change of mindset?

While I'm at it, the other issue I have had with the "Reason" for "Current change" field is that many of the options are things that may have made sense to 1 specific garden (UBC?) but not to me. (e.g. "Given to back 40 (FOG)" and "Transferred to Totem Field") this is another field that should be user defined similar to "type of material" #163

[mfrasca]

your last remark, does it relate to standards, or just to practice at your garden? that is: something Bauble/Ghini should try to respect, or something you would like to configure?

[RoDuth]

Not standard (at least I don't believe there is any standard that relates to this) just practice, so just a configurable field (like a note category or something) would be ideal. "Dead" is about the only one I actively use (and have searched against - but not being up to date enough its not really proved much use at this point).

[mfrasca]

the problem with a note is that it is not easy to use them in searches. you can already put notes and look at them as variables in reports. the point is: plant where notes.category='<planted>' and notes.note='2016-01-19' will give you all plants that have a note with category '<planted>' and a note with text '2016-01-19', but there is no guarantee the two requirements are satisfied by the same note. since #263, the plant object, when referred to in a mako report, has a planted field with the value '2016-01-19'.

[mfrasca]

@RoDuth can you open a new issue for:

While I'm at it, the other issue I have had with the "Reason" for "Current change" field is that many of the options are things that may have made sense to 1 specific garden (UBC?) but not to me. (e.g. "Given to back 40 (FOG)" and "Transferred to Totem Field") this is another field that should be user defined similar to "type of material" #163

(otherwise we end like in a library where »There are also letters on the spine of each book; these letters do not indicate or prefigure what the pages will say«)