Skip to content

Api v2 get customer#955

Merged
whikernel merged 69 commits intodevelopfrom
api_v2_get_customer
Jan 11, 2026
Merged

Api v2 get customer#955
whikernel merged 69 commits intodevelopfrom
api_v2_get_customer

Conversation

@c8y3
Copy link
Contributor

@c8y3 c8y3 commented Oct 24, 2025

Implementation of GET /api/v2/manage/customers/{identifier}

  • Deprecated GET /manage/customers/<int:client_id>
  • Moved the .env which is used in tests at the top level (file .env.tests.model). Ideally, I would have prefered to use .env.dev.model, but it requires to clone the new front-end repository. Which would complexify the CI. And I believe repositories should ideally be entirely self-contained.
  • Added some more import constraints and fixed the warnings
    The associated documentation is in PR#90 of iris-doc-src.

Summary by CodeRabbit

Release Notes

  • New Features

    • Added customer retrieval capabilities with improved error handling and not-found responses.
    • Enhanced dashboard case filtering based on user role and permissions.
  • Bug Fixes

    • Improved access control filtering for IoC links based on user permissions.
    • Fixed case state serialization in API responses.
  • Refactor

    • Standardized API method naming across REST endpoints for consistency.
    • Enhanced case creation workflow with better context management.
    • Improved customer data retrieval operations with robust validation.
  • Documentation

    • Updated development environment setup instructions.
  • Tests

    • Expanded customer retrieval test coverage including error scenarios.

Elise17 added 30 commits October 8, 2025 14:04
@c8y3 c8y3 requested a review from whikernel October 24, 2025 09:27
@c8y3 c8y3 added the enhancement New feature or request label Oct 24, 2025
@coderabbitai
Copy link

coderabbitai bot commented Oct 24, 2025

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

🗂️ Base branches to auto review (1)
  • api_*

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

This pull request refactors user context handling throughout the application by adding explicit user parameters to business logic functions, renaming customer-related functions to align terminology, restructuring access control assignment flows, and updating REST API method names from get to read for consistency. Additionally, it updates CI configuration, adds import linting rules, and implements case state serialization.

Changes

