`PATCH /editor/project/visibility` returns 200 with `null` and doesn't update when `projectId` is a slug
Maintainer thường phản hồi trong vòng 3 ngày
@Prbhtsgh đang làm issue này rồi.
Từ ngày 8/10/2026.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 78/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- javascript, mongodb, node.js
Hướng nghiên cứu
Bắt đầu tại server/controllers/project.controller.js, trong changeProjectVisibility quanh dòng 446–487, và so sánh việc tìm kiếm dự án với lệnh gọi cập nhật. Báo cáo có một cách tái hiện sử dụng slug và _id; hãy kiểm tra cả hai với endpoint. Công việc được xem là hoàn tất khi slug cập nhật dự án thuộc sở hữu của người dùng như mong đợi, hoặc bị từ chối bằng phản hồi 4xx thay vì trả về 200 với null.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
p5.js version
No response
What is your operating system?
Mac OS
Web browser and version
Google Chrome 153.0.8010.53 (Official Build) (arm64)
Actual Behavior
PATCH /editor/project/visibility looks up the project by either _id or slug, but then updates it by _id only. When a slug is sent as projectId, the ownership check passes, but the update matches no document. The visibility is not changed, and the server still responds 200 OK with null as the body.
In changeProjectVisibility (server/controllers/project.controller.js):
- The lookup uses
Project.findOne({ $or: [{ _id: projectId }, { slug: projectId }] }), which finds the project by slug. - The ownership check runs on that project and passes.
- The update uses
Project.findByIdAndUpdate(projectId, ...). With a slug, this searches for_id === "<slug>", matches nothing and returnsnull. res.status(200).json(updatedProject)then sendsnullwith status 200.
The editor UI always sends the _id, so regular users don't hit this. It affects direct calls to the endpoint.
Checked related issues #3864 / #4291 / #3875 and PRs #3920 / #4305 / #3893. #3920 and #4305 change only client-side visibility state, and #3893 only restricts fields in updateProject. None of them change this lookup/update mismatch.
Expected Behavior
The update should apply to the same project that was found and ownership-checked, so sending a slug changes the visibility just like sending the _id. Alternatively, if slugs are not meant to be supported here, the endpoint should reject them with a 4xx error instead of responding 200 with null.
Steps to reproduce
Steps:
Reproduced on the latest develop branch, running locally with Docker.
- Log in, create a new sketch named
visibility test, and save it. Its slug isvisibility_test. You can confirm it in Mongo:
db.projects.find({ name: 'visibility test' }, { slug: 1, visibility: 1 })
In my case the visibility wasPrivate. - Toggle the sketch's visibility once from the toolbar, and copy the
PATCH /editor/project/visibilityrequest from DevTools (Network tab → Copy as cURL). - Resend it with the body
{"projectId":"visibility_test","visibility":"Public"}.- Response:
200 OKwith the bodynull - In Mongo, the visibility is still
Private(unchanged)
- Response:
- Resend it with the body
{"projectId":"<the sketch _id>","visibility":"Public"}.- Response:
200 OKwith the full project JSON - In Mongo, the visibility is now
Public
- Response:
The only difference between steps 3 and 4 is sending the slug instead of the _id.
Possible fix
Update the project that was already found and checked, instead of looking it up again by the raw projectId:
const updatedProject = await Project.findByIdAndUpdate(
project._id,
{ visibility: newVisibility },
{ new: true, runValidators: true }
)
I'd be happy to open a PR for this if the approach looks good.
- Ngôn ngữ chính
- JavaScript
- Star
- 1.7k
- Fork
- 1.7k
- Merge trung bình
- 3 ngày 18 giờ
- Pull request đã merge (30 ngày)
- 7
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của processing/p5.js-web-editor
-
Fix: example.js stores defaultHTML function reference instead of calling it, causing examples to display raw JavaScript source in previewCó thể đã có người làm @syedbarkath980 đã nhận 5 ngày trước. Đang mởAwaiting Maintainer Approval Bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
processing/p5.js-web-editor#4344 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 3 ngày
-
signup form gets stuck when signup request fails due to network errorCó thể đã có người làm @PS01K đã nhận 35 ngày trước. Đang mởAwaiting Maintainer Approval Bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
processing/p5.js-web-editor#4285 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 3 ngày
-
saveProject throws an error when a network request failsCó thể đã có người làm @dyk1454683243-sudo đã nhận 7 ngày trước. Đang mởBug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
processing/p5.js-web-editor#4276 · 3 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Awaiting Maintainer Approval Enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
processing/p5.js-web-editor#4270 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 3 ngày
-
"Add Sketch" option visible to guest users on other users collectionsCó thể đã có người làm @Riddh1ma đã nhận 123 ngày trước. Đang mởBug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
processing/p5.js-web-editor#4148 ·
Maintainer thường phản hồi trong vòng 3 ngày
Tất cả issue của processing/p5.js-web-editor
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
documentation good first issue help wanted
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 85/100
zmo2s/agent-toolbox#23 ·
-
[Bug]: [MCP/CLI] Bare loopback IP addresses (127.0.0.1:port) and hosts with ports fail to navigate due to erroneous scheme inferenceCó thể đã có người làm @alok-108 đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
microsoft/playwright#43263 ·
Maintainer thường phản hồi trong vòng 1 ngày