On a fresh install of Carrot, the /mapping_rules/ page on a Scan Report may not show the entire mapping in the Term Map column.
Expected Behavior
I would expect the sample data set to return something like this:
Steps To Reproduce
Create a new instance of the product in a clean database.
Upload a scan report and add rules as in the quickstart.
View the rules table.
Environment
- OS: MacOS 14.3.1
- Other environment details: Using the repository developer environment.
I'm part of a Project Team
DRS
Anything else?
The issue is that the content_type is hardcoded throughout the application, and relies on the django_content_type ID being 15 (ScanReportField) or 17 (ScanReportValue), this is reflected in the docs.
But there is no reason to expect those IDs to be attached to those types, and the current code does not create a table that does (they use ID 13 and 14). As it is the order of models.py and migrations that will probably influence what the IDs are, which have presumably changed.
Ironically most of the code works fine with these hardcoded values. For example concepts are created with a content_type of 15, and then have conditions on being 15 in both the backend and frontend, which is assumed to be ScanReportField, even if it actually isn't.
The exception is the /mapping_rules table, which correctly uses get_for_modelhere. The code is complex to follow, but is used to create the term mapping, and the API endpoint will just return term_mapping: null.
Fix is one of these possibilities I think:
Quick: Update the documentation to ask a user to manually change the IDs in the database so 15 and 17 are always used for those content_types. This is brittle, and then needs changes in the auth_permission table (this was my fix to see how it should work).
Quick: Change the get_mapping_rules_list to use the hardcoded values also, this keeps it very brittle.
Quick: Reorder the models.py so the IDs revert back, but not sure this would work with migrations.
Preferred: Remove the magic numbers, and use get_for_id to get the ID for the content_type correctly, presumably the ProcessQueue would need an endpoint to get this type ID also.
Are you willing to contribute to resolve this issue?
Is there an existing issue for this?
Current Behavior
On a fresh install of Carrot, the
/mapping_rules/page on a Scan Report may not show the entire mapping in the Term Map column.Expected Behavior
I would expect the sample data set to return something like this:
Steps To Reproduce
Environment
I'm part of a Project Team
DRS
Anything else?
The issue is that the
content_typeis hardcoded throughout the application, and relies on thedjango_content_typeID being15(ScanReportField) or17(ScanReportValue), this is reflected in the docs.But there is no reason to expect those IDs to be attached to those types, and the current code does not create a table that does (they use ID
13and14). As it is the order ofmodels.pyand migrations that will probably influence what the IDs are, which have presumably changed.Ironically most of the code works fine with these hardcoded values. For example concepts are created with a
content_typeof15, and then have conditions on being15in both the backend and frontend, which is assumed to beScanReportField, even if it actually isn't. The exception is the/mapping_rulestable, which correctly usesget_for_modelhere. The code is complex to follow, but is used to create the term mapping, and the API endpoint will just returnterm_mapping: null.Fix is one of these possibilities I think:
15and17are always used for thosecontent_types. This is brittle, and then needs changes in theauth_permissiontable (this was my fix to see how it should work).get_mapping_rules_listto use the hardcoded values also, this keeps it very brittle.models.pyso the IDs revert back, but not sure this would work with migrations.get_for_idto get the ID for thecontent_typecorrectly, presumably theProcessQueuewould need an endpoint to get this type ID also.Are you willing to contribute to resolve this issue?
Yes