Cohort / File(s) Summary
CI & Configuration
.github/workflows/ci.yml, pyproject.toml
Updated CI environment setup to copy .env.tests.model directly to .env instead of using --env-file with basic.env. Added three new import-linter contracts for cross-layer import restrictions (API from business, marshables from persistence, engine from persistence).
REST v2 API Method Renames (get → read)
source/app/blueprints/rest/v2/alerts.py, source/app/blueprints/rest/v2/case_routes/events.py, source/app/blueprints/rest/v2/manage_routes/groups.py, source/app/blueprints/rest/v2/manage_routes/customers.py
Renamed public methods from get(self, identifier) to read(self, identifier) and updated corresponding call sites. Customers endpoint additionally added error handling (ObjectNotFoundError) and a new read() method for fetching individual customers.
Customer/Client Refactoring
source/app/datamgmt/client/client_db.py, source/app/business/customers.py, source/app/blueprints/pages/manage/manage_customers_routes.py, source/app/blueprints/rest/manage/manage_customers_routes.py, tests/tests_rest_customers.py
Renamed get_client() to get_customer(), create_client() to create_customer(). Added new functions customers_get(), customers_get_by_name(), customers_create_with_user() with not-found error handling. Updated all call sites. Tests added for customer GET operations (200, 404, 403 scenarios).
Case Creation with Explicit User Context
source/app/business/cases.py, source/app/blueprints/graphql/cases.py, source/app/blueprints/rest/manage/manage_cases_routes.py, source/app/blueprints/rest/v2/cases.py
Updated cases_create() signature to accept user as first parameter: cases_create(user, case, case_template_id). Added cases_filter_by_user(user, show_all) and cases_filter_by_reviewer(user) with explicit user parameters. Added cases_get_first_with_customer(client) helper. Updated all call sites across GraphQL and REST layers.
Case IoCs & Alerts User Context
source/app/blueprints/rest/case/case_ioc_routes.py, source/app/blueprints/rest/alerts_routes.py, source/app/datamgmt/case/case_iocs_db.py
Updated get_ioc_links() to accept user_search_limitations parameter; moved limitation computation from database layer to caller. Updated alerts escalation routes to pass iris_current_user instead of None to access control functions.
Access Control Restructuring
source/app/business/access_controls.py, source/app/iris_engine/access_control/utils.py, source/app/datamgmt/manage/manage_access_control_db.py
Renamed set_user_case_effective_access() to add_user_case_effective_access() and reordered parameters. Added add_several_user_effective_access() for batch user permission assignment. Refactored ac_set_new_case_access() signature to accept explicit user instead of org_members list. Added get_user_access_levels_by_customer() and set_user_case_access() helpers.
Case State Serialization
source/app/blueprints/pages/manage/manage_cases_routes.py, source/app/blueprints/rest/manage/manage_case_state.py, source/app/datamgmt/manage/manage_case_state_db.py
Updated get_case_states_list() to return raw ORM objects instead of serialized dicts. Added serialization at template/endpoint levels using CaseStateSchema(many=True).dump().
Case Data Access Layer
source/app/datamgmt/case/case_db.py
Updated get_first_case() return type to Optional[Cases]. Added get_first_case_with_customer(customer_identifier) to query cases by customer. Split imports into separate lines for style consistency.
Dashboard User Context
source/app/blueprints/rest/v2/dashboard.py
Updated list_own_cases() to pass iris_current_user to cases_filter_by_user(). Updated list_own_reviews() to pass iris_current_user to cases_filter_by_reviewer().
User & Group Access Management
source/app/datamgmt/manage/manage_users_db.py, source/app/datamgmt/manage/manage_groups_db.py
Moved import source of ac_access_level_mask_from_val_list from app.iris_engine.access_control.utils to app.models.authorization. Reorganized import statements.
Models & Authorization
source/app/models/authorization.py, source/app/models/models.py
Added ac_access_level_mask_from_val_list() function to compute bitmask from access levels. Simplified get_or_create() control flow without changing observable behavior.
Post-Initialization
source/app/post_init.py
Refactored to use customers_get_by_name() and customers_create() with new helpers. Updated to use cases_get_first_with_customer() and add_several_user_effective_access() for batch operations. Changed create_safe_client() return type to Client.
Schema & Marshalling
source/app/schema/marshables.py
Updated IocSchemaForAPIV2.get_link() to accept user_search_limitations from caller instead of computing internally. Removed public validator functions validate_ioc_type() and validate_ioc_tlp().
Events Business Logic
source/app/business/events.py
Updated update_timeline_state() call to use positional argument instead of keyword argument caseid=.
Test Updates
tests/README.md, tests/tests_rest_comments.py, tests/tests_rest_customers.py
Added development server startup instructions. Renamed test method to test_get_notes_comments_should_return_200_when_there_is_a_comment(). Added tests for customer retrieval (existing, non-existent, permission-denied scenarios).

Sequence Diagrams

sequenceDiagram
    participant User
    participant API
    participant Business
    participant AccessControl
    participant DB

    rect rgb(200, 220, 240)
    note right of User: Old Case Creation Flow
    User->>API: POST /cases
    API->>Business: cases_create(case, template_id)
    Business->>AccessControl: ac_set_new_case_access(org_members, case_id)
    AccessControl->>DB: [implicit user from context]
    end

    rect rgb(220, 240, 200)
    note right of User: New Case Creation Flow
    User->>API: POST /cases (with iris_current_user)
    API->>Business: cases_create(iris_current_user, case, template_id)
    Business->>Business: case.owner_id = user.id
    Business->>AccessControl: ac_set_new_case_access(user, case_id, customer_id)
    AccessControl->>DB: add_several_user_effective_access([user.id], case_id, ...)
    AccessControl->>DB: set_user_case_access(user, case_id)
    end
Loading
sequenceDiagram
    participant Caller
    participant IocRoutes
    participant DB as case_iocs_db
    participant AC as access_control

    rect rgb(240, 220, 200)
    note right of Caller: Old IoC Links Flow
    Caller->>IocRoutes: GET /case/{id}/iocs/{ioc_id}/links
    IocRoutes->>DB: get_ioc_links(ioc_id)
    DB->>AC: [internally calls ac_get_fast_user_cases_access]
    DB-->>IocRoutes: [filtered links]
    end

    rect rgb(200, 240, 220)
    note right of Caller: New IoC Links Flow (Caller Computes Limits)
    Caller->>IocRoutes: GET /case/{id}/iocs/{ioc_id}/links
    IocRoutes->>AC: ac_get_fast_user_cases_access(user.id)
    AC-->>IocRoutes: user_limitations
    IocRoutes->>DB: get_ioc_links(ioc_id, user_limitations)
    DB-->>IocRoutes: [filtered links]
    end
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Rationale: This PR spans ~40 files with heterogeneous changes including function signature updates across multiple layers (business, data access, REST API), rename refactorings (client→customer), explicit user context threading through case/access control logic, and access control restructuring. While many changes follow consistent patterns (get→read renames, user parameter additions), each affected layer requires verification that the parameter threading is correct and access control logic remains sound. The scope, cross-layer impact, and logic density (especially in access control and case creation) warrant careful review of signature changes, call sites, and authorization implications.

