"Acquisition" to group multiple accessions acquired at once from a single source

[sehrgut]

I'm not sure how useful this would be for the real target audience for bauble, but I'm using it to manage my garden and collection. It would be useful to me to be able to create an "Acquisition" object which grouped multiple Accessions (such as a large purchase from a vendor, or a number of cuttings gifted by another collector).

It would also be useful to be able to track purchase price for both Acquisitions and Accessions. At present, that must be stored in Notes, where it's difficult to report on. (That may be useful as a separate issue?)

[RoDuth]

I have asimilar issue with when the accessions all come from a field trip to collect specimens from the wild. If I collect 15 ferns for our native fern collection from the one 20m stretch of river bank then they all share the same geographic info (locale, region, lat/long or GPS datum, accuracy, altitude, habitat) but I have to type it in for each and every accession. There must be a way to speed this up in this scenario.

Maybe a copy/paste button for source details? So that you can click copy the first time you enter it and then paste it in for all the others accessions. Or an "extract source details from accession: foo" button? Which, when you click it, it grabs the data and auto fills. This would be great in other scenarios also, like when we do cover more area with some of our collection trips. All details are the same except slight differences in the lat/long of each accession, after grabbing or pasting the data in you could still edit it to capture the slight differences.

I know its not quite the same issue but it is related. Currently I create a new source for each collection trip with a unique name (including the date in the name). This allows me to search by that source name and find everything collected on that trip. This is may be one way you could deal with the original issue. If you create a new source for each Acquisition then you could sort by the one purchase. Gets a bit messy I guess. As it does with my collection trips as individual sources. If there was an Acquisitions object then I could just have a few collection trip types as Sources and then more specific info in the Acquisitions to link all items from a specific date. Still doesn't solve my issue of having slight variations in the lat/long data for individual accessions though.

Sorry that took me so long to explain!

[mfrasca]

I think what @RoDuth writes is related to #51 , something like "unless edited here: inherit from previously edited object". and I wonder whether Tag would help @sehrgut .

[mfrasca]

in case you do not need the source's ID, you could use that field to solve the issue. like in: accession where source.source_detail.name = 'Vivero Acme' and source.sources_code = '#150-3'

if the above does not solve the issue, please reopen! thanks.

for the price and new fields, see new issue #263

[mfrasca]

@sehrgut , when you write »stored in Notes, where it's difficult to report on«, can you elaborate that? why do you call it difficult?

[sehrgut]

Since Notes is a free text field, it has no semantics. This means that a report on "all plants from a given acquisition event" would need to make use of some notational convention WITHIN the notes field, that everyone editing the data would have to know and use consistently.

If, instead, there was an "Acquisition" object (or even field) which could model an acquisition event (e.g. "Purchase from on " or "Donation from collection of " or something like that, it would be trivial to discover all accessions from a given acquisition.

[mfrasca]

That (weak semantics) is indeed what we do now for plant coordinates, and for series of values. For the time being, that is to give us time to understand what usage is going to be made of this information, we're instructing users on how to insert coordinates, and data series (arrays and dictionaries), that are only available in reports and exports. Same goes for the CITES and IUCN fields, which seem to have never been actively used. Same again goes for URL of pictures.

But you see, there's such a wide range of requirements on extra fields to our objects, I cannot introduce a database change every time we add one, we need more flexibility. A change in database structure means data migration, a main show stopper for institutions in using a program, as far as my experience goes.

It's the "or something like that" that blocks me. Do you think you could help me take a more informed decision, let me understand what fields do you need in an acquisition event: show me how you're using this data, in queries, in reports, and how you're inserting it now in the database.

I am already considering adding typed data to the database (implies a change in the DB structure) (and I'm afraid I forgot to open an issue for this), but I want to do it well and for once, so we don't need to redo it later again. My initial thought was typed data in the form of native types (and geography), but if I look at your request, you're talking of defining your own structured type to add as an atomic note... That would be interesting, but introduces many more difficulties, for example when implementing queries, how to define the type definition, should we associate a note category to its type? so all notes of that category share the same type, forcibly?

Maybe not necessary to open a new issue, we can stay here, but we have to rename it once we agree on how to enhance the software.

[sehrgut]

Well, I'm not running an institutional collection, so my personal use case is:

I acquired these plants from the same source, I'd like an easy way to find all the plants I got from the same source over time.

So a new object type is simply the most obvious solution I saw to that problem. The data I personally would store in an acquisition event would be things like GPS coordinates for wild collection, contact information for nurseries, and URLs to invoices stored in Dropbox.

However, for me, just having an atomic name to tie all accessions in an acquisition together, even if I had to put that metadata in a freeform field, would still be useful.

[mfrasca]

still, from what you write, I don't see how the current Notes implementation isn't enough. can you give a very concrete example? not explaining, but showing, maybe in tabular form, what you would like to put in the database?

[mfrasca]

sorry, I had forgotten I promised we would handle issues on Ghini/ghini.desktop, not here on Bauble/bauble.classic. I'm going to migrate the issue there.

[mfrasca]

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