-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
fix(core): Return homeProject when filtering workflows by project id #12077
fix(core): Return homeProject when filtering workflows by project id #12077
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! |
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.
Confirmed working, thanks for fixing 🙏🏻
// Since we're filtering using project ID as part of the relation, | ||
// we end up filtering out all the other relations, meaning that if | ||
// it's shared to a project, it won't be able to find the home project. | ||
// To solve this, we have to get all the relation now, even though | ||
// we're deleting them later. | ||
if (typeof options?.filter?.projectId === 'string' && options.filter.projectId !== '') { | ||
const relations = await this.sharedWorkflowRepository.getAllRelationsForWorkflows( | ||
workflows.map((c) => c.id), | ||
); | ||
workflows.forEach((c) => { | ||
c.shared = relations.filter((r) => r.workflowId === c.id); | ||
}); | ||
} |
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.
The facts that we're having to do two queries for this, in-memory processing and fetching things that we later discard makes me wish we could use the query builder, but that'd be a larger refactor. Maybe to improve in future.
n8n Run #8242
Run Properties:
|
Project |
n8n
|
Branch Review |
master
|
Run status |
Passed #8242
|
Run duration | 04m 36s |
Commit |
efafeed334: 🌳 master 🖥️ browsers:node18.12.0-chrome107 🤖 PR User 🗃️ e2e/*
|
Committer | Danny Martini |
View all properties for this run ↗︎ |
Test results | |
---|---|
Failures |
0
|
Flaky |
1
|
Pending |
0
|
Skipped |
0
|
Passing |
480
|
View all changes introduced in this branch ↗︎ |
✅ All Cypress E2E specs passed |
Got released with |
Summary
When filtering workflows by project Id we'd not return the home project if the user was not the owner of the workflow. Without that the FE shows incorrect ownerships of WFs:
The reason for that is that that we're filtering the workflows based on
workflow.shared.projectId
which will also filter down theworkflow.shared
list to only contain the sharings matching that projectId:n8n/packages/cli/src/databases/repositories/workflow.repository.ts
Lines 102 to 105 in 146f489
Later we iterate of
workflow.shared
assuming it contains all sharings:n8n/packages/cli/src/services/ownership.service.ts
Lines 82 to 98 in 146f489
In raw SQL and with a query builder this can be fixed using sub=queries, but it's not possible to have this behavior with TypeORM's repository interface.
For credentials this was fixed 3 months ago: #10144
This PR implements the same fix for workflows.
Related Linear tickets, Github issues, and Community forum posts
This does not address what's in the description, but what this comment mentions:
https://linear.app/n8n/issue/PAY-2271/community-issue-credentials-in-project-personal-are-not-just-my#comment-9fe3bc10
Review / Merge checklist
Docs updated or follow-up ticket created.PR Labeled withrelease/backport
(if the PR is an urgent fix that needs to be backported)