Possibly related PRs

  • Api v2 create object comment #914: Overlapping changes to comments subsystem, access control (ac_fast_* imports), and IoC link handling (get_ioc_links refactoring and IocSchema usage pattern).
  • Tidy imports #928: Related CI configuration and import-linter contract modifications to pyproject.toml for enforcing cross-layer import restrictions.
  • Auth with jwt #780: Earlier user context handling refactor introducing iris_current_user and access control flow updates across overlapping authentication/authorization modules.

Suggested reviewers

  • whikernel

Poem

🐰 A rabbit's ode to refactored flows:

User context flows more clear,
Like carrots lined up, year by year,
No implicit magic in the air—
Explicit paths show owners care!
From get to read, the APIs dance,
As access control finds its stance. 🌟

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 25.29% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Title Check ✅ Passed The title "Api v2 get customer" is specific and directly references the implementation of a new GET endpoint for retrieving customers via the v2 API, which is confirmed as a primary objective in the PR description. While the changeset includes broader refactoring work (explicit user context threading throughout case creation, customer handling, and access control flows), the title accurately captures the main new feature being delivered. A teammate reviewing commit history would understand that this PR adds customer retrieval functionality to the v2 API, which aligns with the stated objective to "Implement GET /api/v2/manage/customers/{identifier}".
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@c8y3 c8y3 changed the base branch from api_v2_delete_alert_filter to develop October 24, 2025 09:27
@c8y3 c8y3 linked an issue Oct 24, 2025 that may be closed by this pull request
9 tasks
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 10

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)
source/app/datamgmt/manage/manage_case_state_db.py (1)

22-28: Fix incorrect return type annotation.

The function signature declares -> List[dict] but the implementation now returns CaseState.query.all(), which yields a list of CaseState ORM objects, not dictionaries. This breaks the contract and will mislead callers.

Apply this diff to correct the return type:

-def get_case_states_list() -> List[dict]:
+def get_case_states_list() -> List[CaseState]:
     """Get a list of case state
 
     Returns:
-        List[dict]: List of case state
+        List[CaseState]: List of case state
     """
     return CaseState.query.all()

Also add the import at the top of the file if not already present:

from app.models.cases import CaseState
source/app/blueprints/rest/manage/manage_customers_routes.py (1)

309-310: Misleading activity message (“Customer” vs “Contact”).

Should log “Deleted contact …”.

-    track_activity(f"Deleted Customer with ID {contact_id}", ctx_less=True)
+    track_activity(f"Deleted contact with ID {contact_id}", ctx_less=True)
🧹 Nitpick comments (8)
source/app/business/events.py (1)

47-47: Consider consistent argument style within the file.

Line 47 now uses a positional argument while line 80 uses a keyword argument (caseid=) for the same function. For consistency and clarity, consider using the same style throughout.

Apply this diff to make line 80 consistent with line 47:

-    update_timeline_state(caseid=event.case_id)
+    update_timeline_state(event.case_id)

Or alternatively, revert line 47 to use the keyword argument to match line 80:

-    update_timeline_state(case_identifier)
+    update_timeline_state(caseid=case_identifier)
source/app/blueprints/rest/manage/manage_customers_routes.py (3)

65-65: Deprecation wrapper applied correctly.

Link header to /api/v2/manage/customers/{identifier} and Deprecation header are fine. Optionally add a Sunset header in endpoints.py to signal removal timeline.


85-86: Pre-flight existence checks OK.

Using get_customer(client_id) before mutating contacts is fine. Consider 404 for parity with v2, but not required here.

Also applies to: 114-116


250-267: Deduplicate create side-effects via business layer.

This route manually tracks activity and associates the user after create; mirror of customers_create_with_user. Centralize to avoid drift.

- from app.datamgmt.client.client_db import create_customer
+ from app.business.customers import customers_create_with_user
@@
-        create_customer(customer)
+        customers_create_with_user(iris_current_user, customer)
@@
-    track_activity(f"Added customer {customer.name}", ctx_less=True)
-
-    # Associate the created customer with the current user
-    add_user_to_customer(iris_current_user.id, customer.client_id)
+    # side-effects handled in customers_create_with_user
source/app/blueprints/rest/v2/manage_routes/customers.py (1)

