Conversation
…n_alert_filter_is_not_found
…o customers_read permission
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. 🗂️ Base branches to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThis 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 Changes
Sequence DiagramssequenceDiagram
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
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
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
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
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. Comment |
There was a problem hiding this comment.
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 returnsCaseState.query.all(), which yields a list ofCaseStateORM 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 CaseStatesource/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_usersource/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 customersource/app/iris_engine/access_control/utils.py (1)
365-365: Clarify the distinction between local and importedset_user_case_accessfunctions.A function named
set_user_case_accessexists both locally (line 388) and inapp.business.access_controls(per relevant code snippets). The local version setsUserCaseAccesswithout setting effective access, while the imported version (if used elsewhere) callsset_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_accessor_create_user_case_access_record.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 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_listfromapp.iris_engine.access_control.utilstoapp.models.authorizationconsolidates 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
gettoreadis 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
readmethod.source/app/blueprints/rest/v2/alerts.py (2)
160-160: LGTM! Method rename aligns with v2 API patterns.The rename from
gettoreadis consistent with the broader refactoring across v2 REST endpoints.
258-258: LGTM! Route handler correctly updated.The route registration properly references the renamed
readmethod.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-fileto copying.env.tests.modelto.envstandardizes 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.casesto 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
Optionalimport enables more precise type annotations for nullable return values.
63-64: LGTM! Consistent terminology and improved type safety.The rename from
get_clienttoget_customeraligns with the broader terminology shift in the PR, and theOptional[Client]return type properly documents that the function may returnNone.
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_customercorrectly uses the renamed function.
217-218: LGTM! Useful name-based lookup.The new
get_customer_by_namefunction 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
gettoreadaligns 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_linkmethod 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_limitationsparameter 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
userparameter 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
userparameter 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_customerfunction 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_createfunction now accepts an explicituserparameter and setscase.owner_id = user.id, making case ownership clear and removing implicit dependencies on global context. The user is also properly threaded through toac_set_new_case_access.source/app/blueprints/graphql/cases.py (1)
118-118: LGTM!The update correctly passes
iris_current_usertocases_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_usertoac_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_OBJECTimproves 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_usertocases_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_clienttoget_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_accessreduces 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
userparameter instead of relying oniris_current_userimproves testability and makes the function's dependencies clearer. The implementation correctly sets theUserCaseAccessrecord, with the caller responsible for setting effective access separately.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Implementation of
GET /api/v2/manage/customers/{identifier}GET /manage/customers/<int:client_id>.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.The associated documentation is in PR#90 of iris-doc-src.
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Refactor
Documentation
Tests