[Bug]: expiring-alerts shows 0 expiring assets in 8.3.2 and 8.3.3

[scs-dst]

Snipe-IT Version

v8.3.3 - Build 20061 (master)

PHP Version

8.3.6 cli, 8.3.6 (web)

Composer Version

2.8.12

MySQL/MariaDB version

MariaDB 11.4.7

How did you install Snipe-IT?

Docker

Is this a fresh install or an upgrade?

Upgrade

What happened?

2 days ago we updated from v8.3.1 to v8.3.3 in a docker setup. From then on, we didn't receive notifications for expiring assets via mail anymore (but expiring licenses). I then ran php artisan snipeit:expiring-alerts and got the result (which is the same with version 8.3.2: 0 assets with expiring warranties, 10 licenses expiring.
With 8.3.1, I get: 25 assets with expiring warranties, 10 expiring licenses (which is correct). As soon as I downgrade to 8.3.1, the notification via mail for the expiring assets also works again.
The expiring alarm is set to 30 days.

What browsers are you seeing the problem on?

Chrome

Can you reproduce this on the public demo?

N/A

Do you have full multiple company support enabled?

Yes

If you have full multiple company support enabled, do you have location scoping to company enabled?

I do not have full multiple company support enabled

Application log output

The logfile is empty. I enabled debugging in the .env, ran php artisan config:clear, restarted the containers and ran php artisan snipeit:expiring-alerts again. Log is still empty.

Browser console output

Common Issues

• I have searched this repo for existing issues related to my issue (including closed issues)
• My APP_URL is set correctly in my .env file (including http or https and no trailing slash)
• I have searched the official Snipe-IT documentation and have checked the Common Issues documentation (where applicable)
• I have run database migrations (where applicable).
• I have attached screenshots and/or videos of the issue (where applicable)

Code of Conduct

• I agree to follow this project's Code of Conduct

[snipe]

Hm, not having any luck reproducing this.

[scs-dst]

Thanks for the quick response! That's interesting. I'm sitting in front of another Snipe instance, also running on 8.3.1. I updated it to 8.3.3 a moment ago and I have the exact same issue. Is it maybe a localization-thing? Just thinking, because the output is mixed language and the output style completely changed after 8.3.1. How can I completely the localization? Is it sufficient to change it in the admin settings for a test?

[snipe]

I'm sitting in front of another Snipe instance, also running on 8.3.1.

Oh I 100% believe you, it's just tough because I cannot reproduce it :(

We did change a bunch of things in expiring assets recently - notably these two:

• Expiring alerts improvements, UI tweaks, tooltips on BS tables buttons #17982
• Fixed nesting in orWhere #17875

but I kinda don't see anything in there that would have bonked this.

You're still showing the 10 that are expiring in v8.3.3, yes? (That first screenshot). The cli itself is just reporting 0 in the "there are blah" bit? Or am I misunderstanding?

[snipe]

The code that's determining that list is here btw, in case anything stands out about own own data set:

snipe-it/app/Models/Asset.php

Lines 924 to 953 in b91d230

	/**
	* Return the assets with a warranty expiring within x days
	*
	* @param $days
	* @author [A. Gianotto] [<snipe@snipe.net>]
	* @since [v2.0]
	* @return mixed
	*/
	public static function getExpiringWarrantyOrEol($days = 30)
	{
	return self::where('archived', '=', '0')
	->NotArchived()
	->whereNull('deleted_at')
	->where(function ($query) use ($days) {
	// Check for manual asset EOL first
	$query->where(function ($query) use ($days) {
	$query->whereNotNull('asset_eol_date')
	->whereBetween('asset_eol_date', [Carbon::now(), Carbon::now()->addDays($days)]);
	// Otherwise use the warranty months + purchase date + threshold
	})->orWhere(function ($query) use ($days) {
	$query->whereNotNull('purchase_date')
	->whereNotNull('warranty_months')
	->whereBetween('purchase_date', [Carbon::now(), Carbon::now()->addMonths('assets.warranty_months')->addDays($days)]);
	});
	})
	->orderBy('asset_eol_date', 'ASC')
	->orderBy('purchase_date', 'ASC')
	->get();
	}

[scs-dst]

I'm sitting in front of another Snipe instance, also running on 8.3.1.

Oh I 100% believe you, it's just tough because I cannot reproduce it :(

We did change a bunch of things in expiring assets recently - notably these two:

• Expiring alerts improvements, UI tweaks, tooltips on BS tables buttons #17982
• Fixed nesting in orWhere #17875

but I kinda don't see anything in there that would have bonked this.

You're still showing the 10 that are expiring in v8.3.3, yes? (That first screenshot). The cli itself is just reporting 0 in the "there are blah" bit? Or am I misunderstanding?

The 10 expiring are licenses. These work in any 8.3.x version for me (in the cli and in the mail notifications). Only the 25 expiring assets are reported as "0" in 8.3.2 and .3.

Unfortunately I have very limited understanding of code (I sort of get what's going on when it doesn't get to wild, but can't follow along every line).

All I could do are further tests if you have any idea what I could try to help finding the issue.

[snipe]

Ah, I see - the table in the v8.3.3 scree shot is licenses, not assets. (I don't speak German, so was having a hard time parsing those headers)

Your assets are not already expired or EOL, and not archived, or deleted, right?

[scs-dst]

Correct, we have 25 assets, which are not deleted, archived and have expiring warranty in the coming 30 days. I think expired corresponds to "Ende der Nutzungsdauer" (="end of usage")? And end of life would be warranty expired, correct? Then these are not expired and still in use.

[snipe]

That query (at least in theory) checks for assets for non-deleted, non-archived assets and THEN:

• Does the asset have a manually entered value for asset_eol_date, and if it does, is that date between right now and the threshold (in your case 30) days from now
• OR if it does not have a manually entered asset_eol_date, is the purchase date between right now and the number of months the warranty is set for, plus the threshold.

[snipe]

Hm, I just tried after switching my locale in my env to de-DE and I get the same result, so I don't think the locale is the issue.

[scs-dst]

Thanks for the check! The interesting part about this is, that there is no warranty expiration date shown in your screenshot, I just realize that the same is true in the english output that you first showed. Then this should be the problem?!

If only a purchase date and, for example, 12 month of warranty are set, the warranty expiration date should be set to 12 months later, correct? But these fields are empty. So the code queries the wrong fields?

For further clarification: on the asset page when editing, the field below "purchase date" is empty on all our assets. Is this the field/value that is used to filter for expiring assets?

Unfortunately I can't manage to switch my locale to US, I tried changing locale + timezone in the env plus changing the locale in the admin settings, but everything stays german. I even tried cache:clear etc. but no luck. So I can't compare it myself..

[snipe]

You'd need php artisan config:clear I think to clear your .env. I also just pushed out a few changes - can you do a fresh pull from master and see if it's any better?

[scs-dst]

I tried config:clear before already, it doesn't seem to help (at least for the web view; the cli output turns to english, when I change the env settings).

Anyway - I am not shure what you mean with "pull from master". What I did:

• Switch back to version 8.3.1
• docker system prune --all
• change the config back to 8.3.3
• docker compose up -d (which then pulled version 8.3.3 from snipe/snipe-it)
  Was that what I should test? If yes, the result is still the same.