Q: Is it possible to have a list for an accessions "Intended Locations"? about ghini.desktop

[mfrasca]

what is your workflow with this regard?
you remind me of a no-go comment from the UBC garden, where they lamented the way Bauble handles plantings, and the inability to separate-join things within one accession. if I understood their comment correctly, this was something they use when they split plants (same accession) at several locations. then imagine they move a plant group to a location where there's already a plant group for the same accession, and they expect to be able to join groups.
it surely is possible to have a list of intended locations and it's good you mention this now because it does need a database change.

[RoDuth]

That sounds like a bad accessioning policy to me! We would give something planted in the same spot from the same source material a different planting number if it was planted at a different time (unless it was within a short period and was a straight forward replacement or the like).

Work flow is fairly straight forward basically its collection planning. Currently when planning for the next years planting (3500 plants a year on average, we are a young blank site that is growing fast) we use a spreadsheet then add it to the database when we plant. Its double handling and I feel we should be able to do this planning within the database and have been experimenting with it and I think, with a slight change, we should be able to do it.

So hypothetically: we start the record for an accession at the planning stage, when we are looking at what we are going to be planting in a new collection (e.g. we are going to be having a community planting day and are going to plant 500 trees in a "timber trees" collection) but don't fill in every field, e.g. the date received, just the ones we need at this point. We use the "intended locations" to show where we are looking to plant them and add a note for which planting bee date they are intended for. Then, when we receive the plants, we fill in the received date and when we plant them we create a plant entry for them and add the planting date (now that there is a spot to add it! 😃) If we decide not to plant something we either just delete the accession or remove one of the intended locations (this isn't possible right now, seems you can enter them but once they are there they are locked in and you can change them but not remove them).

What I would like to be able to get from the data is to be able to search for everything that has an intended location of garden bed XYZ or everything with a note for a set planting bee date (or both date and bed) or everything that isn't planted and is intended to be from a certain supplier or, of course, everything yet to planted. All things I think I could make queries for.

Do you think there is a better way to do this collection planning? I do have concerns about inserting accessions before they actually exist but can't think of a better way and it's a fairly critical part of my day to day work. I did think of having a second database for it and exporting/importing the data when it is planted but worry that it could get messy with an accession having a few plant entries and on different dates etc.. but you only want to import 1 of the plant entries at this point and will pull in the others later when they get planted. I need to get away from the current spreadsheet method!!

[mfrasca]

I think I follow you but do not see the problem.

why are you doing first spreadsheet then bauble and not directly into the database?

if you are clear that accessions with a blank date_received are things that you are still just planning, I do not see why you should not use this workflow.

is a tag unpractical here? it's a pity we cannot tag an object while we're editing it. what do you think if we would define a keyboard shortcut, so while editing something, you would hit ctrl-shift-t and the object would be tagged (with a selected tag). for this to work, the tag plugin should register a global keyboard shortcut, which would be active when any editor is open, and there should be a way to select the tag associated to the shortcut.

[mfrasca]

on the other hand, if you have advantages from the spreadsheet method, you only need transform it into a json file and import it in the database when you're comfortable.

[RoDuth]

That is what I'm trying to say, I don't want to be doing it in a spreadsheet first and then adding it to the database it's double handling. I want to be able to add it into the database when we are planing our next years collection expansions and planting days. My concern is I don't want to "pollute" the database with lots of inaccurate an irrelevant data. (Our first database began life as the landscape architects "procurement and design" database with thousands of entries about what species "could" be part of the various collections. Thing is it never got cleaned up to a reflect the as constructed state so I am currently in the processes of manually going through all the data and auditing the collection to see what does actually exist before I entering it into Bauble)

So for example, in any one year (being a large, young, developing garden on a blank site) we may be designing 10 to 20 new collections containing a total of 3000-4500 plants. Most of these collections would have sub categories, e.g. "Palms Walk" is broken up into 5 major global regions or "Ethnobotanical Collection" into various uses (medicinal, food, shelter, etc.) The issue is that planning involves a lot of research, brainstorming with stakeholders/landscape architects/etc, testing against our Living Collection Policy, risk assessing for weed potential etc. and looking for availability from suppliers etc. etc. so, in our current spreadsheet method, things are put in and then removed or the location changed or the numbers of plants are changed or what have you and this can take some time to "nut out" before a consensus is arrived at and we have a definitive planting schedule for the year. In its early days it is usual to have twice the number of species as we end up with on the list. Then we have to lock in dates (ideally each intended location should have an intended planting date and an intended number of plants for this purpose) based around our works program and community engagement programs. Of course then there are the little additions that creep in throughout the year also as replacements for damaged plants etc. So its a big ugly beast of a process and a big ugly spreadsheet.

As for why we haven't been doing this within Bauble already is two things, the concern of polluting the data with a whole heap of irrelevant data that will ruin search results, reports, counts, etc. and because of the limitations on the number of intended locations, it is quite common for us to buy a tray of 100 plants of one species and use them up throughout the years, planting them in almost every new collection (e.g. 10 locations). So that would be one accession with 10 intended locations and hence "plant" entries.

I know your going to tell me that I am expanding the brief as I go 😆 but I figure that if you can put an accession with zero quantity and no plants it would solve a lot of the polluted data concerns (it's easy enough to have an accession where quantity_recvd!=0 part to the query). But to do this I would need intended location int. date planted and intended quantity kind of like a list or table with 3 fields or columns. Does this make sense? This is another of those things that has been bugging me for sometime and I haven't brought up as I'm not sure I have the ideal solution but this one seems like it would work to me. I can't stand double handling the data by putting it in a spreadsheet then entering it into Bauble later.

[mfrasca]

@RoDuth, attach here one of those spreadsheets of yours! 💡
maybe not a full real one, but one with the full real structure.
and you have had a look at the new dynamic fields, that can be used in reporting? not useful to you here?

[RoDuth]

I'll have to grab the latest spreadsheet from work but have a few days off this week (public holiday, etc.) so it will have to be later in the week.

I did consider the notes/dynamic fields option but kept coming back to the fact that the "Intended Locations" functionality is already there, its just very limited. So much so that it's almost useless for me. It's one of those things, you either use it or you don't, and I had too many examples where it didn't work with just the 2 locations so I ended up not using it. Its a shame when there is a function that almost works but not quite, especially when it is such a big part of what we do here!

[RoDuth]

Procurement Living Collection.xlsx.zip

Example of the sort of planning spreadsheet we work with. This is greatly stripped back version, basically just copied out the sheet that is relevant, without any links, and left one entry in there. The last column has some basic explanations of what some of the less obvious columns are used for. It's fairly simple really just feels like double handling doing it this way when it could all be in the database.

[RoDuth]

@mfrasca I think this should be reopened (I can't as you closed it). Unless I've misunderstood or missed something I believe this feature has not made it into 3.1. This is a very useful feature for us.

[mfrasca]

port this to 3.2 please