| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37748 |
28 m |
ranu |
/trunk/profitmandi-fofo/src/main/ |
today po rbm view showing only for l7 and above |
|
| 37747 |
1 h 1 m |
ranu |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/monitors/ |
today po rbm view showing only for l7 and above |
|
| 37746 |
1 h 13 m |
amit |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ |
feat(scheme): add Ear Buds category (10024) to scheme creation category list |
|
| 37745 |
1 h 13 m |
ranu |
/trunk/profitmandi-fofo/src/main/ |
today po rbm view showing only for l7 and above |
|
| 37744 |
3 h 29 m |
amit |
/trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/service/warehouse/ |
test(warehouse): raising a movement order stamps the line with the stock's cost and vendor
Covers the last untested link in the cost-layer chain: PurchaseOrderServiceImpl writing lineitem.origin_vendor_id and the line price, which is what GRN copies onto received stock. |
|
| 37743 |
1 d 22 h |
vikas |
/trunk/ |
LMS checklist for call |
|
| 37742 |
1 d 23 h |
amit |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/exception/ |
v2: silence client disconnects and demote 4xx, matching the v1 taxonomy
r37728 added a client-disconnect handler to the v1 GlobalExceptionHandler and the
flood did not stop: #39 went on adding events, and every one of a 50-event sample
was from a /v2/ URL. V2GlobalExceptionHandler is scoped
basePackages="com.spice.profitmandi.web.v2", so v2 responses never reached the v1
handler at all and fell through to its own handleGenericException at ERROR --
~19,900 events, the second largest source on the board.
Worth recording because the first diagnosis was wrong. The theory was that an
exception raised while the response body is written cannot reach an @ExceptionHandler
because the response is already committed. It can: DispatcherServlet catches it out of
ha.handle() and still runs the resolvers. What it cannot do afterwards is WRITE the
substitute response. The handler runs and logs either way, which is precisely why
patching the wrong advice class changed nothing.
Adds @ExceptionHandler(IOException.class) here, delegating to the same
isClientDisconnect test the v1 handler uses -- duplicated rather than shared because
catalina is provided by the container and is not on this module's compile classpath,
so ClientAbortException cannot be imported and is matched on simple name plus the
messages a dead peer actually produces. A genuine IOException (full disk, a broken
pipe to something that is not the client) matches none of them and keeps its ERROR
and its 500. Returns null for a disconnect: the connection that would carry a body is
already gone, and writing to it is what raised this.
Also demotes five sibling handlers in the same file that were logging caller mistakes
at ERROR, which v1 has logged at WARN since the taxonomy work: business validation,
missing parameter, type mismatch, malformed body, method not supported, media type
not supported. v2 never received that pass. The business line also stops attaching a
stack trace -- a validation has nothing useful in one.
Left at ERROR deliberately, because they are real defects: IllegalArgument, NPE,
genuine IO failure, and the two catch-alls. |
|
| 37741 |
2 d 0 h |
amit |
/trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/ |
fix(fofo): show Pine Labs monthly EMI in rupees, not paise
Plural sends Money.value in paise; the EMI offers modal printed it raw
(185959 INR instead of Rs 1,859.59). Converted at the view only - the
web API hands the same DTO to the app, which expects paise. |
|
| 37740 |
2 d 2 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/ |
SD credit: getAvailableAmount no longer writes utilized_limit - it is a read path, but the managed entity was dirty-checked so every availability query (gateway callback, both sanction screens, bulk order creation) flushed an UPDATE; availability is now computed locally as limit - liveUtilization, same value |
|
| 37739 |
2 d 2 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/gstpro/ |
GstProService: drop imports only the removed Perfios block used
HttpHostConnectException and JSONObject had no other use after r37736. |
|
| 37738 |
2 d 3 h |
vikas |
/trunk/ |
LMS checklist for call |
|
| 37737 |
2 d 3 h |
vikas |
/trunk/ |
LMS checklist for call |
|
| 37736 |
2 d 3 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/gstpro/ |
Remove dead Perfios GST-return OTP block from GstProService
Commented-out since it was added; the Perfios UAT URL and auth key were the
only trace of that integration. Part of the dead-integrations cleanup
(r37730-37735). |
|
| 37735 |
2 d 3 h |
amit |
/trunk/profitmandi-cron/src/main/ |
Remove dead third-party integrations: cron
- Toffee: attachToffeeInvoices (schedule already commented out), toffeeRollback
and the --tc option; tofee.* keys in run.properties
- Bharti Assist: sendBAGPendingPolicies, testBag/mapBag and the --bag /
--mapbag options
- HyperTrack geofence one-offs (--createGeofence, --getAllGeofences,
--deleteGeofences) and their hardcoded account keys
- SmartPing injection in ScheduledTasks; leftover DTDC comment
- aramex.tracking.url in run.properties |
|
| 37734 |
2 d 3 h |
amit |
/trunk/profitmandi-fofo/src/ |
Remove dead third-party integrations: fofo
- SpiceMoney: controller, spiceform.vm, logo, the Quick Links popover on
analysisDashboard / dashboard-readonly (its button was already commented
out in dashboard1.vm) and the /spicemoney/callback auth exclusions
- FundFina controller and the /fundfina/** auth exclusions
- Wiseapp: the Quick Links popover on 12dashboard34 (its only entry) and logos
- SmartPing injection in WebHookController; the Knowlarity webhooks keep
working with the models now in kommuno/model
- Unused Toffee model reference in WarehouseController
- tofee.* keys, aramex.tracking.url and the PAYU PAY payment option in
main and test resources |
|
| 37733 |
2 d 3 h |
amit |
/trunk/profitmandi-web/src/main/ |
Remove dead third-party integrations: web
- PayU: /payu-pay and the payu-pay-response/cancelled handlers (bodies were
already commented out), PayuHandler, payment/ helpers, PayU POJOs, and the
PAYU PAY option served by checkout/payment-options.
PayuPayController stays: it holds the live CCAvenue, Razorpay and Pine Labs
callbacks.
- SmartPing: GET /click2call/{toMobile} (v1 + v2) and the caller-ID hook
/smartping/receipt + /v2/hookCallerID, which only logged
- HyperTrack: device location, partner location and geofence endpoints plus
HyperTrackService. The attendance endpoints (/getPunchHistory,
/employee/attendance) never called HyperTrack and are kept, moved to
EmployeeAttendanceController / V2EmployeeAttendanceController.
- Affiliate click-outs and live pricing (Amazon/Flipkart/Snapdeal via OMG):
ClicksController, LivePricingController and v2 wrappers. Live pricing was
already returning an empty list.
- Thriwe controller (fully commented out), SpiceMoney and FundFina v2 controllers
- Aramex branch of /track; tofee.* keys in dev/prod properties |
|
| 37732 |
2 d 3 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/ |
purchase return: look up the open return against a document
selectOpenByDocumentReference returns the return still outstanding against a
document reference - neither refunded nor rejected - or null when none is.
Backs a duplicate guard on the invoice-return submit path: the same invoice was
being submitted twice, the closest pair eight seconds apart, and finance was
rejecting the extras by hand. A settled return deliberately does not count, since
rejecting a return is precisely what frees the invoice to be raised again.
Repository lands first so the method exists before the caller uses it. |
|
| 37731 |
2 d 3 h |
amit |
/trunk/profitmandi-dao/src/main/ |
Remove dead third-party integrations: dao
Nothing removed here had a live caller. No tables are touched.
- Toffee Insurance client + models, and the tofee.* keys in shared-*.properties
- Bharti Assist (BAG) service and its certificate/brand models. BagPlanModel
and PlanVariant stay in bharti/model: OneAssist and ICICI Lombard use them.
- Private, uncalled Toffee/BAG request builders in InsuranceServiceImpl
- Wiseapp insurance client and ZestResponseModel
- SmartPing client. CallDetailModel and PushCallLogModel move to
kommuno/model because the Knowlarity webhooks still parse them.
- SpiceMoney SSO (2-partner pilot), Thriwe stub + DTOs, DTDC/Shipsy (demo
URLs only), Blue Dart SOAP stubs, legacy Pine Labs v1 client
- FundFina pre-approval entity/repository, HyperTrack key entity/repository,
affiliate Click entity/repository
- Speqtra SMS constant; aramex.tracking.url keys
- PAYU PAY entry in payment-options.json
Gateway.MANDII and Gateway.FUNDFINA stay: historical fofo.payment rows. |
|
| 37730 |
2 d 3 h |
amit |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/ |
Remove dead third-party integrations: common
Part of the integrations cleanup across all modules. Nothing here had a
live caller.
- Snapdeal product-page parser and UserMessagePojo (affiliate live pricing)
- FundFina request/response DTOs (inbound lender API, removed)
- Aramex XML tracking client (only reachable via /track provider=2)
- WiseApp insurance model
- URL constants for PayU, the SmartPing caller-ID hook, affiliate clicks and
live pricing; the SmartPing agent map |
|
| 37729 |
2 d 3 h |
amit |
/trunk/ |
lead: one workable lead per mobile, with a 6-month supersede and an L2+ override
There was no choke point for lead creation. Ten sites did `new Lead()` across four
modules -- three in web's LeadController, two in V2FofoLeadController, three in fofo's
LeadController, one in TrialServiceImpl and one in the cron LeadSyncRunner -- and only
ONE of them (fofo /createLead) checked for an existing lead at all. Result on live data:
5,137 mobiles carrying duplicate leads over 12,156 rows, worst case 29 on one number,
and two agents unknowingly working the same shop.
THE RULE, in new LeadCreationService, which all ten now route through:
no active lead on the number -> create
active, last activity >= 6 months -> retire the old one, create the new one, SILENTLY
active, last activity < 6 months -> BLOCK; only an L2+ user may override
Active = status in (pending, followUp) AND the assignee is still an active auth_user.
Last activity = GREATEST(lead.updated/created, MAX(lead_activity.created)).
The stale branch is deliberately quiet. A shop enquiring again after six months is a
handover, not a clash, and mailing on it would train the desk to ignore the alert -- so
only a genuine collision notifies. Live split: 195 stale against 1,241 fresh, and roughly
three blocks a month.
WHY "ACTIVE" ALSO MEANS A LIVE OWNER
331 open leads are assigned to 11 DEACTIVATED accounts (157 to sm@smartdukaan.com alone,
whose newest lead is from 2022). Counting them as active would block fresh enquiries
behind an account nobody can log in to and therefore nobody can close. Requiring a live
owner defuses all 331 without retiring a single row. Retirement here is only ever
REACTIVE -- triggered by a new entry on the same number. Nothing runs on a schedule.
ASSUMPTION worth flagging: a superseded lead becomes status=notInterested (stage DROPPED)
with closure_timestamp and reason 'Superseded after 6 months inactivity', rather than a
new `expired` status. "Closed" is an explicit allow-list in the UI --
Arrays.asList(notInterested, finalized) at V2FofoLeadController:150 and fofo
LeadController:313 -- and there are ~107 references to specific LeadStatus values, so a
new enum value would make these leads vanish from BOTH the open and closed screens.
Stage DROPPED keeps the nuance (the shop never said no) and still maps to notInterested
via LeadStage.toLegacyStatus().
OVERRIDE is L2+ in ANY team, not Call Center only: Sales L1 owns 1,063 of the 1,776 open
leads, so a Call-Center-only gate would funnel every team's collisions through three
people. The MAIL still goes to Call Center L2+, resolved from cs.position at send time
rather than hardcoded. An override is a TAKEOVER -- it closes the existing lead -- because
a second live lead is the exact thing the rule exists to prevent.
UNATTENDED CALLERS (cron sync, CSV upload, trial registration, AI intake) have nobody to
offer an override to, so they use createUnattended: skip the colliding row and mail the
desk rather than throwing. CSV reports imported/duplicateSkipped/duplicateMobiles back to
the operator instead of failing the whole file over one number.
ALSO FIXES selectByMobileNumber, which called getSingleResult and therefore threw
NonUniqueResultException on any mobile with more than one lead -- GlitchTip #99 and #1359,
both still firing. It now prefers the open lead, then the most recently touched.
NOT INCLUDED, deliberately: no DB unique constraint. 10 mobiles already carry more than
one open lead and would have to be resolved by hand first, which conflicts with the
no-auto-retirement rule. The service enforces the invariant going forward.
NEEDS A DBA STEP: user.lead.mobile is unindexed on 37,580 rows, so this check is a full
scan on every create. Index DDL is in the accompanying note; it has NOT been applied. |
|