Clarify asset department/location vs holder department semantics

[jnes0824]

Background

On the asset detail page, after assigning an asset to a newly created holder, the page still shows the asset's original Department / Location. For example, after assigning AST-2026-00013 to a new user, the detail page still shows the demo-seeded values 資訊維運部 / 新竹 Fab12 行政樓.

This does not appear to be a simple API routing issue or an incorrect backend join. The current data model stores separate fields for users and assets:

• users.department: the user's organization department
• assets.department: the asset's owning/using department
• assets.location: the asset's physical/storage location
• There is currently no users.location field

The asset assignment flow currently updates the holder, status, and assignment date. It does not synchronize assets.department or assets.location from the assigned user.

Why this needs discussion

The UI currently labels these fields simply as Department / Location. Users may interpret them as the current holder's department/location, while the current API/design docs suggest they are asset-level fields.

This creates confusion:

1. A newly registered user has a department, but the asset detail page may show a different department after assignment.
2. Reassigning an asset changes the holder but leaves the asset department/location unchanged.
3. It is not obvious whether the detail page is displaying asset attributes or holder attributes.

Current documentation signals

The current docs appear to favor keeping asset department and user department as separate concepts:

• FR-13 lists location / responsible person / department as asset detail attributes.
• The database design includes both users.department and assets.department/assets.location.
• User registration accepts department but not location.
• Asset registration/update accepts location and department.
• Asset assignment only specifies responsible_person_id, assignment_date, and version; it does not require synchronizing asset department/location.

Possible directions to discuss

No decision has been made yet. Possible directions include:

1. Keep the data model separate and clarify UI labels

   • Rename Department / Location to Asset Department / Asset Location.
   • Optionally display Holder Department separately.

2. Default asset department from holder department during assignment, but allow override

   • The assign modal could prefill asset department from the selected holder.
   • Keep assets.department for cross-department loans, shared assets, inventory ownership, and audit/asset-accounting scenarios.

3. Collapse the semantics and only use holder department

   • Simpler, but weakens support for asset ownership, inventory, shared equipment, cross-department borrowing, and audits.
   • It also does not solve location because there is no users.location field today.

Recommendation before implementation

This should be clarified as a product/data-semantics decision before changing backend behavior. Key questions:

• Should the asset detail page's Department represent asset department or holder department?
• Should both be displayed?
• Should asset location remain an asset-level attribute?
• Should the assignment flow ask the manager to confirm or update asset department/location?

Acceptance criteria

To be defined after the product direction is chosen.

[jnes0824]

Impact surface to consider before choosing a direction

This decision affects more than the asset detail page. The main impact areas are:

1. Asset detail page

   • The current Department / Location labels can be interpreted as either asset-level fields or holder-level fields.
   • If we keep the current data model separate, the UI should probably clarify these as Asset Department / Asset Location.
   • If holder department is important, the page may need a separate Holder Department field.

2. Asset list and filters

   • The asset list currently displays and filters by department and location.
   • We should clarify whether these filters mean asset department/location or current holder department/location.
   • This matters for managers searching inventory by department.

3. Assign asset flow

   • The current assign flow updates holder, status, and assignment date only.
   • If assignment should also update asset department/location, the backend assign endpoint, frontend modal, tests, and docs need to change.
   • A middle-ground option is to prefill asset department from the selected holder but still let the manager confirm or override it.

4. Asset create/edit flow

   • Asset create/edit currently treats department and location as asset attributes.
   • If these become holder-derived fields, those forms and validation semantics become unclear.

5. User registration and user list

   • Users currently have department but no location.
   • If we want holder-based location, we would need a new users.location field and corresponding DB/API/frontend changes.

6. Asset APIs

   • GET /assets and GET /assets/mine expose/filter department and location.
   • The API contract should make clear whether those fields are asset-level or holder-derived.

7. Dashboard/reporting

   • Any future dashboard showing assets by department will produce different numbers depending on whether department means asset-owning department or current holder department.

8. Audit/history

   • If assign/unassign can change asset department/location, asset_action_histories.metadata may need to capture old/new department/location values for traceability.
   • Otherwise it may be hard to explain why an asset's department changed later.

9. Seed/demo data and tests

   • Demo data can intentionally have asset department differ from holder department.
   • Once the product semantics are chosen, seed data and tests should be updated to reflect the chosen behavior.

Suggested low-risk direction: keep assets.department and assets.location as asset-level attributes, clarify the UI labels, and optionally display holder department separately. That avoids a backend behavior change while resolving the immediate confusion.