-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
fix(core): Administrator soft delete constraint error (#1523) #3890
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
base: master
Are you sure you want to change the base?
fix(core): Administrator soft delete constraint error (#1523) #3890
Conversation
|
Someone is attempting to deploy a commit to the Vendure Team on Vercel. A member of the Team first needs to authorize it. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
WalkthroughModified the Administrator entity to use a composite unique constraint on Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
All contributors have signed the CLA ✍️ ✅ |
|
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.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
packages/core/src/service/services/administrator.service.ts (2)
349-352: Critical: Restore logic must also setisCurrent = true.When restoring a soft-deleted administrator, the code sets
deletedAt = nullbut does NOT restoreisCurrentback totrue. This is a bug because:
- The restored administrator will have
deletedAt = nullbutisCurrent = null- This breaks the intended pattern where active administrators should have
isCurrent = true- This could prevent creating new administrators with the same email if the restored one has
isCurrent = nullApply this diff to fix the restore logic:
} else if (superAdministrator.deletedAt != null) { superAdministrator.deletedAt = null; + superAdministrator.isCurrent = true; await this.connection.rawConnection.getRepository(Administrator).save(superAdministrator); }
256-273: Restore operations missingisCurrentrestoration.The soft-delete sets both
isCurrent: nullanddeletedAt, but restore operations at lines 349–350 and 354–356 only restoredeletedAtto null, leavingisCurrentas null. This creates an inconsistent state where the administrator appears deleted for uniqueness enforcement (due to the@Unique(['emailAddress', 'isCurrent'])constraint) whiledeletedAtis cleared.Update the restore logic to also set
isCurrent = true:} else if (superAdministrator.deletedAt != null) { superAdministrator.deletedAt = null; superAdministrator.isCurrent = true; await this.connection.rawConnection.getRepository(Administrator).save(superAdministrator); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/core/src/entity/administrator/administrator.entity.ts(3 hunks)packages/core/src/service/services/administrator.service.ts(1 hunks)
🔇 Additional comments (3)
packages/core/src/entity/administrator/administrator.entity.ts (1)
2-2: LGTM! Import needed for composite constraint.The
Uniqueimport is correctly added to support the class-level composite unique constraint.packages/core/src/service/services/administrator.service.ts (2)
264-266: LGTM! Soft delete correctly updates both fields.The soft delete operation now correctly sets both
isCurrent: nullanddeletedAt, which is essential for the composite unique constraint to allow email address reuse.
354-357: No action required - the review comment is based on incorrect assumptions.The User entity structure is fundamentally different from Administrator and does not have an
isCurrentfield or composite unique constraints. User only implements soft-deletion viadeletedAt, which is already handled correctly byuserService.softDelete(). The restoration logic at lines 354-357 properly handles both entities according to their respective designs: Administrator resetsdeletedAt, and User resetsdeletedAt(with noisCurrentto manage).Likely an incorrect or invalid review comment.
| @Column({ type: 'boolean', default: true, nullable: true }) | ||
| isCurrent: true | null; |
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.
Verify type safety: TypeScript true | null vs SQL boolean.
The TypeScript type is true | null, but the column type is boolean. This mismatch could cause issues:
- SQL
booleancolumns can storetrue,false, ornull - If the database ever returns
false(through direct DB manipulation or ORM behavior), TypeScript will not expect it - TypeScript will show type errors when assigning
booleanvalues to this field
Consider using boolean | null for better type safety, and enforce the constraint through validation logic or a database CHECK constraint if you truly want to prevent false values.
If you want to keep the current pattern, add a comment explaining why only true and null are valid values.
+ // isCurrent can only be true (for active administrators) or null (for soft-deleted ones)
+ // This constraint allows multiple soft-deleted administrators with the same email address
@Column({ type: 'boolean', default: true, nullable: true })
isCurrent: true | null;🤖 Prompt for AI Agents
In packages/core/src/entity/administrator/administrator.entity.ts around lines
35-36, the property is declared as TypeScript type `true | null` while the
Column is defined as SQL `boolean`; change the TS type to `boolean | null` to
match the database semantics (allow true, false, or null) or, if you truly
require only true/null, keep `true | null` but add a clear inline comment
explaining the restriction and add application-level validation or a DB CHECK
constraint to prevent false values; ensure any code that sets/reads this field
is updated to the chosen type/validation approach.
|
I have read the CLA Document and I hereby sign the CLA |
|
recheck |
dlhck
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.
I don't think this is the correct approach. We should rather remove the unique constraint on the emailAddress and do the proper exist-checks in the create and update in the administrator.service.ts. Similar to what we have in customer.service.ts



Description
Fixes administrator soft delete constraint error by adding combined unqiue index. #1523
Breaking changes
None.
Screenshots
None.
Checklist
📌 Always:
👍 Most of the time:
Summary by CodeRabbit
Bug Fixes
Chores