-
Notifications
You must be signed in to change notification settings - Fork 0
Feat/visibility remastered #466
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
Conversation
…ay satisfies visibilitymatrix
…ility filter acording to memberships
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.
Pull Request Overview
This PR refactors the visibility system to use a new interface based on requirements and conditions, removing the old concept of visibility purposes and special visibility types. The changes eliminate the need for distinguishing between "regular" and "special" visibility, as all visibility operations now flow through specific implementations rather than direct CMS updates.
Key Changes:
- Replaced dual-level (regular/admin) visibility model with a single requirement-based model using conditions (ACTIVE/ORDER types)
- Removed visibility purposes and special visibility types, simplifying the authorization model
- Updated database schema to support the new visibility structure with requirement groups and omega order relationships
Reviewed Changes
Copilot reviewed 36 out of 36 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| src/services/visibility/operations.ts | New operations file implementing create, destroy, update, and read operations for the visibility system |
| src/services/visibility/implement.ts | Utility for implementing read and update operations with authorization |
| src/services/visibility/types.ts | Updated type definitions to use requirement-based visibility conditions |
| src/services/visibility/schemas.ts | New Zod schemas for validating visibility operations |
| src/auth/visibility/*.ts | New visibility helper functions for filtering, checking, and comparing visibility |
| src/prisma/schema/*.prisma | Database schema changes to support new visibility model |
| src/services/images/collections/*.ts | Updated image collection services to use new visibility operations |
| src/app/_components/VisiblityAdmin/*.tsx | Simplified visibility admin UI components |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
|
getUser will also be removed when useUser is |
Paulijuz
left a comment
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.
LGTM 👍
I will keep these PRs small. I will first open this one changing to the new visibility interface and removing references to the old system here and there. Now there is no need for visibilityPurpose or special visibility. This information can be gathered from the system using the visibility. Before it could not as the update method for the cms went right to the cms so knowing what bypass permission to use was hard, but now all these operations goes through a particular implementation.
First I will change useUser and useEditing to use Sessions and the author system (this is a little overdue now)
Then I will rework the image and image_collection services to be the first service using this. Some visibility utils still must be made... We need some semantics around filtering for readMany operations. These will notes an up front author but rather a filter. I think we might let an author return a filter field that can be obtained in the operation function. This might be a simple way to retain the author semantics for readMany operations...