71-74: Rename handler for clarity.

get_event handles a customer resource; rename to get_customer to avoid confusion.

-@customers_blueprint.get('/<int:identifier>')
-@ac_api_requires(Permissions.customers_read))
-def get_event(identifier):
-    return customers.read(identifier)
+@customers_blueprint.get('/<int:identifier>')
+@ac_api_requires(Permissions.customers_read))
+def get_customer(identifier):
+    return customers.read(identifier)
source/app/business/customers.py (2)

28-31: Return the created entity for consistency.

Returning the customer aligns with customers_create_with_user and simplifies callers.

-def customers_create(customer: Client):
-    create_customer(customer)
+def customers_create(customer: Client) -> Client:
+    create_customer(customer)
+    return customer

33-37: Mirror return value on user-aware create.

Helps fluent usage and symmetry with customers_create.

-def customers_create_with_user(user, customer: Client):
+def customers_create_with_user(user, customer: Client) -> Client:
     create_customer(customer)
     track_activity(f'Added customer {customer.name}', ctx_less=True)
     add_user_to_customer(user.id, customer.client_id)
+    return customer
source/app/iris_engine/access_control/utils.py (1)

365-365: Clarify the distinction between local and imported set_user_case_access functions.

A function named set_user_case_access exists both locally (line 388) and in app.business.access_controls (per relevant code snippets). The local version sets UserCaseAccess without setting effective access, while the imported version (if used elsewhere) calls set_case_effective_access_for_user. This naming collision can cause confusion and potential bugs if the wrong function is called.

Consider renaming the local function to make its scope clear, e.g., _set_creator_case_access or _create_user_case_access_record.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b68b34c and df5de76.

📒 Files selected for processing (36)
  • .github/workflows/ci.yml (4 hunks)
  • pyproject.toml (2 hunks)
  • source/app/blueprints/graphql/cases.py (1 hunks)
  • source/app/blueprints/pages/manage/manage_cases_routes.py (3 hunks)
  • source/app/blueprints/pages/manage/manage_customers_routes.py (2 hunks)
  • source/app/blueprints/rest/alerts_routes.py (2 hunks)
  • source/app/blueprints/rest/case/case_ioc_routes.py (2 hunks)
  • source/app/blueprints/rest/manage/manage_case_state.py (1 hunks)
  • source/app/blueprints/rest/manage/manage_cases_routes.py (1 hunks)
  • source/app/blueprints/rest/manage/manage_customers_routes.py (5 hunks)
  • source/app/blueprints/rest/v2/alerts.py (2 hunks)
  • source/app/blueprints/rest/v2/case_routes/events.py (3 hunks)
  • source/app/blueprints/rest/v2/cases.py (1 hunks)
  • source/app/blueprints/rest/v2/dashboard.py (3 hunks)
  • source/app/blueprints/rest/v2/manage_routes/customers.py (3 hunks)
  • source/app/blueprints/rest/v2/manage_routes/groups.py (2 hunks)
  • source/app/blueprints/rest/v2/manage_routes/users.py (0 hunks)
  • source/app/business/access_controls.py (2 hunks)
  • source/app/business/cases.py (4 hunks)
  • source/app/business/customers.py (1 hunks)
  • source/app/business/events.py (1 hunks)
  • source/app/datamgmt/case/case_db.py (1 hunks)
  • source/app/datamgmt/case/case_iocs_db.py (2 hunks)
  • source/app/datamgmt/client/client_db.py (5 hunks)
  • source/app/datamgmt/manage/manage_access_control_db.py (1 hunks)
  • source/app/datamgmt/manage/manage_case_state_db.py (1 hunks)
  • source/app/datamgmt/manage/manage_groups_db.py (1 hunks)
  • source/app/datamgmt/manage/manage_users_db.py (1 hunks)
  • source/app/iris_engine/access_control/utils.py (3 hunks)
  • source/app/models/authorization.py (1 hunks)
  • source/app/models/models.py (1 hunks)
  • source/app/post_init.py (7 hunks)
  • source/app/schema/marshables.py (2 hunks)
  • tests/README.md (1 hunks)
  • tests/tests_rest_comments.py (1 hunks)
  • tests/tests_rest_customers.py (2 hunks)
💤 Files with no reviewable changes (1)
  • source/app/blueprints/rest/v2/manage_routes/users.py
