KamoCRM

History records what happens after a lead exists, not its starting form

Fixkamo-shared-library
관련 상품
2026년 9월 23일 오후 11:27 UTC
이름 *
Kamo
뚱 베어
31880e8

recordCreated wrote the CREATED row and then diffed the new lead against an empty snapshot, so every non-null starting field became a FIELD_CHANGED row — and the market and pool-entry keys, which carry their own event types, a MARKET_CHANGED and a MARKED_FOR_REASSIGNMENT row. Every intake lead therefore opened its History tab with ~20 rows restating the form it arrived with: 16.8M rows for 796K leads, 11M+ INSERTs per the database's own statistics. It also let a member earn the status-change achievement just by creating a lead (it reads FIELD_CHANGED on status). Creation now writes the CREATED row only; the lead itself is its starting state, and the first real change records the value it replaced in previous_value. **************** had the same shape (25 accounts, 227 rows) and follows the same rule. LeadHistoryServiceCreatedTest pins both halves (one row at creation; a later change keeps its previous value) and goes red with the old creation diff restored, as does the updated AccountHistoryServiceTest case. Takes effect as the lead-creating services rebuild: securityservice, daemonservice (intake processing), mediaservice (webinar registrations). Existing rows are untouched.

모든 변경 사항

배송을 보는 것과 같이?

모든 것이 자신의 작업 공간에서 도착합니다. 무료 플랜을 시작하고 이 페이지를 다시 한 달에 읽으십시오.

무료 영원히 시작가격 비교