Why is Unassigned considered a Previous Owner?

Hi ​@jo.cpa ,

I hope you’re doing great! In the process you mentioned above, when the device is checked-in and assigned to another user, the “Previous Owner” field’s data shows “Unassigned” instead of the previous owner in the timeline, is that correct?

I look forward to hearing from you!

Regards,

Jas

Hello ​@JDhanjal_iiQ - I work with ​@jo.cpa and this is what we notice: 

1. Device is returned and checked in. 
   • This step unassigns the current owner → [Owner] = [blank]
   • The owner is then added as the previous owner → [Previous Owner] = [user that was just removed from device]. 
2. Weeks later (example), the same device is assigned to a new owner. 
   • This step assigns the new owner → [Owner] = [new user]
   • The “Previous Owner” field is then left blank → [Previous Owner] = [blank]
     • This happens even though there hasn’t been a user in between the actual previous owner and the new owner. 

It seems like the system is considering “Unassigned” an owner in between owners.

• When a device skips the “unassigned” state and simply goes from being check out from one student to another in one step, the previous owner reflects the previous user. 
• When a device gets “unassigned” from one user first and is then assigned to a new user afterward, the previous owner field is completely blank when the new user is added. 
  • Even though the previous owner was an actual person… they don’t remain listed as the previous owner if the device is unassigned at any point. 

Hope this helps you understand!

Related to this, it would also be really useful to have an asset timeline/history view on user pages so we could see any devices previously assigned to them. In an ideal world, we’d like to have a comprehensive asset assignment history report that shows all previous owners and assignment history in one place... for now though, the Previous Owner field isn’t reliable for auditing or backtracking devices.

​@DLeyden 4909d0d pca While there is not a designated “Asset” timeline/history view on a user page, there is a history of all actions on a user that does show history of assets assigned to that user! If you click into a user’s profile and scroll down to “Revisions” and expand. Here, you can see where users have had assets assigned/unassigned to them, you can see what it looks like from my test site below:

Hope this info is helpful!

​@Karen.Tirado.CPA 
 

You are exactly correct. When the system is looking for previous owner it only sees what was populated in that field prior to the current user. It does not differentiate between unassigned owner and a user.

This would be a great product enhancement idea. You can share this idea by clicking on the link shared below.

https://community.incidentiq.com/ideas

THANK YOU!

I don’t get this… something that is not Assigned considers an Unassigned “Owner”.  It doesn’t make any sense.  

As in… A system that has an asset that is not Assigned has a report that considers an Unassigned “Owner”.  It doesn’t make any sense.

Here is what AI says about it.
 

That scenario is a classic example of an oxymoron or a logical contradiction.

In software development and database design, this specific issue is often called an architectural anti-pattern or a data inconsistency.

Here are the best terms to describe this specific situation:

Technical & System Terms

• Contradictory: The system's logic simultaneously asserts two opposing states (it has no owner, but that "no owner" is the owner).
• Paradoxical: It creates a logical loop where a negative state (Unassigned) is treated as a positive entity (an Owner).
• Oxymoronic: It uses a self-canceling phrase, like calling something an "Unassigned Owner."
• Incoherent: The system architecture lacks a consistent internal logic.

User Experience & Design Terms

• Counterintuitive: It goes completely against how a human naturally expects a system to work.
• Absurd: The design defies basic operational logic to a ridiculous degree.

Why Systems Do This (The Root Cause)

This usually happens because of lazy database design or technical debt. The system likely requires the "Owner" field to always have a value (it cannot be blank or NULL). To bypass this rule, developers create a fake user profile named "Unassigned" to fill the blank space, creating this logical mess.

If you are writing a bug report or feedback for the development team, I can help you draft a technical ticket or suggest the proper database fix to bring to your team.