🧰 Additional context used
🧬 Code graph analysis (29)
source/app/blueprints/pages/manage/manage_customers_routes.py (1)
source/app/datamgmt/client/client_db.py (1)
  • get_customer (63-64)
source/app/datamgmt/case/case_db.py (2)
source/app/models/models.py (2)
  • ReviewStatus (815-819)
  • Client (120-132)
source/app/models/cases.py (1)
  • Cases (50-160)
source/app/blueprints/rest/manage/manage_case_state.py (2)
source/app/datamgmt/manage/manage_case_state_db.py (1)
  • get_case_states_list (22-28)
source/app/schema/marshables.py (1)
  • CaseStateSchema (1699-1714)
source/app/blueprints/rest/v2/manage_routes/customers.py (3)
source/app/blueprints/rest/endpoints.py (2)
  • response_api_success (29-30)
  • response_api_not_found (72-73)
source/app/business/errors.py (1)
  • ObjectNotFoundError (35-38)
source/app/business/customers.py (2)
  • customers_create_with_user (33-36)
  • customers_get (39-43)
source/app/blueprints/rest/v2/cases.py (1)
source/app/business/cases.py (1)
  • cases_create (110-141)
source/app/blueprints/rest/manage/manage_customers_routes.py (3)
source/app/blueprints/rest/v2/manage_routes/customers.py (1)
  • create_customer (67-68)
source/app/datamgmt/client/client_db.py (2)
  • create_customer (103-105)
  • get_customer (63-64)
source/app/blueprints/rest/endpoints.py (1)
  • endpoint_deprecated (76-86)
source/app/blueprints/rest/alerts_routes.py (1)
source/app/iris_engine/access_control/utils.py (1)
  • ac_set_new_case_access (350-373)
source/app/blueprints/rest/case/case_ioc_routes.py (2)
source/app/iris_engine/access_control/utils.py (1)
  • ac_get_fast_user_cases_access (532-540)
source/app/datamgmt/case/case_iocs_db.py (1)
  • get_ioc_links (120-142)
source/app/datamgmt/client/client_db.py (2)
source/app/models/models.py (1)
  • Client (120-132)
source/app/blueprints/rest/v2/manage_routes/customers.py (1)
  • create_customer (67-68)
source/app/blueprints/graphql/cases.py (1)
source/app/business/cases.py (1)
  • cases_create (110-141)
source/app/datamgmt/manage/manage_users_db.py (1)
source/app/models/authorization.py (2)
  • CaseAccessLevel (38-45)
  • ac_access_level_mask_from_val_list (262-270)
source/app/blueprints/rest/v2/manage_routes/groups.py (5)
source/app/blueprints/rest/v2/manage_routes/customers.py (1)
  • read (51-57)
source/app/blueprints/rest/v2/manage_routes/users.py (1)
  • read (56-62)
source/app/datamgmt/manage/manage_groups_db.py (1)
  • get_group (84-87)
source/app/blueprints/access_controls.py (1)
  • wrap_with_permission_checks (344-376)
source/app/models/authorization.py (1)
  • Permissions (48-65)
source/app/blueprints/rest/v2/dashboard.py (1)
source/app/business/cases.py (2)
  • cases_filter_by_user (83-84)
  • cases_filter_by_reviewer (87-88)
source/app/blueprints/rest/v2/alerts.py (3)
source/app/blueprints/rest/v2/manage_routes/groups.py (1)
  • read (57-63)
source/app/blueprints/rest/v2/cases.py (1)
  • read (115-124)
source/app/blueprints/rest/v2/alerts_routes/comments.py (1)
  • read (69-78)
source/app/blueprints/pages/manage/manage_cases_routes.py (1)
source/app/schema/marshables.py (1)
  • CaseStateSchema (1699-1714)
source/app/business/access_controls.py (1)
source/app/datamgmt/manage/manage_access_control_db.py (1)
  • add_user_case_effective_access (196-204)
source/app/schema/marshables.py (2)
source/app/iris_engine/access_control/utils.py (1)
  • ac_get_fast_user_cases_access (532-540)
source/app/datamgmt/case/case_iocs_db.py (1)
  • get_ioc_links (120-142)
source/app/post_init.py (6)
source/app/datamgmt/manage/manage_access_control_db.py (1)
  • add_several_user_effective_access (207-226)
source/app/models/models.py (2)
  • Client (120-132)
  • get_or_create (109-117)
source/app/business/customers.py (2)
  • customers_get_by_name (46-50)
  • customers_create (29-30)
