Expired Filter Check Stuck at Server Start Date

[jacobfelknor]

Please verify that this bug has NOT been raised before.

• I checked and didn't find a similar issue

Describe the bug*

There is a bug in InvenTree/stock/models.StockItem.EXPIRED_FILTER

    # A query filter which can be used to filter StockItem objects which have expired
    EXPIRED_FILTER = (
        IN_STOCK_FILTER
        & ~Q(expiry_date=None)
        # THIS DATE IS "STUCK" TO WHEN THE SERVER STARTED!
        & Q(expiry_date__lt=InvenTree.helpers.current_date())
    )

The date used to compare the expiry date is forever the day the server started. This explains why the bug isn't present in development, because the server is constantly restarting.

This results in inaccurate "expired" vs "stale" badges on the stock item detail page.

I will submit a patch for this, unless someone beats me to it. I think we can fix this by adding a StockItem.get_expired_filter() which reevaluates this expression on each use rather than once at server start

Steps to Reproduce

1. Start server
2. create stock with expiry of tomorrow
3. wait 2 days
4. observe stock still doesn't show expired, because the server start date was before the expiry date

Expected behaviour

1. Start server
2. create stock with expiry of tomorrow
3. wait 2 days
4. observe stock shows expired,

Deployment Method

None

Version Information

NOTE: I'm behind, but checked source code in master to confirm bug is still present unless something else was done I'm not seeing to prevent it

InvenTree-Version: 1.1.11
Django Version: 4.2.26
Database: django.db.backends.postgresql
Debug-Mode: False
Deployed using Docker: True
Platform: Linux-5.14.0-611.36.1.el9_7.x86_64-x86_64-with-glibc2.41
Installer: DOC
Active plugins: [{"name":"InvenTreeBarcode","slug":"inventreebarcode","version":"2.1.0"},{"name":"BOM Exporter","slug":"bom-exporter","version":"1.1.0"},{"name":"InvenTree Exporter","slug":"inventree-exporter","version":"1.0.0"},{"name":"Part Parameter Exporter","slug":"parameter-exporter","version":"1.0.0"},{"name":"InvenTreeEmailNotifications","slug":"inventree-email-notification","version":"1.0.0"},{"name":"InvenTreeUINotifications","slug":"inventree-ui-notification","version":"1.0.0"},{"name":"InvenTreeCurrencyExchange","slug":"inventreecurrencyexchange","version":"1.0.0"},{"name":"InvenTreeMachines","slug":"inventree-machines","version":"1.0.0"},{"name":"InvenTreeLabel","slug":"inventreelabel","version":"1.1.0"},{"name":"InvenTreeLabelMachine","slug":"inventreelabelmachine","version":"1.0.0"},{"name":"InvenTreeLabelSheet","slug":"inventreelabelsheet","version":"1.0.1"},{"name":"DigiKeyBarcodePlugin","slug":"digikeyplugin","version":"1.0.1"},{"name":"LCSCBarcodePlugin","slug":"lcscplugin","version":"1.0.1"},{"name":"MouserBarcodePlugin","slug":"mouserplugin","version":"1.0.1"},{"name":"TMEBarcodePlugin","slug":"tmeplugin","version":"1.0.1"}]

Try to reproduce on the demo site

I did not try to reproduce

Is the bug reproducible on the demo site?

Not reproducible

Relevant log output

[PkLavc]

The issue is indeed that EXPIRED_FILTER is defined as a class-level constant, so InvenTree.helpers.current_date() is evaluated only once when the module is imported.

To fix this while keeping the logic clean, you can refactor it into a class method to ensure the date is evaluated at runtime:

@classmethod
def get_expired_filter(cls):
    return (
        cls.IN_STOCK_FILTER
        & ~Q(expiry_date=None)
        & Q(expiry_date__lt=InvenTree.helpers.current_date())
    )

[jacobfelknor]

Yep, that was my idea too. I submitted a PR