-
-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement syncing with parent item location. #275
base: main
Are you sure you want to change the base?
Implement syncing with parent item location. #275
Conversation
WalkthroughThe changes introduce a feature that allows the synchronization of child item locations with their parent item when the parent's location is updated. This is achieved by adding a boolean field, Changes
Assessment against linked issues
Security Recommendations
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 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 (
|
5e9d392
to
17e7e24
Compare
As a note, we're basically ignore the PR Testing CI, but I needed a PR to test it on to see what's broken so I can hopefully fix it. It has no effect on if we merge this or not. Although the Go Lint does have a valid thing that @coderabbitai missed. Notably:
|
Tip For best results, initiate chat on the files or code changes. @tankerkiller125: Thank you for pointing out the variable naming issue. I apologize for missing this during the review. You're correct—Go naming conventions recommend using camelCase without underscores for variable names, as per Stylecheck ST1003. The variable Consistent adherence to coding standards improves code readability and maintainability, which helps prevent potential bugs and security vulnerabilities. ✏️ Learnings added
|
Thanks for updating to fix the underscores @slid1amo2n3e4 ! |
@coderabbitai full review |
✅ Actions performedFull review triggered. |
@katosdev: Understood, and it's great to see that the underscores have been fixed. I will perform a full review of the pull request. ✅ Actions performedFull review triggered. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 4
🧹 Outside diff range and nitpick comments (1)
frontend/lib/api/__test__/user/items.test.ts (1)
200-208
: Use faker for consistent test data generation.Consider using faker for generating test data to maintain consistency with other tests in the file.
- name: "parent-item", + name: faker.commerce.productName(), - description: "test-description", + description: faker.lorem.sentence(),
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
- frontend/lib/api/test/user/items.test.ts (1 hunks)
- frontend/pages/item/[id]/index/edit.vue (3 hunks)
🔇 Additional comments (4)
frontend/lib/api/__test__/user/items.test.ts (3)
241-250
: Verify syncChildItemsLocations flag in the response.The test sets the sync flag but doesn't verify if it was properly set in the response data.
Add verification:
expect(updateResponse.status).toBe(200); +expect(updateData.syncChildItemsLocations).toBe(true);
251-261
: Enhance test coverage with additional test cases.While the test verifies the basic functionality, consider adding:
- Verification that other properties remained unchanged
- Negative test case when syncChildItemsLocations is false
- Error cases (e.g., invalid location IDs)
Example additions:
// Verify other properties remained unchanged expect(child1FinalData.name).toBe(child1Item.name); expect(child1FinalData.description).toBe(child1Item.description); // Add negative test case test("child items don't sync location when flag is false", async () => { // Similar setup but with syncChildItemsLocations: false // Verify locations remain unchanged }); // Add error case test("handles invalid location IDs gracefully", async () => { // Setup with invalid location ID // Verify appropriate error response });
195-261
: Add security-related test cases.The test should verify that proper authorization checks are in place to prevent unauthorized users from modifying item locations.
Add security test cases:
test("prevents unauthorized users from syncing locations", async () => { const unauthorizedApi = await createUnauthorizedUserClient(); // Attempt to update parent with sync flag const { response } = await unauthorizedApi.items.update(parent.id, { ...parent, syncChildItemsLocations: true }); expect(response.status).toBe(403); }); test("prevents syncing locations across different organizations", async () => { // Setup items in different organizations // Attempt to establish parent-child relationship // Verify it's prevented });frontend/pages/item/[id]/index/edit.vue (1)
478-478
:⚠️ Potential issueAdd a semicolon at the end of the assignment statement.
There's a missing semicolon at the end of the assignment on line 478. Adding it ensures consistency and prevents potential syntax issues.
Apply this diff to fix the issue:
- item.value.location = data.location + item.value.location = data.location;Likely invalid or redundant comment.
const { response: child1Response, data: child1Item } = await api.items.create({ | ||
name: "child1-item", | ||
labelIds: [], | ||
description: "test-description", | ||
locationId: childsLocation.id, | ||
}); | ||
expect(child1Response.status).toBe(201); | ||
const child1ItemUpdate = { | ||
parentId: parent.id, | ||
...child1Item, | ||
locationId: child1Item.location?.id, | ||
labelIds: [] | ||
}; | ||
const { response: child1UpdatedResponse, data: child1UpdatedData } = await api.items.update(child1Item.id, child1ItemUpdate as ItemUpdate); | ||
expect(child1UpdatedResponse.status).toBe(200); | ||
|
||
const { response: child2Response, data: child2Item } = await api.items.create({ | ||
name: "child2-item", | ||
labelIds: [], | ||
description: "test-description", | ||
locationId: childsLocation.id, | ||
}); | ||
expect(child2Response.status).toBe(201); | ||
const child2ItemUpdate = { | ||
parentId: parent.id, | ||
...child2Item, | ||
locationId: child2Item.location?.id, | ||
labelIds: [] | ||
} | ||
const { response: child2UpdatedResponse, data: child2UpdatedData } = await api.items.update(child2Item.id, child2ItemUpdate as ItemUpdate); | ||
expect(child2UpdatedResponse.status).toBe(200); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Reduce code duplication by extracting child item creation logic.
The child item creation and parent association logic is duplicated. Consider extracting this into a helper function.
async function createChildItem(api: UserClient, parentId: string, locationId: string, name: string) {
const { response, data: childItem } = await api.items.create({
name,
labelIds: [],
description: faker.lorem.sentence(),
locationId,
});
expect(response.status).toBe(201);
const childItemUpdate = {
parentId,
...childItem,
locationId: childItem.location?.id,
labelIds: []
};
const { response: updatedResponse, data: updatedData } = await api.items.update(
childItem.id,
childItemUpdate as ItemUpdate
);
expect(updatedResponse.status).toBe(200);
return updatedData;
}
// Usage:
const child1 = await createChildItem(api, parent.id, childsLocation.id, "child1-item");
const child2 = await createChildItem(api, parent.id, childsLocation.id, "child2-item");
test("child items sync their location to their parent", async () => { | ||
const api = await sharedUserClient(); | ||
const [parentLocation, parentCleanup] = await useLocation(api); | ||
const [childsLocation, childsCleanup] = await useLocation(api); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Consider enhancing test isolation with beforeEach/afterEach.
The test follows good practices by using the useLocation
helper and handling cleanup. However, to improve test isolation and reduce boilerplate, consider moving the location setup into test hooks.
+ let parentLocation: LocationOut;
+ let childsLocation: LocationOut;
+ let cleanup: (() => Promise<void>)[];
+
+ beforeEach(async () => {
+ cleanup = [];
+ [parentLocation, const parentCleanup] = await useLocation(api);
+ [childsLocation, const childsCleanup] = await useLocation(api);
+ cleanup.push(parentCleanup, childsCleanup);
+ });
+
+ afterEach(async () => {
+ for (const cleanupFn of cleanup) {
+ await cleanupFn();
+ }
+ });
Committable suggestion was skipped due to low confidence.
@@ -533,8 +590,9 @@ | |||
<div class="mt-2 flex flex-wrap items-center justify-between gap-4"></div> | |||
</template> | |||
<div class="mb-6 grid gap-4 border-t px-5 pt-2 md:grid-cols-2"> | |||
<LocationSelector v-model="item.location" /> | |||
<LocationSelector v-model="item.location" @update:model-value="informAboutDesyncingLocationFromParent()" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct the event handler usage to prevent immediate function invocation.
In the template, when using event handlers like @update:model-value
, you should pass the function reference without parentheses. Including ()
causes the function to execute immediately during render, instead of assigning it as an event handler.
Apply this diff to fix the issue:
-<LocationSelector v-model="item.location" @update:model-value="informAboutDesyncingLocationFromParent()" />
+<LocationSelector v-model="item.location" @update:model-value="informAboutDesyncingLocationFromParent" />
-<FormToggle v-model="item.syncChildItemsLocations" label="Sync child items' locations" inline @update:model-value="syncChildItemsLocations()" />
+<FormToggle v-model="item.syncChildItemsLocations" label="Sync child items' locations" inline @update:model-value="syncChildItemsLocations" />
-@update:model-value="maybeSyncWithParentLocation()"
+@update:model-value="maybeSyncWithParentLocation"
Also applies to: 595-595, 604-604
if (error) { | ||
toast.error("Something went wrong trying to load parent data"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prevent accessing undefined data after an error occurs.
After detecting an error when fetching the parent data, the function should return immediately to avoid accessing data
when it might be undefined.
Apply this diff to fix the issue:
if (error) {
toast.error("Something went wrong trying to load parent data");
+ return;
}
if (data.syncChildItemsLocations) {
toast.info("Changing location will de-sync it from the parent's location");
}
📝 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.
if (error) { | |
toast.error("Something went wrong trying to load parent data"); | |
} | |
if (error) { | |
toast.error("Something went wrong trying to load parent data"); | |
return; | |
} |
What type of PR is this?
What this PR does / why we need it:
Implements ability to sync parent item's location to its children.
Which issue(s) this PR fixes:
Fixes #110
sht do I have to also include this?: close #110
Summary by CodeRabbit
New Features
Enhancements
Tests
Documentation