Problem
When editing an attribute definition and changing its type (e.g. TEXT → DECIMAL or TEXT → DATE), existing attribute_values that can't convert to the new type cause the whole save to fail with no useful feedback to the user.
Previously this also crashed with ErrorException: Array to string conversion in Attribute::check_data_validity() (fixed separately). With that crash fixed, the underlying UX gap remains: the save silently rolls back and the user only sees a generic "cannot be updated" message, with no indication of which values are the problem or any way to proceed.
Current behavior
Attribute::check_data_validity() (app/Models/Attribute.php, ~line 376) checks each existing value against the new type and logs an error for any that fail, but doesn't surface this to the caller beyond a boolean.Attribute::convert_definition_data() (~line 438) returns false if validity check fails.Attribute::saveDefinition() (~line 529) rolls back the entire transaction when conversion fails.Attributes::postSaveDefinition() (app/Controllers/Attributes.php) returns a generic failure JSON response with no detail about affected values/items.
Proposed behavior
When a type-changing save hits non-convertible values, show a modal explaining that some attribute values cannot be converted to the new type, with two options:
- Continue — drop/discard the non-convertible attribute values and proceed with the type change
- Cancel — abort the save (current behavior)
Implementation notes
- Backend:
postSaveDefinition() needs to surface which values (and/or affected items) are non-convertible in its JSON response instead of a generic failure, and support a "force"/"drop invalid values" flag that, when set, proceeds with the conversion while discarding the offending values.
- Frontend: the attribute definition save form (attributes/form view JS) needs a confirmation modal that triggers on this new response shape, and resubmits with the force flag on "Continue".
Problem
When editing an attribute definition and changing its type (e.g. TEXT → DECIMAL or TEXT → DATE), existing
attribute_values that can't convert to the new type cause the whole save to fail with no useful feedback to the user.Previously this also crashed with
ErrorException: Array to string conversioninAttribute::check_data_validity()(fixed separately). With that crash fixed, the underlying UX gap remains: the save silently rolls back and the user only sees a generic "cannot be updated" message, with no indication of which values are the problem or any way to proceed.Current behavior
Attribute::check_data_validity()(app/Models/Attribute.php, ~line 376) checks each existing value against the new type and logs an error for any that fail, but doesn't surface this to the caller beyond a boolean.Attribute::convert_definition_data()(~line 438) returnsfalseif validity check fails.Attribute::saveDefinition()(~line 529) rolls back the entire transaction when conversion fails.Attributes::postSaveDefinition()(app/Controllers/Attributes.php) returns a generic failure JSON response with no detail about affected values/items.Proposed behavior
When a type-changing save hits non-convertible values, show a modal explaining that some attribute values cannot be converted to the new type, with two options:
Implementation notes
postSaveDefinition()needs to surface which values (and/or affected items) are non-convertible in its JSON response instead of a generic failure, and support a "force"/"drop invalid values" flag that, when set, proceeds with the conversion while discarding the offending values.