refactor: Modularize Prisma schema into separate files#106
Conversation
Split the main Prisma schema into modular files for better organization: - Separated models into logical domains: employee, framework, policy, portal, risk, and vendor - Removed redundant vendor-related models from the main schema - Maintained existing relationships and model structures - Prepared for easier schema management and future extensions
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughA series of Prisma schema updates were applied. The Changes
Poem
✨ Finishing Touches
🪧 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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
packages/db/prisma/schema/portal.prisma (1)
32-49: PortalAccount Model: Security Consideration Required.
The model is well structured; however, please verify that thepasswordfield is used to store a hashed value rather than plaintext to avoid security vulnerabilities. If not already handled elsewhere, consider hashing passwords before storage.packages/db/prisma/schema/framework.prisma (3)
1-14: Framework Model Review
- The
Frameworkmodel is well-structured with a unique identifier and proper default generation viacuid().- The relationships to models such as
OrganizationCategory,OrganizationFramework,PolicyFramework, andOrganizationEvidenceare clearly established. Please ensure that these related models or enums (especiallyPolicyFramework) are defined elsewhere in your modularized schema.- Nitpick: The explicit index
@@index([id])on the primary key may be redundant because primary keys are automatically indexed in most databases.
111-128: ControlRequirement Model Review
- The model effectively captures the requirements associated with a control, including timestamps and relationships to evidence and policies.
- Nitpick: The field
namehas a default empty string. Consider whether an empty string is the desired default or if the field should be optional/required with proper validation.- The index on
[controlId]is beneficial.
167-176: Evidence Model Review
- The
Evidencemodel is concise and includes essential fields and automatic timestamps.- The relation to
ControlRequirementandOrganizationEvidenceis well-defined.- Suggestion: Consider adding an index on the
frequencyfield if you anticipate frequent queries filtering by this column.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
packages/db/prisma/schema.prisma(3 hunks)packages/db/prisma/schema/employee.prisma(1 hunks)packages/db/prisma/schema/framework.prisma(1 hunks)packages/db/prisma/schema/policy.prisma(1 hunks)packages/db/prisma/schema/portal.prisma(1 hunks)packages/db/prisma/schema/risk.prisma(1 hunks)packages/db/prisma/schema/vendor.prisma(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- packages/db/prisma/schema/vendor.prisma
🔇 Additional comments (34)
packages/db/prisma/schema/policy.prisma (6)
1-23: OrganizationPolicy Model: Solid structure and clear relationships.
The model is well defined with proper unique and index constraints. Please verify that the related modelOrganizationControlRequirementis defined elsewhere since it is referenced here.
25-43: Policy Model: Comprehensive and Consistent.
The model properly enforces uniqueness on theslugfield and establishes multiple relations (e.g., toControlRequirement,EmployeePolicyAcceptance, and others). Consider reviewing whether theusedByfield should be documented with its intended JSON structure (a single JSON value vs. an array) for maintainability.
45-54: PolicyFile Model: Clear and Correct.
The model correctly associates files with a policy using a cascading delete. Everything looks good.
56-64: PolicyFramework Model: Well Defined.
The unique constraint on the combination ofpolicyIdandframeworkIdis a best practice for many-to-many relationship tables.
66-80: PolicyComments Model: Appropriately Indexed and Related.
The model includes the needed relations and indexes for efficient querying. The explicit indexes onorganizationPolicyIdandorganizationIdshould aid performance.
82-90: PolicyControl Model: Concise and Functional.
The unique constraint on[policyId, controlId]enforces data integrity. No issues observed.packages/db/prisma/schema/portal.prisma (3)
1-16: PortalUser Model: Robust and Well-Linked.
The model includes all necessary relations (e.g., toEmployee,PortalAccount, andPortalSession). The optionalorganizationIdfield and its relation withOrganizationare clear.
18-30: PortalSession Model: Satisfactory Session Details.
All essential fields such as the unique token, expiration, and optional client data (IP and user agent) are present.
51-60: PortalVerification Model: Clean and Effective.
This model provides essential fields for verification processes and correctly maps to the underlying database table via@@map.packages/db/prisma/schema/employee.prisma (4)
1-9: EmployeeRequiredTask Model: Clear Definition.
The model properly defines a unique code and includes timestamps, facilitating task tracking and management.
11-24: EmployeeTask Model: Effective Relational Design.
The unique index on[employeeId, requiredTaskId]is appropriate. Field defaults and relation mappings are correct.
26-49: Employee Model: Well-Structured with Appropriate Constraints.
The inclusion of unique constraints on[email, organizationId]and indexes on key fields such asdepartmentanduserIdpromotes efficient querying. The relations toPortalUser,Organization,User, and risk/task assignments are clearly established.
51-63: EmployeePolicyAcceptance Model: Neat and Functional.
The model appropriately enforces uniqueness on the combination ofemployeeIdandpolicyIdand includes adequate timestamp tracking.packages/db/prisma/schema.prisma (4)
1-5: Prisma Client Generator: New Preview Features Enabled.
The addition ofdriverAdapters,postgresqlExtensions, andprismaSchemaFolderin thepreviewFeaturesarray should provide enhanced functionality. Please ensure these features are compatible with your production setup and tested in development.
136-142: OrganizationApiKey Model: Enhanced Tracking.
The fields and indexes in this model are now clearly marked. The use of@uniqueon thekeyfield and proper indexing should improve lookups.
150-160: OrganizationIntegrations Model: Clean and Modular.
This new model cleanly encapsulates integration details, including JSON fields for settings. The unique constraint onnameand the proper relation toOrganizationare well implemented.
162-173: AuditLog Model: Comprehensive Auditing Implementation.
The structure—with fields for a timestamp, user, organization, and associated JSON data—ensures robust logging. The added indexes support efficient querying.packages/db/prisma/schema/risk.prisma (8)
1-28: Risk Model: Detailed and Well-Indexed.
The Risk model is comprehensively defined with fields covering title, description, risk metrics, and relational links toOrganizationandUser. The indexes on key columns likeorganizationId,ownerId,category, andstatusshould support high-performance queries.
30-45: RiskComment Model: Thorough Comment Tracking.
This model effectively links comments to risks, users, and organizations with appropriate indexes. The cascading delete on related entities is correctly applied.
47-70: RiskMitigationTask Model: Robust Task Management.
The model includes numerous useful fields (e.g.,dueDate,notifiedAt,completedAt) and defines proper relations and indexes. Consider confirming that the naming of fields likenotifiedAtaligns with your business logic.
72-89: TaskComments Model: Clear Association for Task Discussions.
The model links comments to both risks and mitigation tasks while including necessary indexes. The design is clear and maintainable.
91-107: TaskAttachment Model: Effective Attachment Management.
The fields for file details and associated metadata are appropriate, and the relation toRiskMitigationTaskis clear.
109-119: RiskTreatmentStrategy Model: Focused and Unique.
The model enforces a one-to-one relationship withRiskthrough a unique constraint onriskIdand captures the treatment type and description as needed.
121-137: RiskAttachment Model: Structured for Clarity.
The model correctly collects attachment data related to risks and is properly linked to bothOrganizationandRiskwith useful indexing.
139-150: RiskTaskAssignment Model: Ensuring Unique Employee Assignments.
The unique constraint on[taskId, employeeId]ensures no duplicate assignments, and the defined relations withEmployeeandRiskMitigationTaskare well implemented.packages/db/prisma/schema/framework.prisma (9)
16-29: OrganizationFramework Model Review
- This model correctly captures the association between organizations and frameworks.
- The use of the enum
FrameworkStatusfor thestatusfield is appropriate; please verify thatFrameworkStatusis defined in your overall schema.- The unique constraint on
[organizationId, frameworkId]is a good design choice to prevent duplicate relationships.
31-41: FrameworkCategory Model Review
- The
FrameworkCategorymodel has clear definitions and a uniquecode, as well as the necessary foreign key (frameworkId) linking it to theFrameworkmodel.- The index on
[frameworkId]is helpful for query performance.
43-56: Control Model Review
- The
Controlmodel is detailed and includes fields such ascodeanddomainalongside an optional relationship viaframeworkCategoryId.- The inclusion of the
PolicyControlrelation requires that this related model is defined elsewhere in your modularized setup.- The index on
[frameworkCategoryId]supports efficient filtering; consider confirming that the optionality offrameworkCategoryIdaligns with your business rules.
58-77: OrganizationControl Model Review
- This model effectively tracks the compliance status and links to multiple other entities, capturing relationships with controls, organizations, and frameworks.
- Optional fields such as
organizationFrameworkIdandorganizationCategoryIdare correctly marked as optional.- The added indices on
organizationId,organizationFrameworkId, andcontrolIdwill aid query performance.
79-98: Artifact Model Review
- The
Artifactmodel is detailed and includes metadata (e.g.,published,needsReview,version) along with a JSON field forcontent.- Please ensure that the enums
DepartmentsandArtifactTypeare defined appropriately elsewhere.- The relations to
OrganizationandUser(asowner) appear correctly established; verify consistency with their definitions in the broader schema.
100-109: ControlArtifact Model Review
- This model correctly creates the many-to-many linkage between artifacts and organization controls.
- The relation definitions and indices are appropriate for ensuring referential integrity and performance.
130-150: OrganizationControlRequirement Model Review
- The unique constraint on
[organizationControlId, controlRequirementId]is a good design choice to enforce data integrity.- All relationships have clear
onDelete: Cascaderules where applicable, which supports clean-up of dependent records.
152-165: OrganizationCategory Model Review
- The
OrganizationCategorymodel neatly connects organizations to frameworks with corresponding foreign keys.- Timestamps and an index on
organizationIdare useful additions for tracking and performance.
178-205: OrganizationEvidence Model Review
- This model is robust, tracking various metadata such as publication status, multiple URL arrays (
additionalUrlsandfileUrls), and review dates.- The use of arrays (e.g., for URLs) is suitable provided your database supports them (e.g., PostgreSQL). Please verify this compatibility.
- Relationships to
Framework,User,Evidence, andOrganizationare correctly established. Ensure that these cross-file references are properly integrated in your modularized schema.
Create initial Prisma schema defining core database models and comprehensive enum types for the application, including: - Authentication models (User, Account, Session) - Organization and membership structures - Detailed enum definitions for roles, statuses, and categories - Comprehensive database relationships and indexing
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/db/prisma/schema/schema.prisma (2)
185-193: Enum Departments: Consider Future ExpansionThe Departments enum is defined with a limited set of values. Depending on future organizational structure needs, you might revisit this list to accommodate additional departments.
326-326: File Ending: Remove Trailing LineThere appears to be an extra or stray line (line 326) at the end of the file. Please remove it or ensure it does not affect the schema parsing.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/db/prisma/schema/schema.prisma(1 hunks)
🔇 Additional comments (31)
packages/db/prisma/schema/schema.prisma (31)
1-5: Generator Configuration: Verify Preview FeaturesThe generator block uses several preview features—
driverAdapters,postgresqlExtensions, andprismaSchemaFolder. Please double-check that these are stable and necessary for your production environment, as preview features can sometimes introduce unexpected behavior.
7-10: Datasource Configuration: Looks StandardThe datasource is configured correctly for PostgreSQL with the connection URL sourced from an environment variable. This is a standard and secure approach.
12-30: Model Account: Well-Defined StructureThe Account model is clearly defined. It uses a unique composite constraint on
providerandproviderAccountIdalong with an index onuserId, which is excellent for ensuring data integrity and optimal queries.
32-40: Model Session: Clear and ConciseThe Session model includes the necessary fields, a unique constraint on
sessionToken, and a proper relational link to the User model with cascade deletion.
42-72: Model User: Comprehensive Relationship SetupThe User model now excludes vendor-related fields and includes multiple relationships with other models. Please ensure that all related queries and business logic are updated to align with these changes. Consider adding or updating documentation for the rich set of relationships to aid future maintenance.
74-106: Model Organization: Clean and StructuredThe Organization model is well-structured with clear relationships and indexes. The removal of vendor-specific fields aligns with the PR objectives. Double-check that any query or integration depending on the old vendor fields is updated accordingly.
108-114: Model VerificationToken: Standard ImplementationThe VerificationToken model uses unique constraints appropriately, ensuring that token integrity is maintained.
116-132: Model OrganizationMember: Robust DefinitionThe OrganizationMember model features proper foreign key relationships, a composite unique constraint, and indexes. The design is both clear and efficient.
134-148: Model OrganizationApiKey: Secure and IndexedThe OrganizationApiKey model is set up well with unique constraints and indexes, providing a good structure for API key management.
150-160: Model OrganizationIntegrations: Effective Use of JSON FieldsThe OrganizationIntegrations model leverages JSON types for flexible settings storage. Everything appears correctly configured; just ensure that downstream code handles these JSON fields properly.
162-173: Model AuditLog: Detailed and SecureThe AuditLog model includes essential fields for logging, with proper indexing and cascade deletion established for its relationships. This will enhance audit tracking effectively.
175-178: Enum Tier: Simple and SufficientThe Tier enum is straightforward with values
freeandpro. This meets the current requirements.
180-183: Enum Role: Meets RequirementsThe Role enum listing
memberandadminis appropriate and clearly defined.
195-202: Enum RequirementType: Clear and ConciseThe RequirementType enum (with values such as
policy,file, etc.) is well-defined and supports the intended use cases.
204-208: Enum Frequency: Appropriate CadenceThe Frequency enum correctly reflects common periodic intervals with
monthly,quarterly, andyearly.
210-215: Enum FrameworkStatus: Clear Status IndicatorsThe FrameworkStatus enum provides meaningful statuses for framework progress (
not_started,in_progress,compliant,non_compliant).
217-222: Enum ComplianceStatus: Well-DefinedThe ComplianceStatus enum mirrors the structure of FrameworkStatus and is appropriate for tracking compliance steps.
224-229: Enum ArtifactType: Sufficient for Use CasesThe ArtifactType enum with values such as
policy,evidence,procedure, andtrainingis clear and fulfills its purpose.
231-235: Enum RiskLevel: Simple and EffectiveThe RiskLevel enum enumerates risk as
low,medium, orhigh. This simplicity aids clarity in risk assessment.
237-248: Enum RiskCategory: Verify Vendor Management InclusionThe RiskCategory enum includes
vendor_managementamong other values. Given the PR objectives to modularize vendor-related logic, please verify if this inclusion is intentional or if it should be moved to a separate module.
250-255: Enum TreatmentType: Concise and ClearThe TreatmentType enum adequately represents the options available (
accept,avoid,mitigate,transfer).
257-262: Enum RiskStatus: Comprehensive Status ValuesThe RiskStatus enum provides the necessary statuses for tracking risk progression.
264-268: Enum RiskTaskStatus: StraightforwardThe RiskTaskStatus enum is clear and effectively categorizes task statuses related to risk management.
270-273: Enum RiskAttachmentType: Proper CategorizationThe RiskAttachmentType enum, listing
fileandurl, is clearly defined.
275-284: Enum VendorCategory: Confirm Schema Modularization IntentThe VendorCategory enum is still present in the main schema. As part of the PR’s goal to remove redundant vendor-related models, please verify if this enum is needed here or should be migrated to a dedicated vendor schema module.
286-290: Enum VendorStatus: Re-evaluate PlacementSimilarly, the VendorStatus enum appears here despite the modularization efforts. Confirm whether it should remain in the main schema.
292-297: Enum VendorInherentRisk: Check Modularization ConsistencyThe VendorInherentRisk enum is defined with typical values. As with other vendor-related enums, please verify its placement relative to the new modularization strategy.
299-304: Enum VendorResidualRisk: Validate Schema LocationEnsure that including the VendorResidualRisk enum in this file aligns with the intended separation of vendor models, as mentioned in the PR objectives.
306-311: Enum MembershipRole: Clear Role DefinitionsThe MembershipRole enum with values such as
owner,admin,member, andvieweris well-defined and fits the requirements.
313-318: Enum EmployeeTaskStatus: Adequate Status OptionsThe EmployeeTaskStatus enum appropriately covers the statuses a task can have (
assigned,in_progress,completed,overdue).
320-325: Enum PolicyStatus: Correct and FunctionalThe PolicyStatus enum is concise and addresses the lifecycle of policies effectively.
Implement comprehensive Cloud Tests functionality: - Create new tests module with server and client-side components - Add AWS Security Hub integration for cloud security findings - Implement dynamic table, filtering, and pagination for test results - Add localization support for tests across multiple languages - Introduce new Prisma model for organization integration results - Update main menu and sidebar with new Cloud Tests navigation - Enhance UI with test details, assignment, and status tracking
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (11)
packages/db/prisma/schema/cloud.prisma (1)
1-20: Review of the OrganizationIntegrationResults Model Definition
The new model is well‑structured with clearly defined fields, relationships, cascading delete behaviors, and indexes. A couple of points to consider:
- The model name uses a plural form (“OrganizationIntegrationResults”). Confirm that this naming pattern is consistent with your other model names (e.g. whether you prefer singular names such as OrganizationIntegrationResult).
- The
completedAtfield is marked optional (DateTime?) while also having a default value (@default(now())). If you never intend for this field to be null, you might remove the optional marker to enforce non‑nullability.packages/db/prisma/schema/schema.prisma (1)
42-73: User Model – Cross-file Relationship Integration
TheUsermodel now includes a relation fieldOrganizationIntegrationResults, which links to the modularized model defined in a separate schema file. This integration appears correct. However, please verify that cross‑file references are resolved correctly in your workflow using theprismaSchemaFolderpreview feature.packages/db/prisma/migrations/20250306115054_test_mig/migration.sql (9)
14-21: Dropping Foreign Keys for VendorComment
The foreign key constraints for the "VendorComment" table are removed correctly. Consider adding an "IF EXISTS" clause (if supported by your SQL dialect) to avoid potential errors if a constraint is already absent in certain environments.
23-28: Dropping Foreign Keys for VendorContact
The commands for dropping constraints on the "VendorContact" table are consistent and clear. As with similar statements, consider using "IF EXISTS" to increase the idempotence of this migration.
29-36: Dropping Foreign Keys for VendorMitigationTask
Foreign key constraints on the "VendorMitigationTask" table are dropped in a logical order. Adding conditional checks (e.g., "IF EXISTS") could help prevent failures in case the constraints have already been removed.
38-46: Dropping Foreign Keys for VendorRiskAssessment
The removal of foreign key constraints from the "VendorRiskAssessment" table is implemented correctly. Again, the use of "IF EXISTS" (if available) may improve the script’s robustness across different database states.
47-52: Dropping Foreign Keys for VendorTaskAssignment
Constraints on the "VendorTaskAssignment" table are dropped properly. Consider adding "IF EXISTS" to ensure the migration runs smoothly even if these constraints are missing in some environments.
53-61: Dropping Foreign Keys for VendorTaskAttachment
The script correctly drops the foreign key constraints for the "VendorTaskAttachment" table. For added safety, consider using "IF EXISTS" to mitigate potential issues if the constraints were previously removed.
62-70: Dropping Foreign Keys for VendorTaskComments
The "VendorTaskComments" table’s constraints are dropped in two steps, ensuring that all relevant foreign keys are removed. You might consider consolidating these if the order is non-critical and adding "IF EXISTS" to each statement to improve error tolerance.
71-76: Dropping Foreign Keys for Vendors
The removal of foreign key constraints for the "Vendors" table is handled appropriately. As with previous segments, consider the "IF EXISTS" safeguard to improve migration resilience.
77-99: Dropping Vendor Tables
The migration script drops each vendor-related table sequentially after dropping their associated foreign keys. This aligns with the overall removal of vendor-related models as described in the PR objectives.
Consider wrapping these DROP TABLE commands within a transaction (if not already managed by the migration framework) to ensure atomic execution, and adding "IF EXISTS" clauses can further reduce the risk of errors during repeated migrations.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
apps/app/src/actions/soc2-seed.ts(0 hunks)apps/app/src/actions/vendor/create-vendor-action.ts(0 hunks)apps/app/src/actions/vendor/create-vendor-comment-action.ts(0 hunks)apps/app/src/actions/vendor/update-vendor-action.ts(0 hunks)apps/app/src/actions/vendor/update-vendor-risk-action.ts(0 hunks)packages/db/prisma/migrations/20250306115054_test_mig/migration.sql(1 hunks)packages/db/prisma/schema/cloud.prisma(1 hunks)packages/db/prisma/schema/schema.prisma(1 hunks)
💤 Files with no reviewable changes (5)
- apps/app/src/actions/soc2-seed.ts
- apps/app/src/actions/vendor/update-vendor-action.ts
- apps/app/src/actions/vendor/create-vendor-action.ts
- apps/app/src/actions/vendor/update-vendor-risk-action.ts
- apps/app/src/actions/vendor/create-vendor-comment-action.ts
🔇 Additional comments (12)
packages/db/prisma/schema/schema.prisma (11)
1-5: Generator Configuration and Preview Features
The generator block now includes additional preview features (driverAdapters,postgresqlExtensions,prismaSchemaFolder) which support schema modularization. Ensure that your current Prisma version supports these preview features and that they work as expected in your deployment workflow.
7-10: Datasource Configuration Check
The datasource configuration for PostgreSQL is standard and correctly references the environment variable for the connection URL. No issues detected here.
12-30: Account Model Verification
TheAccountmodel is defined with appropriate field types, constraints, and relationship configuration. The unique constraint on the combination ofproviderandproviderAccountIdand the index onuserIdare good for ensuring data integrity and query performance.
32-40: Session Model Overview
TheSessionmodel’s structure is standard and correct. The unique constraint onsessionTokenand proper cascading on the user relation ensure consistency.
75-108: Organization Model – New Relationships and Cross‑file References
TheOrganizationmodel properly incorporates theOrganizationIntegrationResultsfield along with existing relations. The structure is consistent, and the index onstripeCustomerIdhelps maintain performance. Just ensure that the cross‑file relationship with the modularizedOrganizationIntegrationResultsmodel is correctly handled by the Prisma CLI under the new schema organization.
110-116: Verification Token Model Check
TheVerificationTokenmodel is implemented correctly with appropriate unique constraints. It follows standard practices for token models.
118-134: OrganizationMember Model Review
This model is well‑constructed with proper default values, unique constraints, and indexes. The cascading delete rules on its relationships ensure integrity.
136-150: OrganizationApiKey Model Analysis
TheOrganizationApiKeymodel is appropriately defined, with unique and index constraints on fields such askeyandorganizationIdto optimize queries.
152-163: OrganizationIntegrations Model Examination
The model includes necessary JSON fields for integration settings and correctly establishes a one‑to‑many relationship with results. Since theresultsfield references theOrganizationIntegrationResultsdefined in a separate file, confirm that your modular setup correctly handles cross‑file references.
165-176: AuditLog Model Verification
TheAuditLogmodel includes all the expected fields and enforces indexes onuserIdandorganizationId, which is ideal for auditing purposes. Its relational directives with cascading deletes are correct.
178-329: Review of Newly Defined Enums
All newly added enums (e.g.,Tier,Role,Departments,RequirementType,Frequency,FrameworkStatus,ComplianceStatus,ArtifactType,RiskLevel,RiskCategory,TreatmentType,RiskStatus,RiskTaskStatus,RiskAttachmentType,VendorCategory,VendorStatus,VendorInherentRisk,VendorResidualRisk,MembershipRole,EmployeeTaskStatus,PolicyStatus) are clearly defined. They are straightforward and aid in maintaining field validations and consistency throughout the schema. Please verify that these enum additions will not create issues with existing migrations and that their naming conventions are uniformly used across your codebase.packages/db/prisma/migrations/20250306115054_test_mig/migration.sql (1)
1-13: Clear Warning: Data Loss Caution
The initial comment block clearly outlines the risks associated with dropping these vendor tables and warns about irreversible data loss if the tables are non-empty. This level of detail is very helpful for database administrators executing the migration.
Streamline authentication and middleware configuration: - Remove redundant `runtime = "nodejs"` exports across auth-related files - Simplify middleware logic by removing session-based redirects - Clean up authentication configuration and imports - Improve code readability and reduce unnecessary runtime specifications
…ture Clean up and remove deprecated vendor-related components: - Delete vendor overview, assessment, and comments components - Remove vendor charts and data table components - Update localization files to remove vendor-specific translations - Simplify file structure by removing unused vendor-related files - Update file upload components with more generic translation keys
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
apps/app/languine.lockis excluded by!**/*.lock
📒 Files selected for processing (38)
apps/app/src/app/[locale]/(app)/(dashboard)/vendors/(overview)/layout.tsx(0 hunks)apps/app/src/app/[locale]/(app)/(dashboard)/vendors/(overview)/page.tsx(0 hunks)apps/app/src/app/[locale]/(app)/(dashboard)/vendors/[vendorId]/layout.tsx(0 hunks)apps/app/src/app/[locale]/(app)/(dashboard)/vendors/[vendorId]/page.tsx(0 hunks)apps/app/src/app/[locale]/(app)/(dashboard)/vendors/register/layout.tsx(0 hunks)apps/app/src/app/[locale]/(app)/(dashboard)/vendors/register/page.tsx(0 hunks)apps/app/src/components/forms/vendors/create-vendor-comment-form.tsx(0 hunks)apps/app/src/components/forms/vendors/create-vendor-form.tsx(0 hunks)apps/app/src/components/forms/vendors/update-vendor-form.tsx(0 hunks)apps/app/src/components/forms/vendors/update-vendor-overview-form.tsx(0 hunks)apps/app/src/components/sheets/create-vendor-sheet.tsx(0 hunks)apps/app/src/components/sheets/vendor-comment-sheet.tsx(0 hunks)apps/app/src/components/sheets/vendor-overview-sheet.tsx(0 hunks)apps/app/src/components/tables/vendor-register/columns.tsx(0 hunks)apps/app/src/components/tables/vendor-register/data-table-header.tsx(0 hunks)apps/app/src/components/tables/vendor-register/data-table-pagination.tsx(0 hunks)apps/app/src/components/tables/vendor-register/data-table.tsx(0 hunks)apps/app/src/components/tables/vendor-register/empty-states.tsx(0 hunks)apps/app/src/components/tables/vendor-register/filter-toolbar.tsx(0 hunks)apps/app/src/components/tables/vendor-register/loading.tsx(0 hunks)apps/app/src/components/tables/vendor-register/server-columns.tsx(0 hunks)apps/app/src/components/upload/FileCard.tsx(5 hunks)apps/app/src/components/upload/FileSection.tsx(1 hunks)apps/app/src/components/upload/FileUpload.tsx(4 hunks)apps/app/src/components/vendors/charts/category-chart.tsx(0 hunks)apps/app/src/components/vendors/charts/status-chart.tsx(0 hunks)apps/app/src/components/vendors/charts/vendor-overview.tsx(0 hunks)apps/app/src/components/vendors/charts/vendors-by-assignee.tsx(0 hunks)apps/app/src/components/vendors/charts/vendors-by-category.tsx(0 hunks)apps/app/src/components/vendors/charts/vendors-by-status.tsx(0 hunks)apps/app/src/components/vendors/vendor-assessment.tsx(0 hunks)apps/app/src/components/vendors/vendor-comments.tsx(0 hunks)apps/app/src/components/vendors/vendor-overview.tsx(0 hunks)apps/app/src/locales/en.ts(1 hunks)apps/app/src/locales/es.ts(1 hunks)apps/app/src/locales/fr.ts(1 hunks)apps/app/src/locales/no.ts(1 hunks)apps/app/src/locales/pt.ts(1 hunks)
💤 Files with no reviewable changes (30)
- apps/app/src/components/tables/vendor-register/server-columns.tsx
- apps/app/src/components/vendors/charts/vendor-overview.tsx
- apps/app/src/app/[locale]/(app)/(dashboard)/vendors/(overview)/page.tsx
- apps/app/src/components/sheets/vendor-comment-sheet.tsx
- apps/app/src/components/tables/vendor-register/filter-toolbar.tsx
- apps/app/src/components/vendors/charts/vendors-by-category.tsx
- apps/app/src/components/tables/vendor-register/loading.tsx
- apps/app/src/components/sheets/create-vendor-sheet.tsx
- apps/app/src/components/forms/vendors/update-vendor-overview-form.tsx
- apps/app/src/app/[locale]/(app)/(dashboard)/vendors/[vendorId]/layout.tsx
- apps/app/src/components/sheets/vendor-overview-sheet.tsx
- apps/app/src/components/forms/vendors/update-vendor-form.tsx
- apps/app/src/app/[locale]/(app)/(dashboard)/vendors/(overview)/layout.tsx
- apps/app/src/app/[locale]/(app)/(dashboard)/vendors/register/layout.tsx
- apps/app/src/components/vendors/charts/status-chart.tsx
- apps/app/src/components/tables/vendor-register/data-table-pagination.tsx
- apps/app/src/components/tables/vendor-register/empty-states.tsx
- apps/app/src/components/vendors/charts/vendors-by-status.tsx
- apps/app/src/components/tables/vendor-register/data-table.tsx
- apps/app/src/components/forms/vendors/create-vendor-form.tsx
- apps/app/src/components/tables/vendor-register/data-table-header.tsx
- apps/app/src/components/forms/vendors/create-vendor-comment-form.tsx
- apps/app/src/app/[locale]/(app)/(dashboard)/vendors/[vendorId]/page.tsx
- apps/app/src/components/vendors/vendor-comments.tsx
- apps/app/src/app/[locale]/(app)/(dashboard)/vendors/register/page.tsx
- apps/app/src/components/tables/vendor-register/columns.tsx
- apps/app/src/components/vendors/charts/vendors-by-assignee.tsx
- apps/app/src/components/vendors/charts/category-chart.tsx
- apps/app/src/components/vendors/vendor-assessment.tsx
- apps/app/src/components/vendors/vendor-overview.tsx
🔇 Additional comments (21)
apps/app/src/locales/es.ts (1)
161-197: Consistent localization additions for file upload functionality.The new
uploadsection adds comprehensive localization strings in Spanish for the file upload interface, including file actions, URL management, and file previews. This is well-structured and maintains consistency with the existing localization pattern.apps/app/src/locales/en.ts (1)
126-164: Well-structured localization for file upload features.The added English localization strings for file upload functionality are well-organized with clear naming conventions and comprehensive coverage of UI elements. The nested structure maintains consistency with the rest of the localization file.
apps/app/src/locales/no.ts (1)
161-197: Complete Norwegian localization for file upload features.The Norwegian translations for the file upload interface are comprehensive and follow the same structure as the other language files, ensuring consistency across the application. The translations appear natural and appropriate.
apps/app/src/locales/fr.ts (1)
161-197: French localization added for upload functionality.The new French translations for the upload functionality are well-structured and complete, providing comprehensive coverage for file upload UI elements.
This addition organizes the translations into logical categories (fileUpload, fileUrl, fileCard, fileSection) which aligns with the component structure in the codebase. The French translations include all placeholder variables like
{count},{size}, and{fileName}that are essential for proper text formatting.apps/app/src/components/upload/FileSection.tsx (1)
110-112: Translation key path updated for consistency.The translation key has been updated from
upload.fileSection.filesUploadedtocommon.upload.fileSection.filesUploadedto align with the reorganized translation structure.apps/app/src/components/upload/FileCard.tsx (7)
132-132: Translation key path updated for consistency.The translation key has been updated from
upload.fileCard.previewtocommon.upload.fileCard.previewto align with the reorganized translation structure.
154-156: Translation key path updated for consistency.The translation key has been updated from
upload.fileCard.filePreviewtocommon.upload.fileCard.filePreviewto align with the reorganized translation structure.
180-180: Translation key path updated for consistency.The translation key has been updated from
upload.fileCard.previewNotAvailabletocommon.upload.fileCard.previewNotAvailableto align with the reorganized translation structure.
220-220: Translation key path updated for consistency.The translation key has been updated from
upload.fileCard.openFiletocommon.upload.fileCard.openFileto align with the reorganized translation structure.
240-240: Translation key path updated for consistency.The translation key has been updated from
upload.fileCard.deleteFiletocommon.upload.fileCard.deleteFileto align with the reorganized translation structure.
247-247: Translation key path updated for consistency.The translation key has been updated from
upload.fileCard.deleteFileConfirmTitletocommon.upload.fileCard.deleteFileConfirmTitleto align with the reorganized translation structure.
250-250: Translation key path updated for consistency.The translation key has been updated from
upload.fileCard.deleteFileConfirmDescriptiontocommon.upload.fileCard.deleteFileConfirmDescriptionto align with the reorganized translation structure.apps/app/src/components/upload/FileUpload.tsx (9)
93-93: Translation key path updated for consistency.The translation key has been updated from
upload.fileUpload.uploadingTexttocommon.upload.fileUpload.uploadingTextto align with the reorganized translation structure.
102-102: Translation key path updated for consistency.The translation key has been updated from
upload.fileUpload.dropFileHeretocommon.upload.fileUpload.dropFileHereto align with the reorganized translation structure.
105-105: Translation key path updated for consistency.The translation key has been updated from
upload.fileUpload.releaseToUploadtocommon.upload.fileUpload.releaseToUploadto align with the reorganized translation structure.
114-114: Translation key path updated for consistency.The translation key has been updated from
upload.fileUpload.addFilestocommon.upload.fileUpload.addFilesto align with the reorganized translation structure.
117-117: Translation key path updated for consistency.The translation key has been updated from
upload.fileUpload.uploadAdditionalEvidencetocommon.upload.fileUpload.uploadAdditionalEvidenceto align with the reorganized translation structure.
120-120: Translation key path updated for consistency.The translation key has been updated from
upload.fileUpload.dragDropOrClicktocommon.upload.fileUpload.dragDropOrClickto align with the reorganized translation structure.
149-151: Translation key path updated for consistency.The translation key has been updated from
upload.fileUpload.uploadingFiletocommon.upload.fileUpload.uploadingFileto align with the reorganized translation structure.
158-159: Translation key path updated for consistency.The translation keys have been updated from
upload.fileUpload.dropFileHereAltandupload.fileUpload.dragDropOrClickToSelecttocommon.upload.fileUpload.dropFileHereAltandcommon.upload.fileUpload.dragDropOrClickToSelectto align with the reorganized translation structure.
162-162: Translation key path updated for consistency.The translation key has been updated from
upload.fileUpload.maxFileSizetocommon.upload.fileUpload.maxFileSizeto align with the reorganized translation structure.
| upload: { | ||
| fileUpload: { | ||
| uploadingText: "Carregando...", | ||
| uploadingFile: "Carregando arquivo...", | ||
| dropFileHere: "Solte o arquivo aqui", | ||
| dropFileHereAlt: "Solte o arquivo aqui", | ||
| releaseToUpload: "Solte para carregar", | ||
| addFiles: "Adicionar Arquivos", | ||
| uploadAdditionalEvidence: "Carregue um arquivo ou documento", | ||
| dragDropOrClick: "Arraste e solte ou clique para navegar", | ||
| dragDropOrClickToSelect: "Arraste e solte ou clique para selecionar o arquivo", | ||
| maxFileSize: "Tamanho máximo do arquivo: {size}MB" | ||
| }, | ||
| fileUrl: { | ||
| additionalLinks: "Links Adicionais", | ||
| add: "Adicionar", | ||
| linksAdded: "{count} link{s} adicionado{s}", | ||
| enterUrl: "Digite a URL", | ||
| addAnotherLink: "Adicionar Outro Link", | ||
| saveLinks: "Salvar Links", | ||
| urlBadge: "URL", | ||
| copyLink: "Copiar Link", | ||
| openLink: "Abrir Link", | ||
| deleteLink: "Excluir Link" | ||
| }, | ||
| fileCard: { | ||
| preview: "Pré-visualização", | ||
| filePreview: "Pré-visualização do Arquivo: {fileName}", | ||
| previewNotAvailable: "Pré-visualização não disponível para este tipo de arquivo", | ||
| openFile: "Abrir Arquivo", | ||
| deleteFile: "Excluir Arquivo", | ||
| deleteFileConfirmTitle: "Excluir Arquivo", | ||
| deleteFileConfirmDescription: "Esta ação não pode ser desfeita. O arquivo será excluído permanentemente." | ||
| }, | ||
| fileSection: { | ||
| filesUploaded: "{count} arquivos carregados" | ||
| } | ||
| } |
There was a problem hiding this comment.
Split upload localization in Portuguese file.
The Portuguese localization has the upload section split into two locations: one within the common object (lines 161-198) and a second at the root level (lines 863-901). This could cause issues if the code expects all upload-related localization to be under common.upload.
Recommend consolidating all upload-related localization under common.upload to match the structure of the other language files:
- upload: {
- fileSection: {
- filesUploaded: "{count} arquivo(s) enviado(s)",
- upload: "{count} arquivo(s) enviado(s)"
- },
- fileUpload: {
- uploadingText: "Enviando...",
- dropFileHere: "Solte o arquivo aqui",
- releaseToUpload: "Solte para enviar",
- addFiles: "Adicionar Arquivos",
- uploadAdditionalEvidence: "Enviar um arquivo",
- dragDropOrClick: "Arraste e solte ou clique para enviar",
- dropFileHereAlt: "Solte o arquivo aqui",
- dragDropOrClickToSelect: "Arraste e solte um arquivo aqui ou clique para selecionar",
- maxFileSize: "Tamanho máximo do arquivo: {size}MB",
- uploadingFile: "Enviando arquivo..."
- },
- fileCard: {
- preview: "Pré-visualização",
- previewNotAvailable: "Pré-visualização não disponível. Clique no botão de download para visualizar o arquivo.",
- filePreview: "Pré-visualização do arquivo: {fileName}",
- openFile: "Abrir arquivo",
- deleteFile: "Excluir arquivo",
- deleteFileConfirmTitle: "Excluir Arquivo",
- deleteFileConfirmDescription: "Você tem certeza de que deseja excluir este arquivo? Esta ação não pode ser desfeita."
- },
- fileUrl: {
- additionalLinks: "Links Adicionais",
- add: "Adicionar",
- linksAdded: "{count} link{s} adicionado",
- enterUrl: "Digite a URL",
- addAnotherLink: "Adicionar Outro Link",
- saveLinks: "Salvar Links",
- urlBadge: "URL",
- copyLink: "Copiar link",
- openLink: "Abrir link",
- deleteLink: "Excluir link"
- }
- },Additionally, the evidence section at line 859-862 is much shorter than in other language files. This could lead to missing translations.
Also applies to: 863-901
2 participants
Split the main Prisma schema into modular files for better organization:
Summary by CodeRabbit
New Features
Chores