Signals Notebook: For Inventory properties 'List' type, modifications made to value definitions are not reflected in the API responses ?

When a 'List' type property is created with values such as "A" and "B" and saved, the API endpoint Inventory GET /inventory/types correctly returns both values in the response. However, if the list values are later updated to new values, such as "C" and "D," the same API endpoint does not reflect these newly added values in the response. 

Answer: 
The API endpoint functions as expected and is not a bug. On creating a new container in the system with updated values (e.g., "C"). Subsequently, running the GET /inventory/types API endpoint reflects these updated values in the response. You can try the steps below to observe this behavior:

• Step 1: Admin defines a container type with a list containing values A and B.
• Step 2: A user creates a container of this type.
• Step 3: Admin updates the list to include additional values C and D.
• Step 4: Using the ExtAPI, the list definition for the container created in Step 2 will show only the original values, A and B.
• Step 5: A user creates a new container using the updated type (C or D).
• Step 6: Using the ExtAPI, the list definition for the container created in Step 5 will show all values: A, B, C, and D.
• Step 7: If the outcomes of these steps align with the described behavior, this is expected functionality and not a bug.

 
Reasoning for this behavior:

• List property definitions are tied to the objects at the time of their creation, reflecting the definition as it was then, without retroactively updating to align with centralized changes. In contrast, Attribute Lists are managed centrally, ensuring that all objects referencing them dynamically reflect the latest updates. please find more information including examples below:

 
List Property Definitions

1. Definition at the Time of Creation: When an object is created, the list properties associated with that object are set based on the list's definition at that specific moment. This means:
   • If the list definition (structure, attributes, or values) changes later, the object still retains the original list definition it had at the time of creation.
   • It does not automatically reflect updates or changes made to the centralized definition of the list.
2. No Link to Centralized Definition: These list properties are "baked into" the object, so any modifications to the master or centralized list definition are not retroactively applied to already created objects.

 
Attribute Lists

1. Centralized List: Attribute lists are managed centrally, meaning:
   • All objects referencing this list dynamically use the current, updated version of the list definition.
   • If you change the definition of the centralized attribute list, all objects using it will immediately reflect those changes.
2. Dynamic Updates: This centralization ensures consistency across all objects that use the attribute list because they are always aligned with the latest definition.

Example

• List Property Definitions: Suppose you create an object "Car" with a list property "Available Colors" defined as [Red, Blue, Green]. If you later add "Yellow" to the centralized definition of "Available Colors," the "Car" object will still only show [Red, Blue, Green].
• Attribute Lists: If "Available Colors" is an attribute list, any change (e.g., adding "Yellow") in the centralized list will be reflected in all objects, including the "Car" object.

 
This behavior determines whether updates to list definitions affect existing objects or only new ones, which is critical for designing systems where consistency or object independence is required.