Added "Maximum holding time" setting to services and analyses

[xispa]

Description of the issue/feature this PR addresses

This Pull Request allows the user to set the maximum holding time before it does no longer make sense to perform a given test. In the context of sample analysis, maximum holding time refers to the maximum duration a sample can be stored after collection before it must be analyzed to ensure reliable and accurate results. This period is established to prevent degradation, contamination, or chemical changes that could alter the sample's composition

For instance, testing for arboviral illnesses like Dengue, Zika, and Chikungunya might not make sense 5 days after the collection date. Likewise, identification of pathogenic microorganisms in a food sample won't make sense e.g. 2d after collection.

A new field "Maximum holding time" has been added to services and analyses:

On sample creation form, when the user selects a collection date that makes not possible to conduct a given analysis within the holding time, the service becomes not available for selection and an icon is displayed instead, along with an informative text:

Service is still available for selection from "Manage analyses" view though.

An alert icon is also displayed in analyses listing either when the result was captured past the holding time limit or when the holding time is about to expire:

--
I confirm I have tested this PR thoroughly and coded it according to PEP8
and Plone's Python styleguide standards.

[ramonski]

Cool stuff!

I played around with the Date Sampled field after the sample was created with an Analysis contained that had a max holding time of 1 day set. After I changed to the date of today, I got the following traceback:

Traceback (innermost last):
  Module ZPublisher.WSGIPublisher, line 176, in transaction_pubevents
  Module ZPublisher.WSGIPublisher, line 385, in publish_module
  Module ZPublisher.WSGIPublisher, line 288, in publish
  Module ZPublisher.mapply, line 85, in mapply
  Module ZPublisher.WSGIPublisher, line 63, in call_object
  Module senaite.app.listing.view, line 246, in __call__
  Module senaite.app.listing.ajax, line 113, in handle_subpath
  Module senaite.core.decorators, line 40, in decorator
  Module senaite.app.listing.decorators, line 63, in wrapper
  Module senaite.app.listing.decorators, line 50, in wrapper
  Module senaite.app.listing.decorators, line 100, in wrapper
  Module senaite.app.listing.ajax, line 383, in ajax_folderitems
  Module senaite.app.listing.decorators, line 88, in wrapper
  Module senaite.app.listing.ajax, line 259, in get_folderitems
  Module bika.lims.browser.analyses.view, line 808, in folderitems
  Module senaite.app.listing.view, line 982, in folderitems
  Module bika.lims.browser.analyses.view, line 797, in folderitem
  Module bika.lims.browser.analyses.view, line 1758, in _folder_item_holding_time
TypeError: can't compare datetime.datetime to str

[ramonski]

Great to have this removed. I see that this is already handled by the setProfiles method in the sample content.

[ramonski]

I tested it with profiles and templates and it worked perfectly.
The only issue seem to be when changing afterwards the Date sampled to today in the sample that has such an Analysis Service added

[xispa]

Cool stuff!

I played around with the Date Sampled field after the sample was created with an Analysis contained that had a max holding time of 1 day set. After I changed to the date of today, I got the following traceback:

Traceback (innermost last):
  Module ZPublisher.WSGIPublisher, line 176, in transaction_pubevents
  Module ZPublisher.WSGIPublisher, line 385, in publish_module
  Module ZPublisher.WSGIPublisher, line 288, in publish
  Module ZPublisher.mapply, line 85, in mapply
  Module ZPublisher.WSGIPublisher, line 63, in call_object
  Module senaite.app.listing.view, line 246, in __call__
  Module senaite.app.listing.ajax, line 113, in handle_subpath
  Module senaite.core.decorators, line 40, in decorator
  Module senaite.app.listing.decorators, line 63, in wrapper
  Module senaite.app.listing.decorators, line 50, in wrapper
  Module senaite.app.listing.decorators, line 100, in wrapper
  Module senaite.app.listing.ajax, line 383, in ajax_folderitems
  Module senaite.app.listing.decorators, line 88, in wrapper
  Module senaite.app.listing.ajax, line 259, in get_folderitems
  Module bika.lims.browser.analyses.view, line 808, in folderitems
  Module senaite.app.listing.view, line 982, in folderitems
  Module bika.lims.browser.analyses.view, line 797, in folderitem
  Module bika.lims.browser.analyses.view, line 1758, in _folder_item_holding_time
TypeError: can't compare datetime.datetime to str

Fixed with 48e7631

Note I use ANSIs to compare dates. Is useful for sorting and for preventing the infamous TypeError: can't compare offset-naive and offset-aware datetimes when comparing a TZ-naive datetime with a non-naive.

However, I now realized that this might lead to inconsistencies when the TZ of the collection date (DateSampled) is different from system's TZ.

To overccome this problem I am considering to add the param to_uc=False in to_ansi function, so it always tries to convert to Universal Time before formatting. This saves the developer from all dance re TZ conversion and naive cases before to_ansi is called. Or even better, I can use the parameter tz=None instead, so if tz is set, the system will try to convert to that TZ. Umm let me try this.

[xispa]

Note I use ANSIs to compare dates. Is useful for sorting and for preventing the infamous TypeError: can't compare offset-naive and offset-aware datetimes when comparing a TZ-naive datetime with a non-naive.

However, I now realized that this might lead to inconsistencies when the TZ of the collection date (DateSampled) is different from system's TZ.

To overccome this problem I am considering to add the param to_uc=False in to_ansi function, so it always tries to convert to Universal Time before formatting. This saves the developer from all dance re TZ conversion and naive cases before to_ansi is called. Or even better, I can use the parameter tz=None instead, so if tz is set, the system will try to convert to that TZ. Umm let me try this.

Pheew... had to go through api.dtime and resolve some inconsistencies with TZ conversions. Hope it becomes cleaner now.

[ramonski]

Works like a charm, many thanks for this!