@ramonski forced me to start a topic about the need of secondary sample functionality, that has (temporarily?) disappeared in the current development after the great concept change from ARs to samples as the main entity.
At the moment secondary samples are created only after invalidation with a new sample id ruled by the id-server. Additionally you can copy an existing sample into a new one.
I still see several use-cases, where those ways are not sufficient, e.g. because invalidation isnât wanted or copying sample will not keep the original sample id or received date.
Examples:
client requests supplementary analyses after publication
wrong analysis profile
client requests a full retest for whatever reason
report should contain primary and secondary AS of a sample bound together
simply change sample metadata after publication (client feedback)
client or other client (edge case) requests independent additional analyses
no one wants to change/add labels and stickers of samples and partitions out of the storage
Surely some of you will see moreâŠ
In senaite up to 1.2 I liked the possibility in AR registration to choose an existing sample to create a secondary request on that.
This might be a useful way for this task.
Creating new sample ids can be OK, if senaite links primary and secondary samples similar to invalidations.
At least the old concept of analysis requests using a suffix to the sample id was a smart idea for this case.
Maybe the partition functionality can be adapted for this purpose?
Thanks @grulisco for sharing your thoughts and use-cases.
@xispa and me discussed already some possible ways how to implement this in the system and thought about âproxyingâ (passthrough) of the initial Sample fields to the secondary Sample (aka AR in Senaite up to 1.2.9).
However, I think it might be all done in the Add Form by a simple checkbox âSecondaryâ, stating that this is a secondary Sample. Then the Core machinery would do the linkage and mark the Sample with an interface like in https://github.com/senaite/senaite.core/pull/1228 (well done @xispa!).
The ID could then be correctly generated and the received date could be set according to the original Sample when receiving the secondary.
The only disadvantage (advantage?) is that changes in the original Sample are not visible in the secondary Samples, because the values are copied and not passed by reference. This was especially the case in Senaite up to 1.2.9, which I think was confusing to the user because of this implicit side-effect.
@mgarner19801 , we are referring to senaite.core 1.3 (current master branch from senaite.core repository). This new version will be released within the following days.
Yes @leo, secondary samples functionality has been incorporated into Senaite 1.3. It follows the same approach as before, except that the suffix that comes by default with secondaries is now S-01, S-02, etc. Check the Pull Request for further info: https://github.com/senaite/senaite.core/pull/1284