| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37651 |
22 d 4 h |
vikas |
/trunk/ |
LMS click to call |
|
| 37552 |
29 d 7 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
lead/knowlarity: stop a null lookup key from matching every row
selectByEquals maps a null VALUE to NO PREDICATE AT ALL rather than to "= null",
because GenericRepositoryImpl.prepareEqualPredicate skips null entries. So a null
lookup key does not miss -- it selects the whole table and dies on
NonUniqueResultException. Two live call paths were doing exactly that.
RecordingService.updateAgentCallLog read caller_id, which knowlarity has never sent
on push-call-log: a sample of 50 live webhooks contained it zero times. Every call
therefore ran selectByCallerId(null) -> "select every sip_master row" -> throw, and
the whole feed was discarded. 17 of those 50 were Connected calls with a real agent.
Resolve the agent from agent_number instead, which is the field that actually
identifies them and holds the sip_url; it arrives bare, sip:-prefixed, or as the
literals "False"/"None" when nobody picked up. caller_id is still honoured first in
case they ever start sending it. A payload naming no agent is INFO, and an agent
missing from sip_master is WARN (an ops fix, and per-agent, so an ERROR would
fingerprint into one GlitchTip issue per agent).
AuthRepositoryImpl.putEmailOrMobile had the same hole via Long.parseLong(null)
falling into the catch and putting a null email. selectByEmailOrMobile(null)
degenerated to "select all 405 users", and authenticate(null, hash) degenerated to
"does ANY user have this password hash", which would answer true. Both fail closed
today only as an accident of how many rows the table holds, so the guard goes on the
one path they share.
Fixes GlitchTip #58/#1324/#1335 (fofo, 281 events) and #10 (web). |
|
| 37309 |
56 d 0 h |
vikas |
/trunk/ |
Scratch Offers now selects only active partners |
|
| 37248 |
63 d 4 h |
vikas |
/trunk/ |
Updated Escalation Level |
|
| 37153 |
73 d 2 h |
vikas |
/trunk/ |
Null check for email |
|
| 37038 |
92 d 0 h |
vikas |
/trunk/ |
Beat Report: Gaurav Mathur can see all sales employees data, also added past discussions |
|
| 36897 |
108 d 2 h |
vikas |
/trunk/ |
Location Tracking Dashboard |
|
| 36896 |
108 d 4 h |
vikas |
/trunk/ |
Mark Agenda Filled: Update logic |
|
| 36867 |
112 d 6 h |
ranu |
/trunk/ |
pendig visit should be come in defered |
|
| 36852 |
114 d 5 h |
ranu |
/trunk/ |
code committed by some bug fix in pjp |
|
| 36848 |
115 d 3 h |
vikas |
/trunk/ |
Update BeatTrackingController to update total_distance |
|
| 36762 |
127 d 23 h |
vikas |
/trunk/ |
Punch, Check, Deferred handling improvements and mapbox |
|
| 36758 |
128 d 0 h |
vikas |
/trunk/ |
Punch, Check, Deferred handling improvements and mapbox |
|
| 36709 |
134 d 1 h |
vikas |
/trunk/ |
Show Image in popup with approve Action, Increased MAP markers size |
|
| 36699 |
134 d 23 h |
vikas |
/trunk/ |
Validation for Duplicate beat tracking creation |
|
| 36664 |
137 d 21 h |
vikas |
/trunk/ |
Beat Reports & Live Tracking |
|
| 36656 |
138 d 2 h |
vikas |
/trunk/ |
Beat Reports |
|
| 36645 |
138 d 7 h |
vikas |
/trunk/ |
Added Beat Report |
|
| 36601 |
142 d 0 h |
vikas |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/ |
Location Tracking Report: Add Travel Row and added Company Office Repository Implementation |
|
| 36291 |
174 d 6 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/ |
Optimize slow DB queries: split fan-out join, FORCE INDEX on wallet history
- CurrentInventorySnapshotRepositoryImpl.getSpilitStockBatch: split
LEFT-JOIN fan-out into two independent aggregates (~8x faster);
fixes SUM(DISTINCT) undercounting bug where same availability/qty
values across items collapsed into one.
- UserWalletRepositoryImpl.getWarehousewiseCollection: HQL -> native
SQL with FORCE INDEX(idx_uwh_wallet_timestamp) so timestamp range
filters at index level instead of row filter (~4x faster, 3.1s -> 722ms).
- PartnerCollectionPlanRepositoryImpl.getCommitmentCollectionSummary:
Criteria 3-Root CROSS JOIN -> explicit INNER JOIN + FORCE INDEX
(idx_uwh_wallet_timestamp) (~3.5x faster). |
|