fix(fixtures): ship the asset attribute option rows in the sample-data fixtures

[Jino-T]

Description

#15869 converted Product.platform / lifecycle / origin from choice strings to foreign keys on the new Product_Platform / Product_Lifecycle / Product_Origin lookup tables, and rewrote defect_dojo_sample_data.json and defect_dojo_sample_data_locations.json to reference the rows seeded by migration 0297 by primary key. It did not add those rows to the fixtures themselves.

Product carries a tagulous TagField, so tagulous wraps the deserializer and its _retag_to_original does getattr(obj, field.name) on every non-M2M field, which resolves each foreign key with a real SELECT while the fixture is still being read. The option rows therefore have to exist in the database before the first dojo.product entry is deserialised. On a freshly migrated database they do, so unittests/test_sample_data.py kept passing. On a database whose tables were emptied after migrating (manage.py flush, which is what the community demo server does before reloading the sample data) loaddata fails with:

dojo.product_attributes.models.Product_Platform.DoesNotExist: Problem installing fixture
'/app/dojo/fixtures/defect_dojo_sample_data_locations.json': Product_Platform matching query does not exist.

Because loaddata is atomic the whole fixture rolls back, System_Settings is never created either, and the UI shows the "Unable to load system settings from database ... Default values are being used" banner.

This PR adds the fourteen option rows (five platforms, three lifecycles, six origins) to both fixtures, with exactly the primary keys, value, name, icon and display_order the 0297 seed produces, placed ahead of the first dojo.product entry. On a seeded database they update in place with identical data; on a flushed database they recreate the rows. This follows the pattern the fixtures already use for dojo.development_environment and dojo.sla_configuration. The diff is purely additive.

Test results

unittests/test_sample_data.py gains test_loaddata_is_self_contained_for_asset_attribute_options, which empties the three lookup tables before loaddata and then checks the persisted platform / lifecycle / origin values of the three sample products.

Run against a freshly created test database with pure open-source settings, both with and without DD_V3_FEATURE_LOCATIONS:

• Before the fixture change: test_loaddata passes, the new test errors with Product_Platform matching query does not exist.
• After the fixture change: Ran 2 tests ... OK on both legs.

Ruff 0.16.4 passes on the test file.

Documentation

No user-facing change; nothing to document.

🤖 Generated with Claude Code