fix: default modification activated flag to true at creation only#190
fix: default modification activated flag to true at creation only#190flomillot wants to merge 1 commit into
Conversation
The activated field defaulted to true in the DTO, so after deserialization it was never null when omitted from a request. This made the null guard in updateNetworkModificationMetadata always pass, silently reactivating a deactivated modification on edit. The field now defaults to null; the true default is applied at creation only, which preserves the activated status when the field is not provided on update. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Signed-off-by: Florent MILLOT <75525996+flomillot@users.noreply.github.com>
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
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 |
The
activatedfield ofModificationInfosdefaulted totrue(field initializer +@Builder.Default), so after JSON deserialization it was nevernullwhen omitted from a request.As a consequence, the null guard
if (metadata.getActivated() != null)inupdateNetworkModificationMetadata(network-modification-server) was always satisfied, silently reactivating a deactivated modification when editing it without sending the field.Change
activatednow defaults tonullin the DTO.truedefault must be applied at creation only (handled on the server side in theModificationEntity(ModificationInfos)constructor).This way, sending
nullon update leaves the activation status unchanged, while a creation without the field still produces an activated modification.