Rules Hub
Coding Rules Library
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Check soft-delete/disabled flags before serving a cached entity
A truthy lookup result can still be a deactivated entity — check its active/deleted flag before returning it publicly.
Bad example
| 1 | const user = await UserRepository.byId(req.params.id); |
| 2 | if (!user) throw new Http404(); |
| 3 |
|
| 4 | return res.json(user.publicProfile()); |
Explanation (EN)
A user that was deleted or disabled upstream can still exist in the cache/index that backs `byId`, so `!user` is `false` and the disabled account's name, email, and photo are served as a live public profile.
Objašnjenje (HR)
Korisnik koji je gore u sustavu obrisan ili onemogućen i dalje može postojati u cacheu/indexu koji stoji iza `byId`, pa je `!user` netočno (`false`) i podaci onemogućenog računa (ime, email, slika) se serviraju kao živi javni profil.
Good example
| 1 | const user = await UserRepository.byId(req.params.id); |
| 2 | if (!user || user.isDeleted || user.disabled) throw new Http404(); |
| 3 |
|
| 4 | return res.json(user.publicProfile()); |
Explanation (EN)
The entity's own active/deleted state is checked explicitly, so a deactivated record is treated the same as a missing one from the caller's perspective.
Objašnjenje (HR)
Eksplicitno se provjerava vlastito stanje entiteta (aktivan/obrisan), pa se deaktiviran zapis za pozivatelja tretira jednako kao da ne postoji.