source/app/business/cases.py (1)
  • cases_get_first_with_customer (102-103)
source/app/business/errors.py (1)
  • ObjectNotFoundError (35-38)
source/app/datamgmt/manage/manage_groups_db.py (1)
  • add_case_access_to_group (226-254)
source/app/datamgmt/manage/manage_groups_db.py (2)
source/app/iris_engine/access_control/utils.py (1)
  • ac_ldp_group_removal (169-182)
source/app/models/authorization.py (2)
  • Group (100-112)
  • ac_access_level_mask_from_val_list (262-270)
source/app/business/cases.py (5)
source/app/datamgmt/case/case_db.py (1)
  • get_first_case_with_customer (43-47)
source/app/models/cases.py (1)
  • Cases (50-160)
source/app/models/models.py (1)
  • Client (120-132)
source/app/datamgmt/dashboard/dashboard_db.py (2)
  • list_user_cases (174-183)
  • list_user_reviews (85-99)
source/app/iris_engine/access_control/utils.py (1)
  • ac_set_new_case_access (350-373)
source/app/datamgmt/manage/manage_access_control_db.py (1)
source/app/models/authorization.py (1)
  • UserCaseEffectiveAccess (143-154)
source/app/datamgmt/case/case_iocs_db.py (2)
source/app/models/comments.py (2)
  • Comments (33-48)
  • IocComments (73-81)
source/app/models/cases.py (1)
  • Cases (50-160)
source/app/blueprints/rest/v2/case_routes/events.py (5)
source/app/blueprints/access_controls.py (2)
  • ac_api_requires (379-383)
  • ac_fast_check_current_user_has_case_access (583-584)
source/app/blueprints/rest/v2/manage_routes/customers.py (1)
  • read (51-57)
source/app/blueprints/rest/v2/cases.py (1)
  • read (115-124)
source/app/blueprints/rest/v2/case_routes/evidences.py (1)
  • read (96-111)
source/app/blueprints/rest/v2/events_routes/comments.py (1)
  • read (81-90)
tests/tests_rest_customers.py (2)
source/app/blueprints/rest/v2/manage_routes/customers.py (1)
  • create (41-49)
tests/iris.py (3)
  • create (60-61)
  • get (63-64)
  • create_dummy_user (85-91)
source/app/datamgmt/manage/manage_case_state_db.py (1)
source/app/models/cases.py (1)
  • CaseState (211-219)
source/app/business/events.py (1)
source/app/datamgmt/states.py (1)
  • update_timeline_state (86-87)
source/app/iris_engine/access_control/utils.py (3)
source/app/datamgmt/manage/manage_access_control_db.py (1)
  • add_several_user_effective_access (207-226)
source/app/models/authorization.py (4)
  • User (199-255)
  • CaseAccessLevel (38-45)
  • UserClient (184-196)
  • UserCaseAccess (129-140)
source/app/business/access_controls.py (1)
  • set_user_case_access (32-56)
source/app/business/customers.py (6)
source/app/blueprints/rest/v2/manage_routes/customers.py (1)
  • create_customer (67-68)
source/app/datamgmt/client/client_db.py (3)
  • create_customer (103-105)
  • get_customer (63-64)
  • get_customer_by_name (217-218)
source/app/models/models.py (1)
  • Client (120-132)
source/app/iris_engine/utils/tracker.py (1)
  • track_activity (30-66)
source/app/datamgmt/manage/manage_users_db.py (1)
  • add_user_to_customer (138-155)
source/app/business/errors.py (1)
  • ObjectNotFoundError (35-38)
source/app/blueprints/rest/manage/manage_cases_routes.py (1)
source/app/business/cases.py (1)
  • cases_create (110-141)
🪛 LanguageTool
tests/README.md

