User is removed when asset is Archived/Pending

[mihaiolimpiu]

Debug mode

• I have enabled debug mode
• I have read checked the Common Issues page

Describe the bug

When an asset is Ready to Deployed and it's status goes to a status with Archived/Pending type, the user is removed from the asset.

For archived, this might be a bug or depending on the logic you applied not.
For Pending, definitely a bug.

We have the following statuses set to Archived:

SOLD - Last user is important information
STOLEN - Last user is important information
Donated (Needs to be checked in first)
Written Off (Ceased) - (Depends)

In all the above cases it would be beneficial to know the user it was assigned, for tracking purposes.

Hope this clears it up.

Reproduction steps

1. Select a Ready to deploy asset that is assigned to an user
2. Change it's status to archived
3. Check the asset
4. User is removed.

Expected behavior

User should not be removed, as the assets are Archived and do not interfere with regular operation.

It helps to know if someone is abusing company policy in buying old hardware and also past history (stolen, missing items.

Also:
When using the bulk edit menu to go through the same status change, the user is not removed, as both menu actions should be consistent.

The only case when the user should be removed is when the asset is checked in.

Screenshots

No response

Snipe-IT Version

v6.1.2 build 10938

Operating System

Red Hat

Web Server

Apache

PHP Version

8.1.21

Operating System

Windows 11

Browser

Chrome

Version

115.0.5790.102 (Official Build) (64-bit)

Device

No response

Operating System

No response

Browser

No response

Version

No response

Error messages

No response

Additional context

This is an upgrade.

[mihaiolimpiu]

So the issue is better understood:

To be returned by who? asset is still assigned to that user, and it's wrecking havoc in our department.

Agree, old user is visible in history, but that requires to go to that page, and when the item is checked in, as there is no user assigned, no handover paperwork is done. Quite a problem from a legal standpoint.

P.S.: To be returned is part of the "pending" so these are affected too, not only archived statuses.
This is definitively a bug.

[snipe]

I don't think this is really a bug exactly as it is a misunderstanding or misuse of the workflow. If an item is in an archived or pending state, there wouldn't be a user associated with it. That would still be a Ready to Deploy status, since it's still currently checked out.

[mihaiolimpiu]

@snipe Partially agree with your logic for the archived items as an user should not be assigned (Yes we used it for tracking, and it was useful).

For Pending, we used it for Being serviced and To Be returned and it worked as described according to the documentation.

I changed the status labels type to Undeployable and now it works as expected after I checked the demo page.
Still this is a change that wasn't advertised? We're using Snipe It for years.

If you confirm this is the logic you're after I guess this can be closed, and this should reflect in the status labels as for now, I'm sure no one gets the difference:

Current description:
-Deployable: These assets can be checked out. Once they are assigned, they will assume a meta status of Deployed.

-Pending: These assets can not yet be assigned to anyone, often ??used for items that are out for repair, but are expected to return to circulation??. / Doesn't this mean it was perfect for Out for repair?

-Undeployable: These assets cannot be assigned to anyone but they're retaining the current user, used for items that are out for repair, but are expected to return to circulation .

-Archived: These assets cannot be checked out, and will only show up in the Archived view. This is useful for retaining information about assets for budgeting/historic purposes but keeping them out of the day-to-day asset list. / User is removed

[StarlessNights]

I ran into a couple related issues with regards to the archived status, and the fact that it removes the assigned user (and probably other types of assignments as well).

1. When a checked out asset is modified to an Archived type status, there will be no entries generated in the assets history tab. Perhaps something goes wrong behind the scenes?
2. It's possible to create a checked out Archived asset from the API. E.g. like this:

POST /hardware
{
  "status_id": 3,
  "model_id": 19,
  "assigned_user": 1
}

Both seem like bugs to me.

[snipe]

When a checked out asset is modified to an Archived type status, there will be no entries generated in the assets history tab. Perhaps something goes wrong behind the scenes?

This was already fixed a few weeks ago

It's possible to create a checked out Archived asset from the API. E.g. like this:

If that's still possible, it's a bug. An archived status should never be able to be checked out to.

[snipe]

@StarlessNights this might resolve the API bug allowing checkouts to non-deployable status types: #15547