Shareable Collections#120
Conversation
… the left sidebar to display weither a collection is shared or not, if the logged in user is the owner of collection and if a user is invited, to display access to said collection
…ng access Viewer in a shared Collection fix: Fixing viewing shared drawings as an Owner of a shared collection
ZimengXiong
added
enhancement
ZimengXiong
requested review from
ZimengXiong and
Copilot
and removed request for
Copilot
|
The feature is still wanted, but this branch is too large and too far behind If you still want to keep working on it, I’d want a narrower follow-up focused on the core collection-sharing backend/foundation first, and then the frontend/UX in separate PRs. If not, that’s fine too (let me know) and I can pick it up from here. Thanks! |
Could you confirm the expected integration requirement for this feature split: Should the backend collection-sharing foundation be fully safe to merge and run independently (with no frontend changes) without introducing regressions, or do you require backend and frontend portions to ship together for correctness? My plan is to submit backend first and frontend as a follow-up PR, so I want to align with your expectation on whether backend-only mergeability is a hard requirement. |
|
Feature should work once both are merged (as it reasonably destructively changes endpoints). Splitting mainly to decrease review scope. Please include/update tests so that each passes, thanks!
… On Apr 17, 2026, at 07:06:20, Ismail Mohamed Mostafa ***@***.***> wrote:
INagaty
left a comment
(ZimengXiong/ExcaliDash#120)
<#120?email_source=notifications&email_token=AT7G33EGRTU33LZF3V73GNT4WI25ZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRWHA3TENZWGI3KM4TFMFZW63VGMFZXG2LHN2SWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4268727626>
The feature is still wanted, but this branch is too large and too far behind main to want a straight rebase. It touches schema, authz, API behavior, and dashboard UX all at once.
If you still want to keep working on it, I’d want a narrower follow-up focused on the core collection-sharing backend/foundation first, and then the frontend/UX in separate PRs.
If not, that’s fine too (let me know) and I can pick it up from here. Thanks!
Could you confirm the expected integration requirement for this feature split:
Should the backend collection-sharing foundation be fully safe to merge and run independently (with no frontend changes) without introducing regressions, or do you require backend and frontend portions to ship together for correctness?
My plan is to submit backend first and frontend as a follow-up PR, so I want to align with your expectation on whether backend-only mergeability is a hard requirement.
—
Reply to this email directly, view it on GitHub <#120?email_source=notifications&email_token=AT7G33EGRTU33LZF3V73GNT4WI25ZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRWHA3TENZWGI3KM4TFMFZW63VGMFZXG2LHN2SWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4268727626>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AT7G33F2PM4TOVMXIXZCZGD4WI25ZAVCNFSM6AAAAACXILX3F2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DENRYG4ZDONRSGY>.
You are receiving this because you were assigned.
|
Separate branches have been created, only tests are remaining. Keep an eye out for the PRs in the next upcoming days |
Both PRs for backend and frontend changes have been made a week ago, please review and merge as soon as possible to ensure no conflicts are there. |
2 participants
This pull request introduces a new system for sharing collections between users, enabling more granular access control and collaboration. The changes span database schema updates, backend logic, and API route enhancements to support collection sharing, role-based access, and improved collection listing.
Key changes:
Database & Schema Updates
Collection Sharing Table Added:
Introduced a new
CollectionSharetable to track which users collections are shared with, their roles (e.g., "view"), and relevant metadata. Includes unique and foreign key constraints for data integrity. (backend/prisma/migrations/20260326143103_add_collection_sharing/migration.sql,backend/prisma/schema.prisma) [1] [2] [3] [4]Schema Cleanups:
Removed inline comments from permission fields and other string fields to standardize schema formatting. (
backend/prisma/schema.prisma) [1] [2] [3] [4]Backend Logic Enhancements
Collection-Level Access Control:
Updated the drawing access logic to check for collection-level sharing if no direct drawing permission exists. Users can now gain access to drawings via shared collections, not just individual drawing permissions. (
backend/src/authz/sharing.ts)Utility & Formatting Improvements:
Refactored several utility functions for clarity and consistency, including formatting, parameter naming, and legacy hash handling. (
backend/src/authz/sharing.ts) [1] [2] [3] [4] [5]API & Route Changes
Enhanced
/collectionsEndpoint:The GET
/collectionsendpoint now returns both collections owned by the user and those shared with them, including metadata such as ownership, sharing role, and whether the collection is shared. (backend/src/routes/dashboard/collections.ts) [1] [2]Consistent Owner-Only Enforcement:
The POST, PUT, and DELETE endpoints for collections are updated to ensure only owners can modify or delete collections, and responses include sharing metadata. Deleting a collection also removes all its share entries. (
backend/src/routes/dashboard/collections.ts) [1] [2] [3] [4]These changes lay the groundwork for robust collection sharing and access management, making it easier for users to collaborate while maintaining secure and clear ownership boundaries.