[grammar] ~32-~32: Ensure spelling is correct
Context: ...d_return_201 ``` Tip: this is a way to spped up the develop/run test loop. To restar...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

🪛 markdownlint-cli2 (0.18.1)
tests/README.md

17-17: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


23-23: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


28-28: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


33-33: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


38-38: Fenced code blocks should have a language specified

(MD040, fenced-code-language)


43-43: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
  • GitHub Check: Database migration tests
  • GitHub Check: Test API
  • GitHub Check: Generate graphQL documentation
  • GitHub Check: End to end tests
🔇 Additional comments (49)
source/app/datamgmt/manage/manage_groups_db.py (1)

23-23: LGTM! Import refactoring centralizes access control utilities.

The relocation of ac_access_level_mask_from_val_list from app.iris_engine.access_control.utils to app.models.authorization consolidates access control utilities in a single module, improving code organization.

Also applies to: 28-28

source/app/datamgmt/manage/manage_users_db.py (1)

40-40: LGTM! Consistent import refactoring.

The import path update aligns with the centralization of access control utilities in app.models.authorization, matching the pattern applied in other modules.

source/app/blueprints/rest/v2/manage_routes/groups.py (2)

57-57: LGTM! Method rename aligns with API consistency.

The rename from get to read is consistent with the same pattern applied in customers and users modules, improving API naming consistency across the v2 REST endpoints.


102-102: LGTM! Route handler correctly updated.

The route registration properly references the renamed read method.

source/app/blueprints/rest/v2/alerts.py (2)

160-160: LGTM! Method rename aligns with v2 API patterns.

The rename from get to read is consistent with the broader refactoring across v2 REST endpoints.


258-258: LGTM! Route handler correctly updated.

The route registration properly references the renamed read method.

source/app/datamgmt/manage/manage_access_control_db.py (1)

207-226: LGTM! Batch access assignment is well-implemented.

The function correctly handles batch deletion and creation of effective access records. The approach of deleting existing records before adding new ones ensures a clean state.

.github/workflows/ci.yml (4)

134-135: LGTM! Environment setup simplified.

The change from using --env-file to copying .env.tests.model to .env standardizes the environment initialization pattern and simplifies Docker Compose invocations.


171-172: LGTM! Consistent environment setup.

The pattern is consistently applied across all CI jobs.


225-225: LGTM! Consistent environment setup.

The pattern is consistently applied across all CI jobs.


275-276: LGTM! Consistent environment setup.

The pattern is consistently applied across all CI jobs.

tests/tests_rest_comments.py (1)

540-540: LGTM! More descriptive test name.

The rename clarifies the test precondition by explicitly stating "when there is a comment," improving test documentation.

pyproject.toml (2)

27-27: LGTM! Expanded architectural boundary enforcement.

Adding app.business.cases to the contract ensures the cases business module doesn't leak API-layer dependencies.


45-57: LGTM! Strengthened layer separation.

The new contracts enforce proper architectural boundaries by preventing:

  • Persistence layer from importing marshables (reducing coupling)
  • Persistence layer from importing engine components (maintaining clear responsibilities)
source/app/datamgmt/client/client_db.py (5)

23-23: LGTM! Type hint improvement.

Adding Optional import enables more precise type annotations for nullable return values.


63-64: LGTM! Consistent terminology and improved type safety.

The rename from get_client to get_customer aligns with the broader terminology shift in the PR, and the Optional[Client] return type properly documents that the function may return None.


103-103: LGTM! Consistent rename.

The function rename aligns with the terminology shift from "client" to "customer."


168-168: LGTM! Internal reference updated.

The call to get_customer correctly uses the renamed function.


217-218: LGTM! Useful name-based lookup.

The new get_customer_by_name function provides convenient name-based retrieval to complement ID-based lookup.

source/app/blueprints/rest/v2/case_routes/events.py (1)

86-102: LGTM - Consistent REST method naming.

The rename from get to read aligns with the REST API consistency improvements seen across the codebase. The logic remains unchanged, and all access control checks are properly preserved.

source/app/blueprints/rest/case/case_ioc_routes.py (1)

79-80: LGTM - Proper user-scoped access control for IoC links.

The addition of explicit user search limitations correctly implements per-user access filtering for IoC links. This ensures users only see links to cases they have access to, improving security and data isolation.

source/app/schema/marshables.py (1)

944-947: LGTM - Consistent user-scoped IoC link filtering.

The schema's get_link method now properly filters IoC links based on the current user's case access, ensuring data isolation at the serialization layer. This aligns with the access control improvements throughout the PR.

source/app/datamgmt/case/case_iocs_db.py (1)

120-142: LGTM - Secure fail-closed access control.

The new user_search_limitations parameter implements proper access control filtering. The logic correctly defaults to an empty result set when no limitations are provided (line 124), following a secure fail-closed pattern. This ensures users cannot access IoC links for cases they don't have permission to view.

source/app/business/cases.py (4)

83-84: LGTM - Explicit user context threading.

The addition of the user parameter makes the function's dependency on user context explicit, improving testability and clarity. This change aligns with the broader refactoring pattern across the PR.


87-88: LGTM - Explicit user context threading.

The addition of the user parameter makes the function's dependency on user context explicit, improving testability and clarity.


102-104: LGTM - Clear helper function for customer-based case retrieval.

The new cases_get_first_with_customer function provides a clean business-layer interface for retrieving the first case associated with a customer, properly delegating to the data layer.


110-133: LGTM - Explicit user ownership assignment.

The cases_create function now accepts an explicit user parameter and sets case.owner_id = user.id, making case ownership clear and removing implicit dependencies on global context. The user is also properly threaded through to ac_set_new_case_access.

source/app/blueprints/graphql/cases.py (1)

118-118: LGTM!

The update correctly passes iris_current_user to cases_create, aligning with the updated business logic signature that now requires explicit user context.

source/app/blueprints/rest/alerts_routes.py (1)

609-609: LGTM!

Both escalation flows now correctly pass iris_current_user to ac_set_new_case_access, ensuring proper user-case association during case creation from alerts.

Also applies to: 887-887

tests/tests_rest_customers.py (2)

24-24: Good practice using a sentinel constant.

Using _IDENTIFIER_FOR_NONEXISTENT_OBJECT improves test maintainability.


78-87: LGTM!

The tests properly verify the GET customer endpoint for both existing and non-existent customers.

source/app/blueprints/rest/v2/cases.py (1)

107-107: LGTM!

The change correctly passes iris_current_user to cases_create, consistent with the explicit user context pattern throughout this PR.

source/app/blueprints/rest/v2/dashboard.py (2)

23-23: LGTM!

Import added to support explicit user context in filtering operations.


43-43: LGTM!

Both filtering functions now correctly receive explicit user context, aligning with the updated business logic signatures.

Also applies to: 62-62

source/app/blueprints/rest/manage/manage_case_state.py (1)

48-49: LGTM!

The change correctly introduces serialization of case states using CaseStateSchema, ensuring consistent data format in API responses.

source/app/blueprints/pages/manage/manage_cases_routes.py (2)

44-44: LGTM!

Import added to support case state serialization.


85-85: LGTM!

Case states are now properly serialized before being passed to the template, ensuring consistent data format.

Also applies to: 97-97

source/app/blueprints/pages/manage/manage_customers_routes.py (1)

25-25: LGTM!

The changes correctly update from get_client to get_customer, aligning with the terminology standardization across the codebase.

Also applies to: 118-118

source/app/blueprints/rest/manage/manage_customers_routes.py (1)

28-28: Import rename alignment looks good.

Swapping to create_customer/get_customer matches the DAL rename; call sites in this file remain consistent.

Also applies to: 32-32

source/app/blueprints/rest/v2/manage_routes/customers.py (3)

25-26: Response helpers wired correctly.

Using response_api_success/response_api_not_found matches v2 conventions.


45-46: Create path uses user-aware helper.

customers_create_with_user(iris_current_user, …) is the right abstraction.


51-58: Read flow and 404 mapping look correct.

ObjectNotFoundError → response_api_not_found maintains clean domain-to-HTTP mapping.

source/app/blueprints/rest/manage/manage_cases_routes.py (1)

254-255: Signature update aligns with business layer.

Passing iris_current_user into cases_create is correct.

source/app/business/customers.py (2)

39-44: LGTM on not-found semantics.

customers_get raising ObjectNotFoundError is appropriate for v2 mapping.


46-50: LGTM on get-by-name behavior.

Consistent with customers_get; good.

source/app/post_init.py (1)

713-719: Initial customer bootstrap looks fine.

Try/get-by-name then create avoids duplicate entries; simple and safe.

source/app/iris_engine/access_control/utils.py (3)

324-324: LGTM! Good refactoring to centralize bulk access assignment.

Delegating to add_several_user_effective_access reduces code duplication and improves maintainability.


376-384: LGTM! Simple and correct query helper.

The function correctly retrieves user access levels for a given customer. The TODO comment appropriately notes the planned refactoring to move this to the data management layer.


387-400: LGTM! Good refactoring to use explicit user parameter.

Accepting an explicit user parameter instead of relying on iris_current_user improves testability and makes the function's dependencies clearer. The implementation correctly sets the UserCaseAccess record, with the caller responsible for setting effective access separately.

whikernel and others added 2 commits January 11, 2026 17:18
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
@whikernel whikernel merged commit 823c86e into develop Jan 11, 2026
12 of 17 checks passed
@whikernel whikernel deleted the api_v2_get_customer branch January 11, 2026 16:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

API v2 get customer

3 participants

Comments