refactor!: rename project to perimeter as preparation for upcoming features #1446
Conversation
WalkthroughThis pull request represents a comprehensive refactoring of the application's data model, transitioning from a project-centric to a perimeter-centric architecture. The changes span multiple components across the backend and frontend, systematically replacing references to "project" with "perimeter". This involves modifying models, serializers, views, tests, localization files, and user interface components to ensure consistent terminology and data structure throughout the application. Changes
Sequence DiagramsequenceDiagram
participant User
participant Frontend
participant Backend
participant Database
User->>Frontend: Navigate to Perimeters
Frontend->>Backend: Request Perimeters
Backend->>Database: Query Perimeters
Database-->>Backend: Return Perimeter Data
Backend-->>Frontend: Send Perimeter List
Frontend->>User: Display Perimeters
Possibly related PRs
Suggested Labels
Suggested Reviewers
Poem
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
eric-intuitem
changed the title
eric-intuitem
changed the title
ab-smith
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🧹 Nitpick comments (13)
frontend/messages/nl.json (1)
212-213: Consider refining the term "perimeteren".The translations are generally good, but the term "perimeteren" (verb form of "perimeter") in the composer description might be unclear to users. Consider using a more natural Dutch phrase.
Suggested revision:
-"Dit zal je helpen meerdere componenten (perimeteren) samen te voegen" +"Dit zal je helpen meerdere componenten (perimeters) samen te voegen"backend/core/tests/test_models.py (2)
101-101: Consider using a shared fixture for perimeter creation.
This line is repeated in multiple tests. Centralizing it in a fixture can reduce duplication and keep tests consistent.
315-315: Creating a second perimeter.
Consider a fixture for multiple perimeter creation.backend/core/views.py (3)
251-251: Avoid potential F405 warnings by explicitly importingPerimeter.Star imports may lead to undefined references or overriding. Import
Perimeterdirectly to enhance readability and avoid static analysis warnings.-from .models import * +from .models import Perimeter, ...🧰 Tools
🪛 Ruff (0.8.2)
251-251:
Perimetermay be undefined, or defined from star imports(F405)
257-257: Consider renamingPRJ_LC_STATUSfor clarity.This attribute name still references "project." For consistency, rename it to something perimeter-specific, e.g.
LC_STATUS.-return Response(dict(Perimeter.PRJ_LC_STATUS)) +return Response(dict(Perimeter.LC_STATUS))🧰 Tools
🪛 Ruff (0.8.2)
257-257:
Perimetermay be undefined, or defined from star imports(F405)
277-277: ImportPerimeterReadSerializerexplicitly to avoid star import pitfalls.Star imports could cause confusion in large files. Consider using a direct import for better clarity.
-from .serializers import * +from .serializers import PerimeterReadSerializer, ...🧰 Tools
🪛 Ruff (0.8.2)
277-277:
PerimeterReadSerializermay be undefined, or defined from star imports(F405)
backend/core/management/commands/status.py (1)
Line range hint
2-2: Consider replacing star imports with explicit imports.Using star imports (
from core.models import *) makes it harder to track dependencies and could lead to naming conflicts.-from core.models import * +from core.models import ( + Perimeter, LoadedLibrary, Asset, Threat, + ReferenceControl, AppliedControl, Evidence, + ComplianceAssessment, RiskAssessment, + RiskScenario, RiskAcceptance +)🧰 Tools
🪛 Ruff (0.8.2)
13-13:
LoadedLibrarymay be undefined, or defined from star imports(F405)
15-15:
Perimetermay be undefined, or defined from star imports(F405)
16-16:
Assetmay be undefined, or defined from star imports(F405)
17-17:
Threatmay be undefined, or defined from star imports(F405)
18-18:
ReferenceControlmay be undefined, or defined from star imports(F405)
backend/core/tests/test_requirement_assessment.py (1)
7-7: LGTM! Consider adding migration-specific tests.The test changes correctly reflect the transition from projects to perimeters. Consider adding specific tests to verify that existing data is correctly migrated from projects to perimeters.
Example test to add:
def test_project_to_perimeter_migration(): # Create a compliance assessment with old project structure # Run migration # Verify data integrity and relationships are maintained passAlso applies to: 28-30, 39-39
backend/core/tests/test_helpers.py (1)
Line range hint
1-1: Consider replacing star imports with explicit imports.The static analysis tool flags multiple undefined classes from star imports. Consider replacing:
from core.models import *with explicit imports to improve code maintainability and avoid potential naming conflicts.
-from core.models import * +from core.models import ( + Perimeter, + RiskAssessment, + RiskMatrix, + RiskScenario, + StoredLibrary, +)🧰 Tools
🪛 Ruff (0.8.2)
39-39:
Foldermay be undefined, or defined from star imports(F405)
39-39:
Foldermay be undefined, or defined from star imports(F405)
41-41:
Perimetermay be undefined, or defined from star imports(F405)
42-42:
RiskAssessmentmay be undefined, or defined from star imports(F405)
45-45:
RiskMatrixmay be undefined, or defined from star imports(F405)
47-47:
RiskScenariomay be undefined, or defined from star imports(F405)
48-48:
Rolemay be undefined, or defined from star imports(F405)
49-49:
Permissionmay be undefined, or defined from star imports(F405)
frontend/src/routes/(app)/(internal)/recap/+page.server.ts (1)
Line range hint
96-108: Consider optimizing the data aggregation logic.The nested loops for data aggregation could be optimized for better performance.
Consider this optimization:
- perimeter.compliance_assessments.forEach((compliance_assessment: Record<string, any>) => { - compliance_assessment.donut.result.values.forEach( - (donutItem: RequirementAssessmentDonutItem) => { + const aggregatedValues = perimeter.compliance_assessments.reduce((acc, assessment) => { + assessment.donut.result.values.forEach((donutItem: RequirementAssessmentDonutItem) => { + const existing = acc.get(donutItem.name) || { ...donutItem, value: 0 }; + existing.value += donutItem.value; + acc.set(donutItem.name, existing); + }); + return acc; + }, new Map<string, RequirementAssessmentDonutItem>()); + + aggregatedDonutData.values = Array.from(aggregatedValues.values());Also applies to: 135-141
backend/core/urls.py (1)
Line range hint
1-1: Consider making imports explicit.Instead of using star imports (
from .views import *), consider explicitly importingPerimeterViewSetand other required view classes. This improves code maintainability and helps avoid potential naming conflicts.-from .views import * +from .views import ( + FolderViewSet, + PerimeterViewSet, + RiskMatrixViewSet, + # ... other required view classes +)🧰 Tools
🪛 Ruff (0.8.2)
26-26:
PerimeterViewSetmay be undefined, or defined from star imports(F405)
27-27:
RiskMatrixViewSetmay be undefined, or defined from star imports(F405)
28-28:
VulnerabilityViewSetmay be undefined, or defined from star imports(F405)
29-29:
RiskAssessmentViewSetmay be undefined, or defined from star imports(F405)
backend/app_tests/api/test_api_perimeters.py (1)
12-12: Fix typo in PERIMETER_REFERENCE constant.The constant
PERIMETER_REFERENCEcontains a typo: "test:perimter" should be "test:perimeter".-PERIMETER_REFERENCE = "test:perimter" +PERIMETER_REFERENCE = "test:perimeter"frontend/tests/functional/user-route.test.ts (1)
34-47: Add table data assertion for perimeter creation.The test step for perimeter creation is well-structured, but the TODO comment indicates missing verification of the created perimeter in the table.
Consider adding this assertion after perimeter creation:
await pages.perimetersPage.createItem({ name: vars.perimeterName, description: vars.description, folder: vars.folderName, ref_id: 'R.1234', lc_status: 'Production' }); -//TODO assert that the perimeter data are displayed in the table +await expect(page.getByRole('row', { name: vars.perimeterName })).toBeVisible();
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (87)
backend/app_tests/api/test_api_compliance_assessments.py(12 hunks)backend/app_tests/api/test_api_perimeters.py(1 hunks)backend/app_tests/api/test_api_projects.py(0 hunks)backend/app_tests/api/test_api_requirement_assessments.py(6 hunks)backend/app_tests/api/test_api_risk_acceptances.py(3 hunks)backend/app_tests/api/test_api_risk_assessments.py(15 hunks)backend/app_tests/api/test_api_risk_scenarios.py(9 hunks)backend/app_tests/test_vars.py(1 hunks)backend/core/base_models.py(1 hunks)backend/core/filters.py(5 hunks)backend/core/helpers.py(9 hunks)backend/core/locale/fr/LC_MESSAGES/django.po(3 hunks)backend/core/management/commands/status.py(2 hunks)backend/core/migrations/0050_rename_project_perimeter_alter_perimeter_options_and_more.py(1 hunks)backend/core/models.py(10 hunks)backend/core/serializers.py(9 hunks)backend/core/startup.py(11 hunks)backend/core/templates/core/action_plan_pdf.html(1 hunks)backend/core/templates/snippets/mp_data.html(1 hunks)backend/core/templates/snippets/ra_data.html(1 hunks)backend/core/tests/fixtures.py(2 hunks)backend/core/tests/test_helpers.py(2 hunks)backend/core/tests/test_models.py(35 hunks)backend/core/tests/test_requirement_assessment.py(3 hunks)backend/core/tests/test_vulnerability.py(4 hunks)backend/core/urls.py(1 hunks)backend/core/views.py(12 hunks)backend/ebios_rm/serializers.py(1 hunks)backend/iam/models.py(1 hunks)backend/iam/tests/test_user.py(5 hunks)backend/serdes/tests/test_dump.py(1 hunks)backend/serdes/utils.py(8 hunks)backend/tprm/migrations/0004_remove_entityassessment_project_and_more.py(1 hunks)backend/tprm/serializers.py(2 hunks)backend/tprm/views.py(1 hunks)cli/clica.py(4 hunks)enterprise/frontend/src/lib/components/SideBar/navData.ts(6 hunks)frontend/messages/ar.json(6 hunks)frontend/messages/cs.json(6 hunks)frontend/messages/de.json(6 hunks)frontend/messages/en.json(9 hunks)frontend/messages/es.json(6 hunks)frontend/messages/fr.json(7 hunks)frontend/messages/hi.json(6 hunks)frontend/messages/id.json(6 hunks)frontend/messages/it.json(6 hunks)frontend/messages/nl.json(8 hunks)frontend/messages/pl.json(6 hunks)frontend/messages/pt.json(6 hunks)frontend/messages/ro.json(6 hunks)frontend/messages/sv.json(6 hunks)frontend/messages/ur.json(6 hunks)frontend/src/lib/components/DetailView/DetailView.svelte(1 hunks)frontend/src/lib/components/Forms/ModelForm.svelte(2 hunks)frontend/src/lib/components/Forms/ModelForm/ComplianceAssessmentForm.svelte(1 hunks)frontend/src/lib/components/Forms/ModelForm/EntityAssessmentForm.svelte(1 hunks)frontend/src/lib/components/Forms/ModelForm/RiskAcceptanceForm.svelte(1 hunks)frontend/src/lib/components/Forms/ModelForm/RiskAssessmentForm.svelte(1 hunks)frontend/src/lib/components/Forms/ModelForm/RiskScenarioForm.svelte(1 hunks)frontend/src/lib/components/SideBar/SideBar.svelte(1 hunks)frontend/src/lib/components/SideBar/navData.ts(3 hunks)frontend/src/lib/utils/crud.ts(7 hunks)frontend/src/lib/utils/schemas.ts(5 hunks)frontend/src/lib/utils/table.ts(7 hunks)frontend/src/lib/utils/types.ts(2 hunks)frontend/src/routes/(app)/(internal)/[model=urlmodel]/[id=uuid]/+page.server.ts(1 hunks)frontend/src/routes/(app)/(internal)/analytics/+page.server.ts(2 hunks)frontend/src/routes/(app)/(internal)/analytics/+page.svelte(2 hunks)frontend/src/routes/(app)/(internal)/analytics/ComposerSelect.svelte(1 hunks)frontend/src/routes/(app)/(internal)/analytics/composer/+page.svelte(1 hunks)frontend/src/routes/(app)/(internal)/compliance-assessments/[id=uuid]/action-plan/+page.svelte(1 hunks)frontend/src/routes/(app)/(internal)/recap/+page.server.ts(6 hunks)frontend/src/routes/(app)/(internal)/recap/+page.svelte(2 hunks)frontend/src/routes/(app)/(internal)/risk-assessments/[id=uuid]/+page.svelte(1 hunks)frontend/src/routes/(app)/(internal)/risk-assessments/[id=uuid]/remediation-plan/+page.svelte(1 hunks)frontend/src/routes/(app)/(internal)/risk-scenarios/[id=uuid]/+page.svelte(1 hunks)frontend/src/routes/(app)/(internal)/risk-scenarios/[id=uuid]/edit/+page.server.ts(1 hunks)frontend/src/routes/(app)/(internal)/risk-scenarios/[id=uuid]/edit/+page.svelte(1 hunks)frontend/src/routes/(app)/(internal)/x-rays/+page.server.ts(1 hunks)frontend/src/routes/(app)/(internal)/x-rays/+page.svelte(4 hunks)frontend/src/routes/(app)/(third-party)/compliance-assessments/[id=uuid]/+page.svelte(1 hunks)frontend/tests/functional/detailed/common.test.ts(2 hunks)frontend/tests/functional/detailed/compliance-assessments.test.ts(1 hunks)frontend/tests/functional/user-route.test.ts(5 hunks)frontend/tests/utils/page-detail.ts(1 hunks)frontend/tests/utils/test-data.ts(11 hunks)frontend/tests/utils/test-utils.ts(11 hunks)
💤 Files with no reviewable changes (1)
- backend/app_tests/api/test_api_projects.py
🧰 Additional context used
🪛 Ruff (0.8.2)
backend/core/management/commands/status.py
15-15: Perimeter may be undefined, or defined from star imports
(F405)
backend/core/tests/test_helpers.py
41-41: Perimeter may be undefined, or defined from star imports
(F405)
42-42: RiskAssessment may be undefined, or defined from star imports
(F405)
45-45: RiskMatrix may be undefined, or defined from star imports
(F405)
47-47: RiskScenario may be undefined, or defined from star imports
(F405)
48-48: Role may be undefined, or defined from star imports
(F405)
49-49: Permission may be undefined, or defined from star imports
(F405)
106-106: Perimeter may be undefined, or defined from star imports
(F405)
107-107: RiskAssessment may be undefined, or defined from star imports
(F405)
110-110: RiskMatrix may be undefined, or defined from star imports
(F405)
112-112: RiskScenario may be undefined, or defined from star imports
(F405)
113-113: Role may be undefined, or defined from star imports
(F405)
114-114: Permission may be undefined, or defined from star imports
(F405)
backend/core/urls.py
26-26: PerimeterViewSet may be undefined, or defined from star imports
(F405)
backend/serdes/utils.py
80-80: Redefinition of unused Perimeter from line 19
Remove definition: Perimeter
(F811)
109-109: Redefinition of unused PerimeterImportExportSerializer from line 48
Remove definition: PerimeterImportExportSerializer
(F811)
backend/core/helpers.py
166-166: Perimeter may be undefined, or defined from star imports
(F405)
774-774: Perimeter may be undefined, or defined from star imports
(F405)
807-807: Perimeter may be undefined, or defined from star imports
(F405)
810-810: ComplianceAssessment may be undefined, or defined from star imports
(F405)
1183-1183: Perimeter may be undefined, or defined from star imports
(F405)
1190-1190: ComplianceAssessment may be undefined, or defined from star imports
(F405)
1196-1196: RiskAssessment may be undefined, or defined from star imports
(F405)
backend/core/views.py
251-251: Perimeter may be undefined, or defined from star imports
(F405)
257-257: Perimeter may be undefined, or defined from star imports
(F405)
262-262: Perimeter may be undefined, or defined from star imports
(F405)
272-272: Perimeter may be undefined, or defined from star imports
(F405)
274-274: Perimeter may be undefined, or defined from star imports
(F405)
277-277: PerimeterReadSerializer may be undefined, or defined from star imports
(F405)
309-309: Perimeter may be undefined, or defined from star imports
(F405)
314-314: PerimeterReadSerializer may be undefined, or defined from star imports
(F405)
345-345: Perimeter may be undefined, or defined from star imports
(F405)
347-347: Perimeter may be undefined, or defined from star imports
(F405)
980-980: Perimeter may be undefined, or defined from star imports
(F405)
2596-2596: Perimeter may be undefined, or defined from star imports
(F405)
2611-2611: Perimeter may be undefined, or defined from star imports
(F405)
backend/core/serializers.py
210-210: Perimeter may be undefined, or defined from star imports
(F405)
219-219: Perimeter may be undefined, or defined from star imports
(F405)
227-227: Perimeter may be undefined, or defined from star imports
(F405)
⏰ Context from checks skipped due to timeout of 90000ms (6)
- GitHub Check: startup-docker-compose-test
- GitHub Check: functional-tests (3.12, chromium)
- GitHub Check: build (3.12)
- GitHub Check: enterprise-startup-docker-compose-test
- GitHub Check: test (3.12)
- GitHub Check: enterprise-functional-tests (3.12, chromium)
🔇 Additional comments (233)
frontend/messages/nl.json (5)
28-28: Basic term translations look good!The translations for "perimeter" related terms are consistent and correctly follow Dutch language rules.
Also applies to: 41-41, 81-81
119-119: Single term translation is correct!The technical term "perimeter" is appropriately kept as-is in the Dutch translation.
187-187: UI text translations with variable interpolation are correct!The translations maintain proper Dutch grammar and correctly preserve the variable interpolation.
Also applies to: 189-189
224-224: Summary text translation is accurate!The empty state message is correctly translated and follows the same pattern as other similar messages in the file.
756-756: Error message translation is well-formed!The translation maintains a formal tone and correctly uses Dutch technical terminology.
frontend/src/lib/utils/crud.ts (9)
155-155: Good job on renaming the reverseForeignKeyFields.This change is consistent with the updated perimeter-centric architecture.
159-170: Newperimetersentry looks coherent.The fields and naming convention align well with the perimeter-based model. No concerns regarding consistency or readability.
193-193: Renaming the foreign key reference toperimeteris correct.This aligns with the perimeter refactor.
210-210: Foreign key fields renamed toperimeter.This matches the new model structure and fosters consistency.
235-235: Foreign key field referencingperimetersis correct.No issues found.
468-468: Compliance-assessments referencingperimeters.This ensures consistent naming and avoids confusion.
563-563: Entity-assessments pointing toperimeter.Rename is uniform across the codebase.
880-880: Newperimetersentry inFIELD_COLORED_TAG_MAP.All references align with perimeter-based model. The color mapping seems straightforward.
202-202: Filters updated to includeperimeter.Ensure any code referencing the old
projectfilter key has been updated accordingly.backend/core/serializers.py (10)
214-219:PerimeterReadSerializerlogic looks sound.Including
folderandlc_statusensures completeness of perimeter data retrieval.🧰 Tools
🪛 Ruff (0.8.2)
219-219:
Perimetermay be undefined, or defined from star imports(F405)
223-227:PerimeterImportExportSerializerproperly reflects the perimeter design.Looks consistent with the existing serializer patterns.
🧰 Tools
🪛 Ruff (0.8.2)
227-227:
Perimetermay be undefined, or defined from star imports(F405)
248-248: Field list updated to includeperimeter.Change is consistent with the perimeter refactor in
RiskAssessmentDuplicateSerializer.
253-253: ReplacingprojectwithperimeterinRiskAssessmentReadSerializer.Ensures references match the new data model.
Line range hint
269-280:RiskAssessmentImportExportSerializerusesperimeterfield.The slug-based approach for read-only references is maintained. No issues.
462-463:RiskScenarioReadSerializerreading fromrisk_assessment.perimeter.Field rename is aligned with the rest of the code.
864-864:perimeterfield inComplianceAssessmentReadSerializer.Smooth transition from the old
projectfield.
Line range hint
916-926:ComplianceAssessmentImportExportSerializerreferencingperimeter.Renaming is consistent with other import/export serializers.
🧰 Tools
🪛 Ruff (0.8.2)
919-919:
ComplianceAssessmentmay be undefined, or defined from star imports(F405)
208-210: IntroducedPerimeterWriteSerializer.Static analysis warns that
Perimetermay be from a star import. Confirm thatPerimeteris defined incore.models.✅ Verification successful
Star import confirmed, consider explicit import
The
Perimetermodel is correctly defined incore.models.py, but it's currently imported viafrom core.models import *. Consider replacing the star import with an explicit import for better code maintainability:from core.models import Perimeter🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verifying that Perimeter is declared in core/models.py ast-grep --pattern $'class Perimeter($_) {\n $$$\n}'Length of output: 52
Script:
#!/bin/bash # Search for Perimeter class definition rg "class Perimeter" -A 2 # Check imports in serializers.py rg "from .* import .*Perimeter" backend/core/serializers.py # Look specifically in models.py cat backend/core/models.py | grep -A 5 "class Perimeter"Length of output: 1729
Script:
#!/bin/bash # Check all imports at the top of serializers.py rg "^from|^import" backend/core/serializers.pyLength of output: 509
🧰 Tools
🪛 Ruff (0.8.2)
210-210:
Perimetermay be undefined, or defined from star imports(F405)
111-111:perimeterfield inAssessmentReadSerializer.Change from
projecttoperimeteris coherent. Confirm that any usage of.projectin templates or business logic is updated.✅ Verification successful
Field change from
projecttoperimeteris properly implementedThe change is coherent across the codebase. The field is consistently defined in the base
AssessmentReadSerializerand properly extended in child serializers. No problematic usages of.projectwere found in the serializer context or related code.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Searching for leftover references to AssessmentReadSerializer.project rg 'AssessmentReadSerializer' -A 10 | rg '\.project'Length of output: 52
Script:
#!/bin/bash # Find AssessmentReadSerializer usages with context echo "=== AssessmentReadSerializer usages ===" rg -l "AssessmentReadSerializer" echo -e "\n=== Template files with 'project' ===" fd -e html -e django-html | xargs rg "project" echo -e "\n=== Python files with Assessment and project ===" rg -l "class.*Assessment" | xargs rg "project" -C 3Length of output: 102428
Script:
#!/bin/bash # Find AssessmentReadSerializer implementation and usage echo "=== AssessmentReadSerializer implementation ===" rg -A 10 -B 5 "class AssessmentReadSerializer" echo -e "\n=== AssessmentReadSerializer usage ===" rg "AssessmentReadSerializer\(" -A 3Length of output: 5343
backend/core/helpers.py (10)
120-122: Renamed tocompile_perimeter_for_composer.Docstring matches the new implementation. This is in line with the perimeter-based refactor.
139-139: Filtering bycompliance_assessment__perimeter__in=perimeters_list.Filter logic is correct and consistent with the rename.
156-156:requirement_assessments__assessment__perimeter__in=perimeters_list.Ensures correct composition scope.
163-167: Buildingperimeter_objectsarray.Retrieving
Perimetervia primary key is aligned with the rest of the flow.🧰 Tools
🪛 Ruff (0.8.2)
166-166:
Perimetermay be undefined, or defined from star imports(F405)
170-170: Returningperimeter_objectsin the final dict.Ensures consumers can process the new perimeter-based data set.
Line range hint
740-752:risks_per_perimeter_groups: new perimeter-based grouping.Filtering by
risk_assessment__perimeter__folder=folderis coherent with the new domain/perimeter structure.
772-774: Counters forperimeters.Accurate rename from
projectskey toperimeters.🧰 Tools
🪛 Ruff (0.8.2)
774-774:
Perimetermay be undefined, or defined from star imports(F405)
807-810: Looping overPerimeter.objectsand referencingComplianceAssessmentfor each.Logic cleanly fits the perimeter-based flow.
🧰 Tools
🪛 Ruff (0.8.2)
807-807:
Perimetermay be undefined, or defined from star imports(F405)
810-810:
ComplianceAssessmentmay be undefined, or defined from star imports(F405)
1012-1014: Concatenatingrisk_assessment.perimeterwith version.Properly references the perimeter as a string. No issues found.
1183-1190:get_folder_contentupdated forPerimeterreferences.Switched from counting by project to counting by perimeter. Flow is well-aligned with the new model.
Also applies to: 1191-1192, 1196-1196
🧰 Tools
🪛 Ruff (0.8.2)
1183-1183:
Perimetermay be undefined, or defined from star imports(F405)
1190-1190:
ComplianceAssessmentmay be undefined, or defined from star imports(F405)
backend/core/tests/test_models.py (54)
8-8: Thanks for updating the import statement to Perimeter.
This aligns with the perimeter-centric model.
105-105: Proper reference of perimeter.
This replacement fromprojecttoperimeteris consistent with the rename.
111-111: Good assertion for verifying perimeter.
Ensures that the risk assessment references the correct perimeter.
128-128: Repeated perimeter creation.
Same suggestion as line 101 to consider a shared fixture or factory.
132-132: Correct perimeter usage.
No issues found.
146-146: Repeated perimeter creation.
Same remark as line 101.
150-150: Perimeter assignment is correct.
172-172: Repeated perimeter creation.
Same remark as line 101.
176-176: Perimeter assignment is correct.
202-202: Repeated perimeter creation.
Same remark as line 101.
206-206: Perimeter assignment remains consistent.
233-233: Repeated perimeter creation.
Same remark as line 101.
237-237: Perimeter assignment is correct.
243-243: Renamed test method
Accurately reflects perimeter-based uniqueness.
253-253: Repeated perimeter creation.
Same remark as line 101.
257-257: Perimeter assignment is correct.
264-264: Perimeter assignment outside fixture
Still consistent with rename.
278-278: Repeated perimeter creation.
Same remark as line 101.
282-282: Perimeter usage is correct.
289-289: Perimeter usage is correct.
294-294: Renamed test method
Accurately verifies usage across different perimeters.
306-306: Repeated perimeter creation.
Same remark as line 101.
310-310: Perimeter assignment is consistent.
319-319: Assigning perimeter2
Ensures coverage of multiple perimeters in tests.
324-324: Renamed test method
Scope now references perimeter instead of project.
334-334: Repeated perimeter creation.
Same remark as line 101.
338-338: Perimeter assignment is correct.
344-344: Perimeter assignment remains consistent.
350-350: Perimeter assignment remains consistent.
354-354: Creating a second perimeter
Consider reusing a fixture for perimeter creation.
358-358: Perimeter assignment referencing perimeter2
364-364: Another perimeter2 assignment
385-385: Repeated perimeter creation
Same remark as line 101.
389-389: Perimeter assignment is correct
410-410: Renamed test scenario method
Focuses on 'parent_perimeter' instead of 'parent_project'.
415-415: Repeated perimeter creation
Same remark as line 101.
419-419: Perimeter assignment is consistent
431-433: Great test verifying parent perimeter
Ensures the scenario returns the correct perimeter fromparent_perimeter().
441-441: Repeated perimeter creation
Same remark as line 101.
445-445: Perimeter assignment is consistent
471-471: Repeated perimeter creation
Same remark as line 101.
475-475: Perimeter assignment
502-502: Repeated perimeter creation
Same remark as line 101.
506-506: Perimeter usage
526-526: Repeated perimeter creation
Same remark as line 101.
530-530: Perimeter usage
555-555: Perimeter assignment
Line range hint
566-566: Updated reference to compliance_assessment.perimeter.folder
This is consistent with perimeter-based architecture.
711-711: Repeated perimeter creation
Same remark as line 101.
715-715: Perimeter assignment
750-750: Repeated perimeter creation
Same remark as line 101.
754-754: Perimeter usage
794-794: Repeated perimeter creation
Same remark as line 101.
798-798: Perimeter usagebackend/core/models.py (11)
1351-1351: Introduction of Perimeter model
This is consistent with the perimeter-based refactor.
1373-1373: Updated verbose_name
Accurately reflects the new Perimeter naming.
1374-1374: Updated verbose_name_plural
Ensures consistent Django admin display.
1879-1879: Renamed property
Replaces 'projects' with 'perimeters' to stay consistent with refactor.
1880-1880: Use of set comprehension
Returning distinct perimeters for the AppliedControl.
2042-2046: Switched to referencing Perimeter
Replaces the former project-based foreign key with a perimeter-based approach.
2085-2085: Folder assignment from perimeter
Ensures the newly introduced perimeter is the folder source.
2146-2146: Path display updated
Utilizes perimeter folder path for clarity.
2602-2603: New parent_perimeter method
This method cleanly retrieves the associated perimeter from the risk assessment.
2605-2605: Short description updated
Reflects the 'Perimeter' label in admin.
2706-2706: String representation
Displays perimeter name explicitly with the scenario's name.backend/core/views.py (13)
246-248: RenamingProjectViewSettoPerimeterViewSetis consistent.These lines properly shift the focus from projects to perimeters. The updated docstring clarifies the endpoint’s purpose.
262-262: Query usage looks correct.Filtering by UUIDs via
id__in=uuid_listis a straightforward approach.🧰 Tools
🪛 Ruff (0.8.2)
262-262:
Perimetermay be undefined, or defined from star imports(F405)
272-274: Access control logic stays consistent with the perimeter-based approach.No immediate concerns.
🧰 Tools
🪛 Ruff (0.8.2)
272-272:
Perimetermay be undefined, or defined from star imports(F405)
274-274:
Perimetermay be undefined, or defined from star imports(F405)
309-309: Perimeter-based access check is consistent.No issues found.
🧰 Tools
🪛 Ruff (0.8.2)
309-309:
Perimetermay be undefined, or defined from star imports(F405)
314-314: Same star import concern forPerimeterReadSerializer.This is a duplicate of the earlier comment about explicit imports.
🧰 Tools
🪛 Ruff (0.8.2)
314-314:
PerimeterReadSerializermay be undefined, or defined from star imports(F405)
345-345: Parameter adjustment forobject_type=Perimeter.Implementation follows the new perimeter model.
🧰 Tools
🪛 Ruff (0.8.2)
345-345:
Perimetermay be undefined, or defined from star imports(F405)
347-347: Looping over perimeter objects is valid.No concerns here.
🧰 Tools
🪛 Ruff (0.8.2)
347-347:
Perimetermay be undefined, or defined from star imports(F405)
673-674: Filterset fields updated to perimeter-based attributes.Looks correct as part of the refactor.
1557-1558: Filterset onrisk_assessment__perimeterfields.Shifting from
projecttoperimeteris correct and consistent with the new data model.
1973-1973: Docstring updated to reflect domains and perimeters.This statement clearly describes the new structure.
2611-2612: Same concern with.get()on_fields["perimeter"].A missing or invalid
perimeterID would raiseDoesNotExist.🧰 Tools
🪛 Ruff (0.8.2)
2611-2611:
Perimetermay be undefined, or defined from star imports(F405)
3202-3202: Filterset update toperimeteraligns with the new architecture.No issues here.
980-980: Handle.get()forPerimeter.objects.get(...)carefully.This may raise an exception if the record is not found or if
data["perimeter"]is missing. Consider adding error handling or a fallback.try: - perimeter=Perimeter.objects.get(id=data["perimeter"]) + perimeter = Perimeter.objects.get(id=data["perimeter"]) except Perimeter.DoesNotExist: return Response({"error": "Invalid perimeter ID"}, status=400)🧰 Tools
🪛 Ruff (0.8.2)
980-980:
Perimetermay be undefined, or defined from star imports(F405)
frontend/src/routes/(app)/(internal)/x-rays/+page.server.ts (1)
6-6: Endpoint changed fromprojectstoperimeters.This is consistent with the perimeter-centric refactor.
backend/tprm/migrations/0004_remove_entityassessment_project_and_more.py (3)
1-2: Auto-generated migration header.No issues. The migration comment is standard.
14-17: Removing theprojectfield fromEntityAssessment.Eliminating the field aligns with the new perimeter model. Ensure any data referencing
projectis handled properly before migration.
18-27: Introducing a nullable foreign key toPerimeter.This replacement is consistent with the shift from project to perimeter. Verify that existing references transition smoothly.
frontend/src/routes/(app)/(internal)/analytics/ComposerSelect.svelte (1)
21-21: LGTM! Change aligns with project → perimeter refactoringThe update to use 'perimeter' instead of 'project' in
extra_fieldsis consistent with the broader refactoring effort.backend/core/tests/fixtures.py (1)
4-4: LGTM! Test fixture properly updated for perimeter refactoringThe changes to the fixture are consistent with the model refactoring from Project to Perimeter.
Let's verify that all test files using this fixture have been updated:
Also applies to: 13-13, 20-21
✅ Verification successful
Refactoring verification complete - all test files properly updated
The codebase has been thoroughly checked and no remaining references to the old Project model or domain_project_fixture were found in any test files. The refactoring from Project to Perimeter appears to be complete and consistent.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any remaining references to the old fixture name rg "domain_project_fixture" -l # Search for any remaining Project model references in test files rg "from core\.models import .*Project" "backend/**/test*.py" rg "Project\.objects\." "backend/**/test*.py"Length of output: 262
Script:
#!/bin/bash # Find test files and search for fixture references fd "test.*\.py$" backend/ | xargs rg "domain_project_fixture" -l # Search for Project model references in test files fd "test.*\.py$" backend/ | xargs rg "from core\.models import .*Project" -A 2 fd "test.*\.py$" backend/ | xargs rg "Project\.objects\." -A 2 # Also check for any direct Project class usage fd "test.*\.py$" backend/ | xargs rg "\bProject\b" -A 2Length of output: 268
Script:
#!/bin/bash # Check repository structure ls -R # Find all Python files to understand project structure fd "\.py$" # Find all test-related files regardless of extension fd "test"Length of output: 53085
Script:
#!/bin/bash # Search for Project references in test files rg -l "Project" backend/*/tests/ backend/app_tests/ # Search specifically for the old fixture name rg -l "domain_project_fixture" backend/*/tests/ backend/app_tests/ # Check for any Project model imports in test files rg "from core\.models import.*Project" backend/*/tests/ backend/app_tests/ # Look for Project usage in test files rg "\bProject\." backend/*/tests/ backend/app_tests/Length of output: 690
backend/core/migrations/0050_rename_project_perimeter_alter_perimeter_options_and_more.py (2)
15-18: LGTM! Model rename operation is correctly definedThe rename operation from Project to Perimeter is properly structured.
31-50: Consider data integrity implications of nullable perimeter fieldThe new perimeter foreign key fields are defined with
null=True, which could lead to orphaned assessments. Consider if this is intentional or if assessments should always be associated with a perimeter.Let's check if there are any existing assessments that might be affected:
frontend/src/lib/components/Forms/ModelForm/RiskScenarioForm.svelte (1)
43-43: LGTM! Change aligns with project → perimeter refactoringThe update to use 'perimeter' instead of 'project' in
extra_fieldsis consistent with the broader refactoring effort.frontend/src/lib/components/Forms/ModelForm/RiskAcceptanceForm.svelte (1)
62-62: Verify the impact on existing risk scenarios data.The change from 'project' to 'perimeter' in extra_fields might affect how existing risk scenarios are displayed and filtered in the UI.
Run this script to check for any orphaned risk scenarios:
✅ Verification successful
The change from 'project' to 'perimeter' in extra_fields is safe
The modification is consistent with the codebase architecture where risk scenarios access perimeter data through their risk assessment relationship. This UI-only change doesn't affect existing data or functionality.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for risk scenarios that might be affected by the project->perimeter transition ast-grep --pattern 'class RiskScenario { $$$ project = $field $$$ }'Length of output: 76
Script:
#!/bin/bash # Find relevant files echo "=== Files containing RiskScenario ===" fd -t f -e py -e js -e svelte . | xargs rg -l "RiskScenario" echo -e "\n=== Risk Scenario API endpoints ===" rg -A 3 "risk.*scenario" -g "*.py" echo -e "\n=== Project/Perimeter field usage ===" rg "(project|perimeter).*(risk|scenario)" -g "*.{py,js,svelte}"Length of output: 60165
backend/core/management/commands/status.py (1)
15-15: LGTM! Consistent renaming from projects to perimeters.The changes maintain consistency with the perimeter-centric refactoring.
Also applies to: 41-41
🧰 Tools
🪛 Ruff (0.8.2)
15-15:
Perimetermay be undefined, or defined from star imports(F405)
backend/tprm/views.py (1)
31-31: Verify API backward compatibility for existing clients.The change in filter fields from 'project' to 'perimeter' might break existing API clients that use these filters.
Run this script to check for API usage patterns:
✅ Verification successful
API change is properly handled through migrations
The change from 'project' to 'perimeter' is part of a planned database schema migration (migration 0050). No direct usage of these filter fields was found in frontend code, and the change is properly handled through Django's migration system, ensuring database consistency.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for API calls using project filters rg -l 'project(?:__folder)?' --type js --type pyLength of output: 1054
Script:
#!/bin/bash # Check when TPRM feature was introduced and the timeline of changes git log --oneline -- backend/tprm/Length of output: 0
frontend/src/routes/(app)/(internal)/risk-assessments/[id=uuid]/remediation-plan/+page.svelte (1)
50-50: LGTM! Perimeter references are correctly updated.The changes consistently replace project references with perimeter in both the display text and URL structure.
Let's verify that all project references have been replaced in this component:
Also applies to: 53-54
✅ Verification successful
All perimeter references are correctly updated, no project references remain
The file shows consistent use of "perimeter" terminology in all relevant places - translation keys, URL paths, and data structures. No instances of "project" were found in the component.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any remaining "project" references in the file rg -i "project" "frontend/src/routes/(app)/(internal)/risk-assessments/[id=uuid]/remediation-plan/+page.svelte"Length of output: 111
Script:
#!/bin/bash # First verify file exists fd "page.svelte" frontend/src/routes/ # If file exists, show its content cat frontend/src/routes/\(app\)/\(internal\)/risk-assessments/\[id=uuid\]/remediation-plan/+page.svelte # Search for any files that might contain related code fd "remediation-plan" frontend/src/Length of output: 8377
frontend/src/lib/utils/types.ts (2)
32-32: LGTM! URL model updated correctly.The URL_MODEL array now includes 'perimeters' instead of 'projects', maintaining consistency with the API endpoints.
Line range hint
105-115: Verify interface usage across the codebase.The Project interface has been renamed to Perimeter while maintaining the same structure. We should verify that all references to this interface have been updated.
Let's check for any remaining references to the Project interface:
✅ Verification successful
All references to the Project interface have been successfully updated
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for Project interface references in TypeScript files rg -t ts "interface Project" # Search for type references to Project rg -t ts "Project[^a-zA-Z]"Length of output: 60
Script:
#!/bin/bash # Search with various patterns that might reference the Project interface rg -i "project" --type ts --type js -A 2 -B 2 rg ": Project" --type ts -A 2 -B 2 rg "as Project" --type ts -A 2 -B 2 rg "<Project>" --type ts -A 2 -B 2 rg "@type.*Project" --type js --type ts -A 2 -B 2Length of output: 1422
frontend/src/lib/components/Forms/ModelForm/RiskAssessmentForm.svelte (1)
33-40: LGTM! Form component updated consistently.The AutocompleteSelect component has been properly updated to use perimeter instead of project throughout all its properties:
- Foreign key reference
- Field name
- Cache references
- Label
- Hidden condition
Let's verify that all project references have been updated in this form:
✅ Verification successful
All "project" references successfully replaced with "perimeter"
The verification confirms that all references have been properly updated in the RiskAssessmentForm component, and no other forms in the directory contain legacy "project" references.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any remaining "project" references in the form rg -i "project" "frontend/src/lib/components/Forms/ModelForm/RiskAssessmentForm.svelte" # Check if similar forms have been updated consistently fd -t f ".*Form.svelte" "frontend/src/lib/components/Forms/ModelForm/" -x rg -l "project"Length of output: 173
Script:
#!/bin/bash # Verify file existence and path fd "RiskAssessmentForm.svelte" frontend/ # Search for both project and perimeter with context echo "=== Searching for 'project' references ===" rg -i "project" frontend/src/lib/components/Forms/ModelForm/RiskAssessmentForm.svelte -C 2 echo "=== Searching for 'perimeter' references ===" rg -i "perimeter" frontend/src/lib/components/Forms/ModelForm/RiskAssessmentForm.svelte -C 2 # Find similar forms echo "=== Finding similar forms with 'project' references ===" fd -t f "Form.svelte$" frontend/src/lib/components/Forms/ModelForm/ -x rg -l "project"Length of output: 1001
frontend/tests/functional/detailed/common.test.ts (1)
14-14: LGTM! Parameter and usage updated consistently.The refactoring from project to perimeter has been applied consistently in both the function signature and its usage.
Also applies to: 27-27
backend/iam/tests/test_user.py (2)
12-12: LGTM! Reader role permissions updated correctly.The fixture and view permission have been correctly updated from project to perimeter.
Also applies to: 21-21
50-50: LGTM! Editor role permissions updated comprehensively.All project-related permissions (view, add, change, delete) have been consistently updated to use perimeter.
Also applies to: 59-59, 69-71
frontend/src/routes/(app)/(internal)/recap/+page.svelte (2)
24-24: LGTM! Template and routing updated consistently.The changes from projects to perimeters have been applied consistently across:
- Data iteration (
data.perimeters)- Conditional checks (
perimeter.compliance_assessments)- URL construction (
/perimeters/{perimeter.id})Also applies to: 26-26, 32-32
37-37: Verify data structure compatibility.Ensure that the
overallComplianceandcompliance_assessmentsproperties maintain the same structure in the perimeter model as they had in the project model.Also applies to: 49-49
✅ Verification successful
Data structure compatibility verified successfully
The
overallComplianceandcompliance_assessmentsproperties maintain consistent structure between perimeter and project models, with proper typing in the frontend and matching backend implementation. The sorting and display logic in the component correctly handles the data structure.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for type definitions and model structures rg -A 5 "interface.*Perimeter" frontend/src/ rg -A 5 "class.*Perimeter.*Model" backend/core/models.pyLength of output: 1445
Script:
#!/bin/bash # Search for RequirementAssessmentDonutItem and compliance types/models rg -A 5 "type.*RequirementAssessmentDonutItem|interface.*RequirementAssessmentDonutItem" frontend/src/ rg -A 10 "class.*ComplianceAssessment|compliance_assessments" backend/core/models.py rg -A 5 "overallCompliance.*values" frontend/src/Length of output: 6003
backend/core/tests/test_helpers.py (2)
41-44: LGTM! Test cases updated correctly.The test setup has been properly updated to use Perimeter instead of Project.
Also applies to: 51-51
🧰 Tools
🪛 Ruff (0.8.2)
41-41:
Perimetermay be undefined, or defined from star imports(F405)
42-42:
RiskAssessmentmay be undefined, or defined from star imports(F405)
106-109: LGTM! Duplicate test case updated consistently.The second test case has been updated consistently with the same project to perimeter changes.
Also applies to: 116-116
🧰 Tools
🪛 Ruff (0.8.2)
106-106:
Perimetermay be undefined, or defined from star imports(F405)
107-107:
RiskAssessmentmay be undefined, or defined from star imports(F405)
backend/core/tests/test_vulnerability.py (1)
19-19: LGTM! Consistent fixture renaming.The changes correctly reflect the transition from projects to perimeters in the test fixtures and method signatures.
Let's verify that all project references have been updated consistently:
Also applies to: 37-37, 54-54, 84-84
✅ Verification successful
Fixture renaming verification successful
The transition from projects to perimeters is complete and consistent across all test files. No legacy "project" references remain in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any remaining references to 'project' in test files rg -i "project" "backend/core/tests/" --type pyLength of output: 45
Script:
#!/bin/bash # First, verify the directory structure and Python files echo "=== Checking directory structure ===" ls -la backend/core/tests/ echo -e "\n=== Listing Python files ===" fd -e py . backend/core/tests/ echo -e "\n=== Searching for project/perimeter references ===" rg -i "project|perimeter" backend/core/tests/ --type py -C 2 echo -e "\n=== AST-based search for function parameters and variables ===" ast-grep --pattern 'def $_(project$_)' backend/core/tests/ ast-grep --pattern 'def $_(perimeter$_)' backend/core/tests/Length of output: 32453
frontend/src/routes/(app)/(internal)/analytics/+page.server.ts (1)
6-6: LGTM! Type definitions updated correctly.The changes maintain type safety while transitioning from projects to perimeters.
Let's verify type consistency across the frontend:
Also applies to: 31-31
✅ Verification successful
Type consistency verified: Project to Perimeter migration is complete
The codebase shows consistent usage of the Perimeter type with no remaining references to the old Project type. The type system is properly maintained across the frontend.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any remaining Project type references rg -l "type.*Project.*" "frontend/src/" --type tsLength of output: 49
Script:
#!/bin/bash # More comprehensive search for Project-related types ast-grep --pattern 'type Project = { $$$ }' ast-grep --pattern 'interface Project { $$$ }' # Search for Perimeter type usage rg "Perimeter" "frontend/src/" --type ts -A 2 # Broader search for any remaining "Project" string rg "Project" "frontend/src/" --type tsLength of output: 2873
frontend/src/lib/components/SideBar/SideBar.svelte (1)
62-64: LGTM! Tour steps updated consistently.The guided tour steps have been updated to reflect the new perimeter terminology, maintaining a consistent user experience.
Let's verify the message translations exist:
Also applies to: 71-71
✅ Verification successful
Translation keys are properly defined and implemented ✅
The
tourPerimetersDescriptiontranslation key is correctly defined in both English and French language files, with proper formatting and consistent terminology.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for the new translation keys rg "tourPerimeters.*" "frontend/src/lib/i18n/" --type tsLength of output: 119
Script:
#!/bin/bash # Find i18n-related files and directories fd -t d "i18n"Length of output: 14
Script:
#!/bin/bash # Search for the translation method call pattern rg "tourPerimetersDescription"Length of output: 478
frontend/src/routes/(app)/(internal)/recap/+page.server.ts (2)
3-3: LGTM! Type definitions updated correctly.The type imports and interface definitions have been updated to reflect the new perimeter model.
Also applies to: 27-27
35-39: Verify error handling for API responses.While the API endpoint updates look correct, ensure proper error handling for failed requests.
Let's verify the API endpoint exists:
Also applies to: 42-42
✅ Verification successful
Error handling is properly implemented ✅
The code has appropriate error handling:
- Backend uses Django REST Framework's ModelViewSet with built-in error handling
- Frontend implements
.catch()with proper fallback to empty array and error logging🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for the perimeters API endpoint definition rg -A 5 "class.*PerimeterViewSet" "backend/" --type pyLength of output: 331
Script:
#!/bin/bash # Check BaseModelViewSet implementation rg -A 10 "class BaseModelViewSet" "backend/" --type py # Check for error handling patterns around fetch calls in frontend rg -B 2 -A 2 "catch\(" "frontend/src/routes/(app)/(internal)/recap/"Length of output: 2796
backend/serdes/tests/test_dump.py (1)
23-23: LGTM!The model type change from "project" to "perimeter" in the test fixture aligns with the broader refactoring effort.
frontend/src/lib/components/Forms/ModelForm/ComplianceAssessmentForm.svelte (1)
56-63: LGTM!The
AutocompleteSelectcomponent has been correctly updated to use the perimeter model, maintaining all necessary properties and theextra_fieldsparameter.backend/core/base_models.py (1)
80-81: LGTM!The
get_scopemethod has been correctly updated to check for the perimeter attribute instead of project, maintaining the existing scope filtering behavior.backend/core/urls.py (1)
26-26: LGTM!The URL pattern has been correctly updated to use the new perimeter endpoint.
🧰 Tools
🪛 Ruff (0.8.2)
26-26:
PerimeterViewSetmay be undefined, or defined from star imports(F405)
frontend/src/lib/components/SideBar/navData.ts (1)
22-22: LGTM! Consistent terminology changes.The changes correctly update all references from 'project' to 'perimeter' in both permissions and navigation items.
Also applies to: 34-34, 53-53, 55-55
frontend/src/lib/components/Forms/ModelForm/EntityAssessmentForm.svelte (1)
23-28: LGTM! Form properties correctly updated.The AutocompleteSelect component's properties have been consistently updated from project to perimeter.
enterprise/frontend/src/lib/components/SideBar/navData.ts (1)
11-11: LGTM! Enterprise version changes align with community version.All project-to-perimeter updates are consistent across both versions of navData.ts.
Also applies to: 23-23, 40-40, 52-52, 64-64, 83-83, 85-85
frontend/tests/utils/page-detail.ts (1)
44-44: LGTM! Test logic updated for perimeter model.The verifyItem method correctly handles the new perimeter-based model.
Consider running the following to verify test coverage:
Also applies to: 47-47
✅ Verification successful
Verified: Changes are well-covered by existing test suite
The perimeter model is already well-tested across multiple test files:
- Utility tests: test-data.ts, test-utils.ts
- Functional tests: user-route.test.ts, common.test.ts, compliance-assessments.test.ts
The 'project' reference in e2e-tests.sh is unrelated as it's only used for Playwright configuration.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check test coverage for perimeter-related changes # Search for test files that might need updates rg -l 'project' frontend/tests/Length of output: 59
Script:
#!/bin/bash # Check context of 'project' usage and search for perimeter tests echo "=== Project usage in e2e-tests.sh ===" rg -C 3 'project' frontend/tests/e2e-tests.sh echo -e "\n=== Existing perimeter test coverage ===" rg -l 'perimeter' frontend/tests/ echo -e "\n=== Test file patterns ===" fd -e ts -e js -e jsx -e tsx . frontend/tests/Length of output: 2560
frontend/src/routes/(app)/(internal)/analytics/composer/+page.svelte (1)
127-127: LGTM! Property access updated correctly.The change from
project.strtoperimeter.straligns with the codebase refactoring from project to perimeter model.backend/app_tests/api/test_api_perimeters.py (2)
21-75: LGTM! Comprehensive test coverage for unauthenticated scenarios.The test class properly covers all CRUD operations for unauthenticated access:
- GET perimeters
- CREATE perimeters
- UPDATE perimeters
- DELETE perimeters
82-173: LGTM! Well-structured authenticated test cases with proper validation.The test class thoroughly covers:
- CRUD operations with authentication
- Status choices validation
- Response structure verification
- Proper folder relationships
frontend/src/routes/(app)/(internal)/[model=urlmodel]/[id=uuid]/+page.server.ts (1)
76-76: LGTM! Model check updated correctly.The condition update from 'projects' to 'perimeters' maintains the same redirect logic while aligning with the new model terminology.
frontend/tests/functional/detailed/compliance-assessments.test.ts (1)
14-14: LGTM! Test requirements updated correctly.The test requirements array has been updated to use 'perimeters' instead of 'projects', maintaining consistency with the model refactoring while preserving the test's functionality.
frontend/tests/utils/test-data.ts (1)
6-6: LGTM! Consistent renaming from project to perimeter.The changes systematically replace project-related keys and permissions with perimeter-related ones across all user roles, maintaining the same access control structure.
Let's verify that no project-related permissions remain:
Also applies to: 34-34, 47-47, 63-63, 81-81, 112-112, 141-141, 156-156, 174-174, 193-193, 214-214
✅ Verification successful
Verification successful: Project to perimeter migration is complete and consistent
The test data shows all permissions have been properly migrated from project to perimeter across all user roles (analyst, reader, domainManager, approver). No legacy project permissions remain in the codebase. The only project references found are unrelated to the permission system (Playwright test configuration).
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for any remaining project-related permissions. # Test: Search for any remaining project-related permissions. Expect: No matches. rg -i 'project' | rg -i 'perm'Length of output: 131070
Script:
#!/bin/bash # Search for permission-related files and check project/perimeter references # Find permission-related files echo "=== Permission files ===" fd -e ts -e js perm # Check for project references in those files echo -e "\n=== Project references in permission files ===" fd -e ts -e js perm --exec rg -i project {} || true # Check for perimeter references in permission files echo -e "\n=== Perimeter references in permission files ===" fd -e ts -e js perm --exec rg -i perimeter {} || trueLength of output: 465
Script:
#!/bin/bash # Examine test data and related files # View test data file content echo "=== Test data file content ===" cat frontend/tests/utils/test-data.ts || true # Look for permission-related types/interfaces echo -e "\n=== Permission types and interfaces ===" rg -t typescript "type.*Permission|interface.*Permission" frontend/ # Check for any remaining project references in frontend tests echo -e "\n=== Project references in frontend tests ===" rg -i project frontend/tests/Length of output: 8592
frontend/tests/functional/user-route.test.ts (3)
128-128: LGTM! Correct perimeter reference in compliance assessment.The path format
${folderName}/${perimeterName}is correctly structured for the perimeter reference.
183-183: LGTM! Correct perimeter reference in risk assessment.The path format
${folderName}/${perimeterName}is correctly structured for the perimeter reference.
217-217: LGTM! Correct perimeter references in risk scenario and acceptance paths.The path formats correctly include the perimeter in the hierarchical structure:
- Risk scenario:
${folderName}/${perimeterName}/${riskAssessmentName} - ${riskAssessmentVersion}- Risk acceptance:
${folderName}/${perimeterName}/${riskAssessmentName} - ${riskAssessmentVersion}/${riskScenarioName}Also applies to: 236-236
frontend/src/routes/(app)/(internal)/risk-scenarios/[id=uuid]/edit/+page.server.ts (1)
139-139: LGTM! Correct folder reference from perimeter.The path to get the folder ID has been correctly updated to use the perimeter object.
Let's verify the perimeter object structure:
✅ Verification successful
✓ Verified: perimeter.folder.id is correctly structured and consistently used
The change is valid as the Perimeter interface properly defines the folder property, and this structure is consistently used across both frontend and backend codebases.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the perimeter object structure in the codebase. # Test: Search for perimeter folder references. Expect: Consistent usage of perimeter.folder.id. ast-grep --pattern 'perimeter.folder.id'Length of output: 724
Script:
#!/bin/bash # Search for perimeter type definitions and implementations # Look for type definitions of perimeter ast-grep --pattern 'type Perimeter = { $$$ }' # Look for interface definitions ast-grep --pattern 'interface Perimeter { $$$ }' # Search for actual implementations using perimeter.folder rg "perimeter\.folder" -t ts -t pyLength of output: 3388
frontend/src/routes/(app)/(internal)/risk-assessments/[id=uuid]/+page.svelte (1)
112-112: LGTM! Correct string reference from perimeter.The path to get the string representation has been correctly updated to use the perimeter object, maintaining the hierarchical display format:
{perimeter.str}/{name} - {version}.Let's verify the string representation format:
✅ Verification successful
Verified: Perimeter string representation is correctly used
The change from
project.strtoperimeter.stris correct and consistent with the codebase's standardized format for perimeter string representation (folder.name/perimeter.name). The hierarchical display format{perimeter.str}/{name} - {version}is maintained across the application.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the perimeter string representation format in the codebase. # Test: Search for perimeter string references. Expect: Consistent usage of perimeter.str. ast-grep --pattern 'perimeter.str'Length of output: 34
Script:
#!/bin/bash # Search for perimeter references and string representations # Look for perimeter references in various contexts rg "perimeter\." -A 2 -B 2 # Search for risk assessment type definitions or interfaces rg "interface.*RiskAssessment|type.*RiskAssessment|class.*RiskAssessment" -A 5 -B 1 # Look for string representation patterns rg "\.str\b" -A 1 -B 1Length of output: 67384
backend/tprm/serializers.py (2)
56-56: LGTM: Field replacement looks correct.The project field has been correctly replaced with a perimeter field using FieldsRelatedField.
98-98: LGTM: Audit creation logic updated correctly.The audit creation logic has been properly updated to use the perimeter model:
- Uses perimeter for audit creation
- Correctly constructs the enclave folder name using perimeter.name
Also applies to: 106-106
backend/app_tests/api/test_api_risk_acceptances.py (2)
5-5: LGTM: Import statement updated correctly.The Project model import has been properly replaced with Perimeter.
142-142: LGTM: Test data creation updated correctly.The test data creation has been properly updated to use Perimeter instances instead of Project instances in both test methods.
Also applies to: 194-194
backend/app_tests/api/test_api_risk_assessments.py (4)
3-3: LGTM: Imports and comments updated correctly.The Project model import and related comments have been properly replaced with Perimeter.
Also applies to: 8-8
30-32: LGTM: Unauthenticated test cases updated correctly.All unauthenticated test cases have been properly updated to use Perimeter instances instead of Project instances.
Also applies to: 49-51, 65-67, 90-92
108-108: LGTM: Authenticated test cases updated correctly.All authenticated test cases have been properly updated:
- Test data creation uses Perimeter
- Response validation checks for perimeter fields
- Object relationships properly maintained
Also applies to: 119-128, 141-141, 152-152, 156-161, 175-177, 190-190, 197-197, 201-206, 219-219, 228-228
239-239: LGTM: Status choice test updated correctly.The TODO comment has been updated to reference Perimeter.PRJ_LC_STATUS instead of Project.PRJ_LC_STATUS.
frontend/src/routes/(app)/(internal)/risk-scenarios/[id=uuid]/+page.svelte (1)
89-92: LGTM: UI updated correctly for perimeter display.The component has been properly updated to display perimeter information:
- Uses correct translation key for perimeter label
- Links to the correct perimeter detail route
- Displays perimeter data consistently
frontend/src/routes/(app)/(internal)/x-rays/+page.svelte (4)
Line range hint
26-40: LGTM!The variable name and data mapping logic correctly align with the perimeter-based structure.
44-47: LGTM!The conditional check correctly uses the renamed variable.
47-56: LGTM!The iteration, URL path, and display string correctly use the perimeter-based structure.
Line range hint
59-280: LGTM!The template consistently uses the perimeter-based structure throughout the tab groups and conditional checks.
backend/app_tests/api/test_api_compliance_assessments.py (5)
4-4: LGTM!The import statement correctly reflects the model change from
ProjecttoPerimeter.
32-34: LGTM!The test correctly creates a Perimeter instance for the compliance assessment.
49-52: LGTM!The test correctly creates a Perimeter instance for creating compliance assessments.
66-76: LGTM!The test correctly creates two Perimeter instances for updating compliance assessments.
90-93: LGTM!The test correctly creates a Perimeter instance for deleting compliance assessments.
frontend/src/routes/(app)/(internal)/risk-scenarios/[id=uuid]/edit/+page.svelte (1)
95-99: LGTM!The text label, URL path, and display string correctly reflect the transition to perimeter-based structure.
backend/ebios_rm/serializers.py (1)
30-30: LGTM!The serializer field correctly uses the perimeter-based structure while maintaining the same field configuration.
frontend/src/lib/components/Forms/ModelForm.svelte (2)
9-9: LGTM! Import statement updated to reflect the new perimeter-centric architecture.The import statement has been correctly updated from
ProjectFormtoPerimeterFormas part of the project → perimeter refactoring.
190-191: LGTM! Conditional rendering updated to use perimeter terminology.The condition has been correctly updated to check for
'perimeters'instead of'projects', maintaining consistency with the new architecture.backend/app_tests/api/test_api_requirement_assessments.py (2)
10-10: LGTM! Import statement updated for the new model.The import statement has been correctly updated to use
Perimeterinstead ofProject.
42-42: LGTM! Test cases updated to use Perimeter model.All test cases have been consistently updated to create and use
Perimeterobjects instead ofProjectobjects, maintaining test coverage while adapting to the new architecture.Also applies to: 80-80, 105-105, 180-180, 216-216, 221-221
backend/core/filters.py (4)
18-18: LGTM! Import statement updated for the new model.The import statement has been correctly updated to use
Perimeterinstead ofProject.
Line range hint
151-177: LGTM! Domain filter class renamed to reflect new terminology.The
ProjectsDomainFilterclass has been correctly renamed toPerimetersDomainFilterwhile maintaining its functionality.
Line range hint
178-203: LGTM! Filter class renamed and placeholder text updated.The
ProjectFilterclass has been correctly renamed toPerimeterFilterwith appropriate updates to the placeholder text.
362-362: LGTM! Field renamed in ComplianceAssessmentFilter.The field has been correctly renamed from
projecttoperimeterin theComplianceAssessmentFilterclass.frontend/src/lib/components/DetailView/DetailView.svelte (2)
179-181: LGTM! Condition updated to use perimeter terminology.The condition has been correctly updated to check for
'perimeters'instead of'projects', maintaining the same related models array.
186-186: LGTM! Related models array updated for folders.The related models array for folders has been correctly updated to use
'perimeters'instead of'projects'.frontend/src/routes/(app)/(third-party)/compliance-assessments/[id=uuid]/+page.svelte (1)
235-235: LGTM! Filter list updated correctly.The filter list has been updated to use 'perimeter' instead of 'project', maintaining consistency with the broader refactoring effort.
cli/clica.py (1)
162-164: LGTM! CLI commands and parameters updated consistently.The CLI tool has been updated to use 'perimeter' terminology instead of 'project', with consistent changes across function names, parameters, variables, and dictionary keys.
Also applies to: 208-208, 218-218, 225-225, 232-232
frontend/src/routes/(app)/(internal)/analytics/+page.svelte (1)
331-334: LGTM! Analytics counter updated consistently.The CounterCard component has been updated to use 'perimeter' terminology instead of 'project', with consistent changes to the count property, label, and navigation href.
backend/serdes/utils.py (1)
19-19: LGTM! Serialization utilities updated consistently.The serialization utilities have been updated to use 'perimeter' terminology instead of 'project', with consistent changes across imports, serializer mappings, queries, and dictionary keys.
Also applies to: 48-48, 212-212, 432-432, 435-435, 466-466, 548-548
backend/app_tests/api/test_api_risk_scenarios.py (1)
16-16: LGTM! Comment updated to reflect new terminology.The comment has been correctly updated from "Generic project data" to "Generic perimeter data" to maintain consistency with the new model.
backend/core/startup.py (1)
24-24: Verify permission migration completeness.The project-to-perimeter permission migration has been applied across all role permission lists:
- READER_PERMISSIONS_LIST
- APPROVER_PERMISSIONS_LIST
- ANALYST_PERMISSIONS_LIST
- DOMAIN_MANAGER_PERMISSIONS_LIST
- ADMINISTRATOR_PERMISSIONS_LIST
Let's verify that no permissions were missed and the hierarchy is maintained:
Also applies to: 53-53, 96-96, 110-110, 127-127, 146-146, 206-206, 221-221, 239-239, 262-262, 343-346
✅ Verification successful
Permission migration successfully verified
The project-to-perimeter permission migration has been completed correctly across all role permission lists. The permission hierarchy is properly maintained, and no legacy project permissions remain in the active codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify permission migration completeness # Check for any remaining 'project' permissions echo "Checking for any remaining project permissions..." rg -i 'project' backend/core/migrations/ # Verify permission hierarchy in migrations echo "Checking permission hierarchy in migrations..." rg -A 5 'permission_classes' backend/core/Length of output: 5569
Script:
#!/bin/bash # Check permission lists in startup.py echo "Checking permission lists in startup.py..." cat backend/core/startup.py # Search for any remaining project permissions in non-migration files echo -e "\nChecking for remaining project permissions in core..." rg -i "project.*permission" backend/core/ --type py -g '!migrations/*'Length of output: 18202
frontend/src/lib/utils/schemas.ts (2)
Line range hint
78-83: LGTM! PerimeterSchema correctly defined.The schema has been properly renamed and structured with appropriate fields:
- name and description from NameDescriptionMixin
- folder as required string
- ref_id as optional nullable string
- lc_status with default value
99-99: Verify schema references are updated consistently.The project to perimeter field updates have been made in:
- RiskAssessmentSchema
- ComplianceAssessmentSchema
- EntityAssessmentSchema
- SCHEMA_MAP
Let's verify all references are updated:
Also applies to: 271-271, 362-362, 494-494
✅ Verification successful
Schema references are updated consistently ✅
The migration from 'project' to 'perimeter' is complete and consistent across all schemas and their usages in the codebase. No remaining references to 'project' were found that need updating.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify schema reference updates # Check for any remaining 'project' references in schema files echo "Checking for remaining project references in schemas..." rg -i 'project' frontend/src/lib/utils/ # Check for any missed schema updates echo "Checking for any missed schema updates..." rg -A 3 'Schema.*=.*z\.object' frontend/src/lib/utils/Length of output: 10448
Script:
#!/bin/bash # Search for SCHEMA_MAP and any remaining project/perimeter references echo "Searching for SCHEMA_MAP..." rg "SCHEMA_MAP" frontend/src/ echo "Checking for project/perimeter references in frontend..." rg -i "project|perimeter" frontend/src/Length of output: 17290
frontend/tests/utils/test-utils.ts (2)
24-24: LGTM! Test fixtures updated correctly.The perimetersPage fixture has been properly added to replace projectsPage in:
- Fixtures type definition
- pages object construction
- page usage
Also applies to: 62-62, 81-81
Line range hint
371-379: Verify test data generation and page content.The test content has been updated to use perimeter instead of project in:
- itemBuilder perimetersPage section
- complianceAssessmentsPage build
- riskAssessmentsPage build
- riskScenariosPage build
- riskAcceptancesPage build
Let's verify the test coverage:
Also applies to: 484-484, 528-528, 550-550, 577-577
✅ Verification successful
All test data sections properly updated to use perimeter instead of project
The verification confirms that all mentioned sections in test-utils.ts have been correctly updated to use perimeter-related fields and paths:
- perimetersPage build section
- complianceAssessmentsPage perimeter field
- riskAssessmentsPage perimeter field
- riskScenariosPage risk_assessment path
- riskAcceptancesPage risk_scenarios path
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify test data and page content updates # Check for any remaining 'project' references in test files echo "Checking for remaining project references in tests..." rg -i 'project' frontend/tests/ # Check test patterns for perimeter-related functionality echo "Checking test patterns for perimeter functionality..." rg -A 3 'test.*perimeter' frontend/tests/Length of output: 2257
Script:
#!/bin/bash # Check the test data structure in the mentioned sections echo "Checking test data structure..." rg -A 10 'perimetersPage.*build' frontend/tests/ rg -A 10 'complianceAssessmentsPage.*build' frontend/tests/ rg -A 10 'riskAssessmentsPage.*build' frontend/tests/ rg -A 10 'riskScenariosPage.*build' frontend/tests/ rg -A 10 'riskAcceptancesPage.*build' frontend/tests/Length of output: 1424
Script:
#!/bin/bash # Examine test-utils.ts directly echo "Checking test-utils.ts content..." cat frontend/tests/utils/test-utils.ts # Also check for any related test data definitions echo -e "\nChecking for related test data definitions..." rg -l "testObjectsData" frontend/tests/Length of output: 18981
frontend/src/lib/utils/table.ts (3)
Line range hint
31-81: LGTM! Filter constants have been correctly renamed.The renaming of filter constants from PROJECT to PERIMETER is consistent with the refactoring objective while maintaining the same functionality.
386-391: LGTM! List view fields configuration updated correctly.The renaming of the 'projects' key to 'perimeters' in listViewFields maintains the same configuration structure while aligning with the new terminology.
433-437: LGTM! Assessment configurations updated consistently.References to project have been correctly updated to perimeter in both risk and compliance assessment configurations.
Also applies to: 623-627
backend/iam/models.py (1)
161-167: LGTM! Path navigation updated correctly.The path navigation in the
get_foldermethod has been properly updated to use 'perimeter' instead of 'project' while maintaining the same traversal logic.Let's verify the path navigation changes with a test:
✅ Verification successful
Path navigation changes verified successfully
The only remaining references to
project.folderare in migration files which is expected and correct, as they document the historical transition. All active folder path navigation now uses 'perimeter' consistently.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that all folder path navigations have been updated from project to perimeter # Test: Search for any remaining references to 'project' in folder path navigation rg -i 'project.*folder' -g '!*.md' -g '!*.po' # Test: Verify the new perimeter folder path navigation exists rg -i 'perimeter.*folder' -g '!*.md' -g '!*.po'Length of output: 65939
frontend/src/routes/(app)/(internal)/compliance-assessments/[id=uuid]/action-plan/+page.svelte (1)
43-47: LGTM! UI references updated correctly.The component has been properly updated to use perimeter instead of project in messages, URLs, and data references while maintaining the same UI functionality.
backend/core/templates/snippets/ra_data.html (1)
10-10: LGTM! Project to perimeter model refactoring.The template has been correctly updated to reference the perimeter model instead of project.
backend/core/templates/core/action_plan_pdf.html (1)
14-14: LGTM! Project to perimeter model refactoring.The template has been correctly updated to:
- Reference the perimeter model instead of project
- Update the display labels from "Project" to "Perimeter"
Also applies to: 16-16
backend/core/templates/snippets/mp_data.html (1)
7-7: LGTM! Project to perimeter model refactoring.The template has been correctly updated to:
- Reference the perimeter model instead of project
- Update the display labels from "Project" to "Perimeter"
Also applies to: 9-9
frontend/messages/ur.json (1)
28-28: LGTM! Keys updated while preserving user-friendly translations.The changes consistently replace "project" with "perimeter" in the keys while retaining the familiar term "پروجیکٹ" (project) in the translations. This approach maintains a good user experience during the backend architectural transition.
Also applies to: 41-41, 81-81, 119-119, 187-187, 189-189, 224-224
frontend/messages/cs.json (1)
26-26: LGTM! Consistent key updates while maintaining user-friendly translations.The changes systematically replace "project" with "perimeter" in the keys while preserving the familiar term "projekt" in the translations. This approach:
- Aligns with the backend architectural changes
- Maintains consistency with other language files
- Ensures a smooth user experience during the transition
Also applies to: 39-39, 79-79, 117-117, 185-185, 187-187, 222-222
frontend/messages/pl.json (1)
28-28: LGTM! Keys renamed consistently while preserving user-facing terminology.The changes in the Polish translation file correctly rename all project-related keys to use "perimeter" while maintaining "projekt" in the displayed text, ensuring a consistent internal architecture change without impacting the user experience.
Also applies to: 41-41, 81-81, 119-119, 187-187, 189-189, 224-224
frontend/messages/ro.json (1)
28-28: LGTM! Keys renamed consistently while preserving user-facing terminology.The changes in the Romanian translation file correctly rename all project-related keys to use "perimeter" while maintaining "proiect" in the displayed text, ensuring a consistent internal architecture change without impacting the user experience.
Also applies to: 41-41, 81-81, 119-119, 187-187, 189-189, 224-224
frontend/messages/pt.json (1)
28-28: LGTM! Keys renamed consistently while preserving user-facing terminology.The changes in the Portuguese translation file correctly rename all project-related keys to use "perimeter" while maintaining "projeto" in the displayed text, ensuring a consistent internal architecture change without impacting the user experience.
Also applies to: 41-41, 81-81, 119-119, 187-187, 189-189, 224-224
frontend/messages/it.json (1)
28-28: Verify if keeping "project" in display text is intentional.The keys have been renamed from "project" to "perimeter" but the displayed text still shows "progetto" (project). For example:
addPerimeter: "Aggiungi progetto"associatedPerimeters: "Progetti associati"perimeters: "Progetti"perimeter: "Progetto"myPerimeters: "I miei progetti"assignedPerimeters: "Assegnato al progetto{i} {number}"perimetersSummaryEmpty: "Riepilogo del progetto"Is this intentional to keep the UI showing "projects" while refactoring the backend?
Also applies to: 41-41, 81-81, 119-119, 187-187, 189-189, 224-224
✅ Verification successful
Keeping "project" in display text is intentional
This appears to be a deliberate choice to maintain user-friendly terminology in the UI ("progetto") while using more technically precise terms ("perimeter") in the codebase. This pattern is consistently applied across all Italian translations, suggesting it's an intentional decision to preserve a familiar user experience.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if this pattern is consistent across the codebase # Check for any remaining "project" references in code echo "Checking for remaining 'project' references..." rg -i "project" --type ts --type js --type py # Check for new "perimeter" terminology echo "Checking for new 'perimeter' terminology..." rg -i "perimeter" --type ts --type js --type pyLength of output: 56460
frontend/messages/es.json (1)
28-28: Same inconsistency found in Spanish translations.The keys have been renamed but the displayed text still shows "proyecto" (project). For example:
addPerimeter: "Agregar proyecto"associatedPerimeters: "Proyectos asociados"perimeters: "Proyectos"perimeter: "Proyecto"myPerimeters: "Mis proyectos"assignedPerimeters: "Asignado a {number} proyecto{s}"perimetersSummaryEmpty: "Resumen de proyectos vacío"Also applies to: 41-41, 81-81, 119-119, 187-187, 189-189, 224-224
frontend/messages/de.json (1)
28-28: Same inconsistency found in German translations.The keys have been renamed but the displayed text still shows "Projekt" (project). For example:
addPerimeter: "Projekt hinzufügen"associatedPerimeters: "Zugehörige Projekte"perimeters: "Projekte"perimeter: "Projekt"myPerimeters: "Meine Projekte"assignedPerimeters: "Zugewiesen zu {number} Projekt{en}"perimetersSummaryEmpty: "Projektzusammenfassung ist leer"Also applies to: 41-41, 81-81, 119-119, 187-187, 189-189, 224-224
frontend/messages/id.json (8)
29-29: LGTM! Key renamed while preserving the translation.The key has been updated from
addProjecttoaddPerimeterwhile correctly maintaining the Indonesian translation "Tambahkan proyek".
42-42: LGTM! Key renamed while preserving the translation.The key has been updated from
associatedProjectstoassociatedPerimeterswhile correctly maintaining the Indonesian translation "Proyek terkait".
84-84: LGTM! Key renamed while preserving the translation.The key has been updated from
projectstoperimeterswhile correctly maintaining the Indonesian translation "Proyek".
122-122: LGTM! Key renamed while preserving the translation.The key has been updated from
projecttoperimeterwhile correctly maintaining the Indonesian translation "Proyek".
190-190: LGTM! Key renamed while preserving the translation.The key has been updated from
myProjectstomyPerimeterswhile correctly maintaining the Indonesian translation "Proyek saya".
192-192: LGTM! Key renamed while preserving the translation.The key has been updated from
assignedProjectstoassignedPerimeterswhile correctly maintaining the Indonesian translation "Ditugaskan ke {number} proyek{s}".
Line range hint
214-215: LGTM! Updated terminology in description while maintaining context.The description has been updated to use "perimeters" instead of "projects" while maintaining the clear explanation of the composer functionality.
227-227: LGTM! Key renamed while preserving the translation.The key has been updated from
projectsSummaryEmptytoperimetersSummaryEmptywhile correctly maintaining the Indonesian translation "Ringkasan proyek kosong".frontend/messages/en.json (10)
28-28: LGTM! Consistent terminology update.The key and value have been updated from project to perimeter terminology.
41-41: LGTM! Consistent terminology update.The key and value have been updated from project to perimeter terminology.
83-83: LGTM! Consistent terminology update.The key and value have been updated from project to perimeter terminology.
121-121: LGTM! Consistent terminology update.The key and value have been updated from project to perimeter terminology.
189-189: LGTM! Consistent terminology update.The key and value have been updated from project to perimeter terminology.
191-191: LGTM! Consistent terminology update.The key and value have been updated from project to perimeter terminology while maintaining the dynamic placeholder format.
214-215: LGTM! Updated terminology in description while maintaining clarity.The composer description has been updated to use "perimeters" instead of "projects" while maintaining clear explanation of the functionality and use cases.
226-226: LGTM! Consistent terminology update.The key and value have been updated from project to perimeter terminology.
767-767: LGTM! Consistent terminology update.The error message has been updated to use "perimeter" terminology.
1102-1103: LGTM! Updated tour descriptions with new terminology.The tour descriptions have been updated to use "perimeter" terminology while maintaining clear guidance for users.
| _fields["perimeter"] = Perimeter.objects.get( | ||
| id=link_dump_database_ids.get(_fields["perimeter"]) |
There was a problem hiding this comment.
💡 Codebase verification
Add error handling for Perimeter.objects.get() calls
The suggestion to add validation is correct. The current implementation assumes the Perimeter object exists, which could lead to unhandled exceptions. The proposed try-except pattern would make the code more robust.
🔗 Analysis chain
Validate _fields["perimeter"] before calling .get().
Similar to line 980, consider handling cases where Perimeter may not exist.
try:
- _fields["perimeter"] = Perimeter.objects.get(
- id=link_dump_database_ids.get(_fields["perimeter"])
- )
+ perimeter_id = link_dump_database_ids.get(_fields["perimeter"])
+ _fields["perimeter"] = Perimeter.objects.get(id=perimeter_id)
except Perimeter.DoesNotExist:
...🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Get context around line 980 and the current implementation
rg -A 5 -B 5 "Perimeter\.objects\.get" backend/core/views.py
# Find similar patterns of Perimeter object retrieval and validation
ast-grep --pattern 'try {
$$$
Perimeter.objects.get($$$)
$$$
}'
Length of output: 1540
Script:
#!/bin/bash
# Get line 980 and surrounding context
rg -A 10 -B 10 -n "^980:" backend/core/views.py
# Look for try-except blocks around Perimeter handling
rg -A 10 -B 10 "try:.*\n.*Perimeter" backend/core/views.py
Length of output: 302
Script:
#!/bin/bash
# Look for try-except blocks around Perimeter with fixed pattern
rg -U -A 10 -B 10 "try:.*Perimeter" backend/core/views.py
# Get specific line context
head -n 990 backend/core/views.py | tail -n 21
Length of output: 952
🧰 Tools
🪛 Ruff (0.8.2)
2596-2596: Perimeter may be undefined, or defined from star imports
(F405)
backend/app_tests/test_vars.py
Outdated
| @@ -15,7 +15,7 @@ | |||
| FRAMEWORKS_ENDPOINT = "frameworks-list" | |||
| STORED_LIBRARIES_ENDPOINT = "stored-libraries-list" | |||
| RISK_MATRICES_ENDPOINT = "risk-matrices-list" | |||
| PROJECTS_ENDPOINT = "projects-list" | |||
| PERIMETERS_ENDPOINT = "perimeter-list" | |||
There was a problem hiding this comment.
💡 Codebase verification
Update test_api_perimeters.py to use PERIMETERS_ENDPOINT constant
The endpoint has proper test coverage with both authenticated and unauthenticated test cases. However, the test file should be updated to use the PERIMETERS_ENDPOINT constant from test_vars.py instead of the hardcoded "Perimeters" string for consistency.
- Update backend/app_tests/api/test_api_perimeters.py to:
- Import PERIMETERS_ENDPOINT from test_vars.py
- Replace all occurrences of "Perimeters" with PERIMETERS_ENDPOINT
🔗 Analysis chain
Verify test coverage for the new endpoint.
The PERIMETERS_ENDPOINT constant has been added correctly. However, we should ensure that all test cases previously using PROJECTS_ENDPOINT have been updated to use this new endpoint.
Let's check for any remaining references to the old endpoint:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining PROJECTS_ENDPOINT references
rg "PROJECTS_ENDPOINT" "backend/app_tests/"
# Search for any test files containing "project" in their names
fd -t f "test.*project" "backend/app_tests/"
Length of output: 86
Script:
#!/bin/bash
# Check directory structure
ls -R backend/
# Find all references to the new endpoint
rg "PERIMETERS_ENDPOINT" backend/
# List all test files
fd -e py "test_.*\.py$" backend/
Length of output: 12172
Script:
#!/bin/bash
# Check the content of perimeters test file
cat backend/app_tests/api/test_api_perimeters.py
# Also check if test_vars.py is imported in the test file
rg "from ..test_vars import" backend/app_tests/api/test_api_perimeters.py
Length of output: 5732
| @@ -77,7 +77,7 @@ | |||
| AppliedControl, | |||
| Evidence, | |||
| Framework, | |||
| Project, | |||
| Perimeter, | |||
There was a problem hiding this comment.
Remove duplicate imports.
The imports of Perimeter and PerimeterImportExportSerializer are duplicated. They are already imported at lines 19 and 48 respectively.
Apply this diff to remove the duplicate imports:
- Perimeter,
RiskAssessment,
RiskMatrix,
RiskScenario,
ComplianceAssessment,
RequirementAssessment,
Vulnerability,
Threat,
ReferenceControl,
LoadedLibrary,
)
from ebios_rm.models import (
EbiosRMStudy,
FearedEvent,
RoTo,
OperationalScenario,
Stakeholder,
StrategicScenario,
AttackPath,
)
from tprm.models import Entity
from core.serializers import (
FolderImportExportSerializer,
AssetImportExportSerializer,
AppliedControlImportExportSerializer,
EvidenceImportExportSerializer,
- PerimeterImportExportSerializer,
RiskAssessmentImportExportSerializer,Also applies to: 109-109
🧰 Tools
🪛 Ruff (0.8.2)
80-80: Redefinition of unused Perimeter from line 19
Remove definition: Perimeter
(F811)
| perimeter=Perimeter.objects.create(name="test", folder=folder), | ||
| risk_matrix=RiskMatrix.objects.create(name="test", folder=folder), | ||
| ), |
There was a problem hiding this comment.
💡 Codebase verification
Additional test coverage needed for Perimeter model
The current test coverage is insufficient. The following test scenarios should be added:
- Lifecycle state transitions through all states (undefined → in_design → in_dev → in_prod → eol/dropped)
- Validation of Perimeter-RiskAssessment relationships
- Deletion scenarios and their impact on related RiskAssessments
Specific files to update:
backend/app_tests/api/test_api_perimeters.py: Add lifecycle state transition testsbackend/app_tests/api/test_api_risk_assessments.py: Add Perimeter relationship tests
🔗 Analysis chain
Verify test coverage for Perimeter model transition.
The test cases have been updated to use the new Perimeter model instead of Project. While the changes look correct, ensure that all edge cases are covered:
- Perimeter creation with various states
- Perimeter relationships with RiskAssessment
- Perimeter deletion scenarios
Let's verify the test coverage:
Also applies to: 172-174, 197-199, 215-217, 337-338, 342-343, 418-419
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check test coverage for Perimeter model and related functionality
# Check for any remaining references to 'project' in test files
echo "Checking for any remaining 'project' references in tests..."
rg -i 'project' backend/app_tests/
# Check test coverage patterns for Perimeter
echo "Checking test patterns for Perimeter model..."
rg -A 3 'def test.*perimeter' backend/app_tests/
Length of output: 3062
Script:
#!/bin/bash
# Check test implementations and relationships
# Check state/status handling in perimeter tests
echo "Checking state handling in perimeter tests..."
rg -A 10 'status.*=.*' backend/app_tests/api/test_api_perimeters.py
# Check RiskAssessment-Perimeter relationship tests
echo "Checking RiskAssessment-Perimeter relationship tests..."
rg -A 5 'RiskAssessment.*perimeter' backend/app_tests/
# Check deletion cascade tests
echo "Checking deletion cascade tests..."
rg -A 10 'delete.*cascade' backend/app_tests/
rg -A 10 'on_delete' backend/app_tests/
Length of output: 882
Script:
#!/bin/bash
# Check model definitions and additional tests
# Check Perimeter model definition
echo "Checking Perimeter model definition..."
rg -A 15 'class Perimeter' backend/
# Check RiskAssessment model definition
echo "Checking RiskAssessment model definition..."
rg -A 15 'class RiskAssessment' backend/
# Look for additional test files
echo "Checking for additional test files..."
fd test_.*py$ backend/app_tests/ | grep -v '__pycache__'
Length of output: 10648
| msgid "Perimeter" | ||
| msgstr "Projet" | ||
|
|
||
| #: core/models.py:1323 | ||
| msgid "Projects" | ||
| msgid "Perimeters" |
There was a problem hiding this comment.
Update French translations for consistency.
The French translations still use "Projet" and "Projets" which is inconsistent with the perimeter refactoring:
msgid "Perimeter"
-msgstr "Projet"
+msgstr "Périmètre"
msgid "Perimeters"
-msgstr "Projets"
+msgstr "Périmètres"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| msgid "Perimeter" | |
| msgstr "Projet" | |
| #: core/models.py:1323 | |
| msgid "Projects" | |
| msgid "Perimeters" | |
| msgid "Perimeter" | |
| msgstr "Périmètre" | |
| #: core/models.py:1323 | |
| msgid "Perimeters" | |
| msgstr "Périmètres" |
| @@ -25,7 +25,7 @@ | |||
| "addComplianceAssessment": "ابدأ التدقيق", | |||
| "addEvidence": "أضف دليلًا", | |||
| "addDomain": "أضف نطاقًا", | |||
| "addProject": "أضف مشروعًا", | |||
| "addPerimeter": "أضف مشروعًا", | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Update Arabic translations to use the equivalent of "perimeter" instead of "project".
While the keys have been updated from project to perimeter, the Arabic translations still use the word for "project" (مشروع). This inconsistency could confuse Arabic users as the UI will use "perimeter" in the code but display "project" in Arabic.
Consider updating these translations to use the Arabic equivalent of "perimeter" (محيط) for consistency with the new terminology:
- "addPerimeter": "أضف مشروعًا",
+ "addPerimeter": "أضف محيطًا",
- "associatedPerimeters": "المشاريع المرتبطة",
+ "associatedPerimeters": "المحيطات المرتبطة",
- "perimeters": "المشاريع",
+ "perimeters": "المحيطات",
- "perimeter": "المشروع",
+ "perimeter": "المحيط",
- "myPerimeters": "مشاريعي",
+ "myPerimeters": "محيطاتي",
- "assignedPerimeters": "مُعين إلى {number} مشروع",
+ "assignedPerimeters": "مُعين إلى {number} محيط",
- "perimetersSummaryEmpty": "ملخص المشاريع فارغ",
+ "perimetersSummaryEmpty": "ملخص المحيطات فارغ"Also applies to: 41-41, 82-82, 120-120, 188-188, 190-190, 225-225
| @@ -25,7 +25,7 @@ | |||
| "addComplianceAssessment": "नया ऑडिट", | |||
| "addEvidence": "साक्ष्य जोड़ें", | |||
| "addDomain": "डोमेन जोड़ें", | |||
| "addProject": "प्रोजेक्ट जोड़ें", | |||
| "addPerimeter": "प्रोजेक्ट जोड़ें", | |||
There was a problem hiding this comment.
Update Hindi translations to use perimeter terminology.
The Hindi translations still use "प्रोजेक्ट" (project) while the keys have been updated to use "perimeter". This creates an inconsistency in terminology between the application's internal representation and the user interface.
Consider updating the translations to use the Hindi equivalent of "perimeter" (e.g., "परिधि") to maintain consistency with the application's new terminology. Here's a suggested mapping:
- "addPerimeter": "प्रोजेक्ट जोड़ें",
+ "addPerimeter": "परिधि जोड़ें",
- "associatedPerimeters": "संबंधित प्रोजेक्ट",
+ "associatedPerimeters": "संबंधित परिधि",
- "perimeters": "प्रोजेक्ट्स",
+ "perimeters": "परिधियाँ",
- "perimeter": "प्रोजेक्ट",
+ "perimeter": "परिधि",
- "myPerimeters": "मेरे प्रोजेक्ट",
+ "myPerimeters": "मेरी परिधियाँ",
- "assignedPerimeters": "{number} प्रोजेक्ट{s} के लिए असाइन किया गया",
+ "assignedPerimeters": "{number} परिधि{s} के लिए असाइन किया गया",
- "perimetersSummaryEmpty": "प्रोजेक्ट्स सारांश खाली है",
+ "perimetersSummaryEmpty": "परिधि सारांश खाली है"Also applies to: 41-41, 81-81, 119-119, 187-187, 189-189, 224-224
| @@ -25,7 +25,7 @@ | |||
| "addComplianceAssessment": "Ny revision", | |||
| "addEvidence": "Lägg till bevis", | |||
| "addDomain": "Lägg till domän", | |||
| "addProject": "Lägg till projekt", | |||
| "addPerimeter": "Lägg till projekt", | |||
There was a problem hiding this comment.
Update Swedish translations to use perimeter terminology.
The Swedish translations still use "projekt" (project) while the keys have been updated to use "perimeter". This creates an inconsistency in terminology between the application's internal representation and the user interface.
Consider updating the translations to use the Swedish equivalent of "perimeter" (e.g., "perimeter" or "omkrets") to maintain consistency with the application's new terminology. Here's a suggested mapping:
- "addPerimeter": "Lägg till projekt",
+ "addPerimeter": "Lägg till perimeter",
- "associatedPerimeters": "Associerade projekt",
+ "associatedPerimeters": "Associerade perimetrar",
- "perimeters": "Projekt",
+ "perimeters": "Perimetrar",
- "perimeter": "Projekt",
+ "perimeter": "Perimeter",
- "myPerimeters": "Mina projekt",
+ "myPerimeters": "Mina perimetrar",
- "assignedPerimeters": "Tilldelad till {number} projekt{s}",
+ "assignedPerimeters": "Tilldelad till {number} perimeter{s}",
- "perimetersSummaryEmpty": "Projektöversikten är tom",
+ "perimetersSummaryEmpty": "Perimeteröversikten är tom"Also applies to: 41-41, 83-83, 121-121, 189-189, 191-191, 226-226
| @@ -25,7 +25,7 @@ | |||
| "addComplianceAssessment": "Démarrer l'audit", | |||
| "addEvidence": "Ajouter une preuve", | |||
| "addDomain": "Ajouter un domaine", | |||
| "addProject": "Ajouter un projet", | |||
| "addPerimeter": "Ajouter un projet", | |||
There was a problem hiding this comment.
Inconsistent terminology between keys and values
The keys have been updated to use "perimeter" terminology, but the corresponding French translations still use "projet". This creates an inconsistency between the application's data model and the user interface.
Apply this diff to align the terminology:
- "addPerimeter": "Ajouter un projet",
+ "addPerimeter": "Ajouter un périmètre",
- "associatedPerimeters": "Projets associés",
+ "associatedPerimeters": "Périmètres associés",
- "perimeters": "Projets",
+ "perimeters": "Périmètres",
- "perimeter": "Projet",
+ "perimeter": "Périmètre",
- "myPerimeters": "Mes projets",
+ "myPerimeters": "Mes périmètres",
- "assignedPerimeters": "Assigné à {number} projet{s}",
+ "assignedPerimeters": "Assigné à {number} périmètre{s}",
- "perimetersSummaryEmpty": "Le résumé des projets est vide",
+ "perimetersSummaryEmpty": "Le résumé des périmètres est vide",Also applies to: 41-41, 83-83, 121-121, 189-189, 191-191, 226-226
| "tourPerimetersDescription": "Les projets sont des périmètres fonctionnels au sein d'un domaine. Vous en aurez besoin d'au moins un. <br/><b>Cliquez dessus</b>.", | ||
| "tourPerimeterAddDescription": "C'est ici que vous pourrez créer un projet.", |
There was a problem hiding this comment.
Update tour messages to use consistent terminology
The guided tour messages still reference "projects" instead of "perimeters".
Apply this diff to maintain terminology consistency:
- "tourPerimetersDescription": "Les projets sont des périmètres fonctionnels au sein d'un domaine. Vous en aurez besoin d'au moins un. <br/><b>Cliquez dessus</b>.",
+ "tourPerimetersDescription": "Les périmètres sont des zones fonctionnelles au sein d'un domaine. Vous en aurez besoin d'au moins un. <br/><b>Cliquez dessus</b>.",
- "tourPerimeterAddDescription": "C'est ici que vous pourrez créer un projet.",
+ "tourPerimeterAddDescription": "C'est ici que vous pourrez créer un périmètre.",📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "tourPerimetersDescription": "Les projets sont des périmètres fonctionnels au sein d'un domaine. Vous en aurez besoin d'au moins un. <br/><b>Cliquez dessus</b>.", | |
| "tourPerimeterAddDescription": "C'est ici que vous pourrez créer un projet.", | |
| "tourPerimetersDescription": "Les périmètres sont des zones fonctionnelles au sein d'un domaine. Vous en aurez besoin d'au moins un. <br/><b>Cliquez dessus</b>.", | |
| "tourPerimeterAddDescription": "C'est ici que vous pourrez créer un périmètre.", |
ab-smith
changed the title
ab-smith
changed the title
Better to do that before PMBOK project management
Summary by CodeRabbit
Release Notes: Major Terminology and Model Update
Overview
This release introduces a significant transformation from a project-based model to a perimeter-based model across the entire application. This change impacts data structures, user interfaces, permissions, and terminology.
Key Changes
Terminology Shift:
Data Model Updates:
Projectmodel toPerimeter.perimeterinstead ofproject.Frontend Modifications:
Permissions:
view_project,add_project, etc., with corresponding perimeter permissions.Impact
Recommended Actions