SmartDukaan – //trunk/profitmandi-web/src/main/java/

Rev 37821 – Lead Management: CSV download now also honours the lead table's ...

aman — Thu, 01 Oct 2026 19:12:54 +0530

aman – 3 file(s) modified
Lead Management: CSV download now also honours the lead table's search text (searchTerm), so the exported rows match the filtered rows on screen. Applies to both the fofo download and the V2 API download.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JjVXnkrysiXEa2YYRn4BqL

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/LeadController.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/lead.js
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoLeadController.java

Rev 37820 – Lead Management: make Excel/CSV download honour the same filters as ...

aman — Thu, 01 Oct 2026 18:36:37 +0530

aman – 3 file(s) modified
Lead Management: make Excel/CSV download honour the same filters as the on-screen list. V2 download no longer folds followUp into the status list when All is chosen (it skipped the status/color/date query and exported only follow-ups); fofo lead page re-selects every chosen status so Download sends the statuses the table was loaded with.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JjVXnkrysiXEa2YYRn4BqL

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/LeadController.java
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/lead.vm
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoLeadController.java

Rev 37793 – feat(cart): carry bag pricing via CarryBagQuote in V2 cart and ...

amit — Mon, 28 Sep 2026 15:37:47 +0530

amit – 2 file(s) modified
feat(cart): carry bag pricing via CarryBagQuote in V2 cart and order create

V2CartController prices and rebalances the carry bag through
CartService.getCarryBagQuote: one bag at Rs 1 per smartphone over Rs 12,000,
extras at listing, Bronze at listing for all. The old resolveCarryBagPrice /
CARRY_BAG_PREMIUM_PRICE path and its partnerTypeChangeService dependency are
removed. OrderController splits the blended carry bag line into its two
priced orders when partitioning the cart, so the same SKU appears twice on
one invoice at its two prices.

Needs profitmandi-dao r37792; deploy together with the partner apps.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/checkout/OrderController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2CartController.java

Rev 37781 – feat(partner-access): demo partners in app switcher + impersonate - ...

amit — Fri, 25 Sep 2026 13:17:18 +0530

amit – 3 file(s) modified
feat(partner-access): demo partners in app switcher + impersonate

- /getPartners, /getPartnersList: position partners + active demo partners
(copies the cached getAuthUserPartnerEmailMapping set, never mutates it)
- /impersonate: an active demo grant also passes the access check

Needs dao r37779 and migration_demo_partner_access.sql applied.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/LeadController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/UserController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoAuthUserController.java

Rev 37772 – fix(supplier): V2 supplier save derives state from GSTIN

amit — Thu, 24 Sep 2026 18:54:36 +0530

amit – 1 file(s) modified
fix(supplier): V2 supplier save derives state from GSTIN

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoSupplierController.java

Rev 37766 – feat(store-closure): V2 closeStore goes through StoreClosureService; access checks read StoreAccess ...

amit — Thu, 24 Sep 2026 17:22:07 +0530

amit – 1 file(s) modified
feat(store-closure): V2 closeStore goes through StoreClosureService; access checks read StoreAccess

Same rules as the fofo portal (dao r37764): reason, remark and approval mail required; mohit.gulati
removed from extend billing.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoRetailerController.java

Rev 37759 – LMS Call for App

vikas — Wed, 23 Sep 2026 19:32:08 +0530

vikas – 10 file(s) modified
LMS Call for App

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/lms
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/lms/LeadDispositionRequest.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/LeadRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/LeadRepositoryImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/lms/LmsCallService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/lms/LmsDispositionService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/lms/LmsOutcome.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/LmsDashboardService.java
+ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/LmsAppCallController.java
+ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2LmsAppCallController.java

Rev 37742 – v2: silence client disconnects and demote 4xx, matching the v1 ...

amit — Mon, 21 Sep 2026 16:51:49 +0530

amit – 1 file(s) modified
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.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/exception/V2GlobalExceptionHandler.java

Rev 37733 – Remove dead third-party integrations: web - PayU: /payu-pay and ...

amit — Mon, 21 Sep 2026 12:33:44 +0530

amit – 33 file(s) modified
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

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/config/WebMVCConfig.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/checkout/OrderController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/checkout/PayuHandler.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/checkout/PayuPayController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/checkout/PayuPayResponseController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/checkout/SmartPingReceiptModel.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/ClicksController.java
+ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/EmployeeAttendanceController.java (copied from /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/HyperTrackController.java@37732)
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/HyperTrackController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/HyperTrackService.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/LivePricingController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/LogisticsTrackingController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/ThriweController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/TicketChatActivityController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/payment
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/req/PayuPayResponsePojo.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/res/AddClickReponse.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/res/LivePricingResponse.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/res/order/PayuPayPojo.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/res/order/PayuResponseParams.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoFundFinaController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoSpiceMoneyController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoWebHookController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2ClicksController.java
+ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2EmployeeAttendanceController.java (copied from /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2HyperTrackController.java@37732)
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2HyperTrackController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2LivePricingController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2PayuPayController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2PayuPayResponseController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2TicketChatActivityController.java
~ /trunk/profitmandi-web/src/main/resources/META-INF/dev.properties
~ /trunk/profitmandi-web/src/main/resources/META-INF/payment-options.json
~ /trunk/profitmandi-web/src/main/resources/META-INF/prod.properties

Rev 37729 – lead: one workable lead per mobile, with a 6-month supersede ...

amit — Mon, 21 Sep 2026 12:31:43 +0530

amit – 13 file(s) modified
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.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/leadsync/LeadSyncRunner.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/CreateRefferalRequest.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/LeadRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/LeadRepositoryImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/lead
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/lead/LeadCreationService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/lead/LeadCreationServiceImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/lead/LeadDuplicateDecision.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/lead/LeadDuplicateNotifier.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/TrialServiceImpl.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/LeadController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/LeadController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoLeadController.java

Rev 37728 – logging: stop three non-defects reporting to the error board as ...

amit — Mon, 21 Sep 2026 12:18:41 +0530

amit – 10 file(s) modified
logging: stop three non-defects reporting to the error board as ERROR

log4j2.xml ships ERROR and above to GlitchTip, so the log level IS the filter.
Three sources of ordinary, expected behaviour were logging at ERROR and between
them accounted for 51,244 events -- 43% of the whole board -- none of them a bug.
GlobalExceptionHandler already logs ProfitMandiBusinessException at WARN and is
unchanged; every leak below bypassed it.

1. Session state (27,302 events, 23% of the board). CookiesProcessor and the two
interceptors logged a missing or expired cookie at ERROR. A logged-out or
anonymous visitor is the normal case -- the code already handles it by
redirecting to /login or returning 403 -- and each of these sits in a class
whose surrounding lines already log at DEBUG. These never reach the handler,
which is why its WARN-level treatment never applied. Now DEBUG.

2. Client disconnect (19,349 events). There was no handler for it, so a client
hanging up mid-response fell through to @ExceptionHandler(Exception.class) and
was recorded as an unhandled server bug. Adds an IOException handler to both
GlobalExceptionHandlers that logs a disconnect at DEBUG and everything else at
ERROR with its 500 intact.

⚠ ClientAbortException CANNOT be imported here: catalina is provided by the
container and is not on either module's compileClasspath (verified against
the configuration, not assumed). The match is therefore on the simple class
name plus the "broken pipe"/"connection reset" messages, walked down the cause
chain. A genuine IOException matches none of those and keeps its ERROR.

The handler returns null for a disconnect rather than a body: the connection
that would carry it is already closed, and writing to it is what raised the
exception. Null is the supported way to say "handled, no body" --
HttpEntityMethodProcessor marks the request handled before reading the value.

3. Business exceptions re-logged at ERROR (11 sites). Each catches a
ProfitMandiBusinessException, logs it, and CONTINUES with a fallback -- a
missing wallet history defaults to an empty list, a user not found by primary
email is retried against the secondary. That is an expected outcome being
reported as a failure, and logging it at ERROR pre-empted the handler that
would have logged it at WARN. Now WARN.

Selenium/WebDriver (58,776 events) is deliberately untouched: that is a genuinely
broken ChromeDriver, and muting it would hide Oppo/Realme IMEI activation failing.
It looks like noise only because one broken thing repeated 52,000 times.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/GlobalExceptionHandler.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/LoginController.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/WalletController.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/interceptor/AuthenticationInterceptor.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/interceptor/RoleInterceptor.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/util/CookiesProcessor.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/AddressController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/BrandController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/GlobalExceptionHandler.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoWalletController.java

Rev 37715 – SD credit: stop read paths writing utilized_limit - the SD ...

amit — Fri, 18 Sep 2026 05:07:16 +0530

amit – 5 file(s) modified
SD credit: stop read paths writing utilized_limit - the SD Credit admin page and V2 getLoans mutated managed SDCreditRequirement entities to show recomputed utilization, so Hibernate dirty-checking flushed an UPDATE per partner at commit; fofo now feeds the view from display maps and getLoans detaches before the display write, leaving output identical

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/SDCreditRequirementRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/SDCreditRequirementRepositoryImpl.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/SDCreditController.java
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/sd-credit-requirement-row.vm
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoSDCreditController.java

Rev 37706 – cart: take the cart row before any line, to break ...

amit — Fri, 18 Sep 2026 04:20:00 +0530

amit – 5 file(s) modified
cart: take the cart row before any line, to break a lock-ordering deadlock

InnoDB was rolling back cart edits with "Deadlock found when trying to get lock"
(GlitchTip #53, 27 deadlocks) and losing others to OptimisticLockException
"actual row count: 0; expected: 1" (11 issues, 42 events). Both are the same cause.

Two request paths took the same two rows in OPPOSITE orders. Adding a line INSERTs
into user.line, and line_cart_id_fk shared-locks the parent cart FIRST, line second.
Validation/hydration mutated the line rows FIRST and wrote cart.total_price second.
Run those concurrently on one cart and it is a cycle. Caught in the act on prod:

T1: INSERT user.line (cart_id=175180781) -> holds S on cart, waits S on line
T2: UPDATE user.cart SET total_price=269340.0, version=175 WHERE version=174
-> holds X on line, waits X on cart
*** WE ROLL BACK TRANSACTION (1)

Fix is to give every mutating path one order: cart, then lines. CartRepository gains
selectByIdForUpdate, and it is called as the first statement of each path that writes
a cart line. Re-taking it inside one request is a no-op.

A lock-ordering fix is all-or-nothing -- one path in the wrong order is enough to
re-form the cycle -- so this covers ALL TEN cart-line writers, not just the two that
happened to show up in the stack traces: createCartItem, clearCart, getCartValidation,
addItemsToCart (x2), addShoppingBag, validateForOpen (x2) and V2BillingController's
bind/unbindInsurance. The audit is worth re-running before adding another writer.

Note validateForOpen and getCartValidation WRITE despite their names (they correct
cart_line quantity/price and roll up cart.total_price), which is why a "validate" call
was ever holding write locks. The lock is placed accordingly; making those genuinely
read-only is a separate, larger change.

This also serialises concurrent edits to the SAME cart, which is what the @Version
column on Cart was already trying and failing to express. Different carts are
different rows, so there is no cost across partners.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/cart/CartServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/cart/v2/CartValidationServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/user/CartRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/user/CartRepositoryImpl.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2BillingController.java

Rev 37698 – V2 getPricing: carry internal movement availability alongside the price ...

amit — Thu, 17 Sep 2026 22:46:05 +0530

amit – 1 file(s) modified
V2 getPricing: carry internal movement availability alongside the price

Mirrors the fofo change so the two /getPricing endpoints answer alike. V2 is dormant but
component-scanned, so it has to keep compiling against the service signature.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoVendorController.java

Rev 37681 – feat(warehouse): resolve the logged-in user on V2 PO creation and ...

amit — Thu, 17 Sep 2026 16:29:18 +0530

amit – 2 file(s) modified
feat(warehouse): resolve the logged-in user on V2 PO creation and GRN mismatch resolution

V2 mirror of r37680, keeping the dormant V2 controllers in step with the fofo MVC ones.

- createPurchaseOrder resolves the logged-in user via getEmailId + authRepository and sets createdBy
- resolvedMismatchRequest passes the resolver through

Pairs with r37679.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoGrnController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoPurchaseOrderController.java

Rev 37676 – v2 version some fixes

ranu — Thu, 17 Sep 2026 15:19:50 +0530

ranu – 1 file(s) modified
v2 version some fixes

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/DealsController.java

Rev 37666 – Hot Deal brand: /fofo/hotDeals/brands accepts categoryId, so the brand chips ...

amit — Wed, 16 Sep 2026 18:56:36 +0530

amit – 1 file(s) modified
Hot Deal brand: /fofo/hotDeals/brands accepts categoryId, so the brand chips match the active tab

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/DealsController.java

Rev 37657 – Remove Mandii checkout, status and callback paths (r37655) OrderController: ...

amit — Wed, 16 Sep 2026 17:15:01 +0530

amit – 7 file(s) modified
Remove Mandii checkout, status and callback paths (r37655)

OrderController: the paymentOption MANDII branch and createMandiiOrder are
gone. GatewayController: the MANDII branch of payment/gateway/status is gone;
the SDDIRECT branch it sat in front of is untouched and still returns
AccountStatusResponseOut.

API endpoints removed, all of them Mandii-only:
- /cart/payment (CartController + its V2CartController delegate) existed
solely to poll Mandii for an order status and credit the wallet. It called
mandiiService unconditionally, so it already failed for any other gateway.
- /mandii, the payment-notification callback, a no-op logging stub in both
HdfcPaymentController and V2FofoHdfcPaymentController, and dropped from the
WebConfig auth whitelist in the fofo commit.

V2 twins touched only where they would otherwise keep a dead route alive or
fail to compile.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/CartController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/checkout/OrderController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/GatewayController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/SmartCartController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoHdfcPaymentController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoPartnerOnBoardingPanelController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2CartController.java

Rev 37649 – Retire user.counter / user.privatedealuser write path (web) createRetailer no ...

amit — Wed, 16 Sep 2026 09:28:13 +0530

amit – 1 file(s) modified
Retire user.counter / user.privatedealuser write path (web)

createRetailer no longer creates a Counter, PrivateDealUser or address mapping; the
non-found branch keeps only the saholic-user address write it also did. Pairs with
dao r37648.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/RetailerController.java

Rev 37641 – Hot Deal brand: badge from brand, /fofo/hotDeals/brands facet, real availability ...

amit — Tue, 15 Sep 2026 17:39:28 +0530

amit – 3 file(s) modified
Hot Deal brand: badge from brand, /fofo/hotDeals/brands facet, real availability on every listing, drop legacy hot-deals pause endpoints

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/DealsController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/services/HotDealEnrichmentService.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoIndentController.java

Rev 37635 – feat(pricing): V2 log tag_listing price changes; reference TP instead of ...

amit — Tue, 15 Sep 2026 17:23:03 +0530

amit – 3 file(s) modified
feat(pricing): V2 log tag_listing price changes; reference TP instead of vendoritempricing in price drop and tag listing

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoOrderManagementController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoPriceDropController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoTagListingController.java

Rev 37633 – preffered app version revert on server side it will ...

ranu — Tue, 15 Sep 2026 17:14:31 +0530

ranu – 2 file(s) modified
preffered app version revert on server side it will be client side

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/dtr/User.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2UserController.java

Rev 37632 – fix(loi): don't leave an LOI half signed when the signed ...

aman — Tue, 15 Sep 2026 14:15:39 +0530

aman – 8 file(s) modified
fix(loi): don't leave an LOI half signed when the signed PDF fails to save

Confirm Sign stores the partner OTP (/validateLoiOtp) before the browser builds and uploads the
signed PDF (/saveLoiDoc). When that second step failed - html2pdf not loaded from cdnjs, upload
rejected, tab closed, server error - nothing was shown, no LOI mail went out, no onboarding was
created, and because loiOtpPresent hid Generate LOI the filler could never re-sign (LOI 734).

- pendingFormList: loiOtpPresent only when OTP AND loiDoc are both saved; new loiSignIncomplete
flag shows a red "signed LOI not saved" note on the Pending LOI list (web + V2 app).
- loi-form.js Confirm Sign: every failure after the OTP says the LOI was NOT saved and how to
retry; checks html2pdf is loaded; success alert only after /saveLoiDoc confirms; no double submit.
- /saveLoiDoc (fofo + V2): refuses a document without a verified OTP; a repeat call for an
already saved LOI is a no-op (no second mail / completion).
- /validateLoiOtp (fofo + V2): clear message when no OTP was sent in 24h; reports the real
rejection reason (e.g. OTP already used) instead of always "wrong".
- sendSignedLoiPdfToPartner: filler without a manager no longer throws and rolls back the save.
- OtpProcessor.generateOtp: never hands back an already verified OTP under the 2-minute throttle.
- AppConfig version 423 for loi-form.js.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RhJD2sc6pf3Zd7f4hyGxhH

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/LoiFormModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/loiForm/LoiFormServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/OtpProcessor.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/LoiFormController.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/loi-form.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/pendingForm.vm
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoLoiFormController.java

Rev 37629 – feat(mail): wire inactive-recipient filter and clean hardcoded addresses Wire ...

amit — Tue, 15 Sep 2026 13:16:01 +0530

amit – 16 file(s) modified
feat(mail): wire inactive-recipient filter and clean hardcoded addresses

Wire MailRecipientFilter into googleMailSender and gmailRelaySender. Remove inactive/unknown addresses from recipient and access lists, fix typo addresses, bulk uploader gate to akhil.kumar, V2 brand fee gate to kamini.sharma.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/CartController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/checkout/OrderController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/ContactUsController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/LeadController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/StoreController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/UserController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoDashboardController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoLeadController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoLoiFormController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoMonitorController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoRefferalController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoRetailerController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoServiceConfigController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoWalletController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoWebListingController.java

Rev 37624 – feat(price-drop): auto-approve V2 price drop DP/MOP into external vendor catalog ...

amit — Mon, 14 Sep 2026 17:10:47 +0530

amit – 1 file(s) modified
feat(price-drop): auto-approve V2 price drop DP/MOP into external vendor catalog pricing

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoPriceDropController.java

Rev 37621 – V2 /entity honours activeOnly, defaulting to false Same defect ...

amit — Mon, 14 Sep 2026 17:09:03 +0530

amit – 1 file(s) modified
V2 /entity honours activeOnly, defaulting to false

Same defect as the fofo endpoint fixed in profitmandi-fofo r37620: the flag was
accepted and ignored. Defaulting to false keeps callers that omit it unchanged.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoContentController.java

Rev 37605 – Use the derived movement price in the v2 vendor controller ...

amit — Sat, 12 Sep 2026 17:01:11 +0530

amit – 1 file(s) modified
Use the derived movement price in the v2 vendor controller too

Same change as the fofo controller: /getPricing returns the movement price for internal
suppliers, and addVendorPricingIfMissing is gone. This copy is component-scanned, so
leaving it behind would have kept writing the pricing rows the fofo side stopped writing.

Requires profitmandi-dao r37603.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoVendorController.java

Rev 37591 – Route V2 admin wallet adjustment through WalletServiceImpl Byte-identical duplicate ...

amit — Fri, 11 Sep 2026 17:30:13 +0530

amit – 1 file(s) modified
Route V2 admin wallet adjustment through WalletServiceImpl

Byte-identical duplicate of the fofo /walletUpdate handler, with the same missing
row lock. Points at the shared walletService.applyManualAdjustment so both
modules share one code path.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoWalletController.java

Rev 37548 – v2 version some fixes

ranu — Wed, 09 Sep 2026 12:01:03 +0530

ranu – 2 file(s) modified
v2 version some fixes

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/dtr/User.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2UserController.java

Rev 37547 – v2 switch version fixes on server side

ranu — Wed, 09 Sep 2026 11:58:50 +0530

ranu – 1 file(s) modified
v2 switch version fixes on server side

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/NotificationController.java

Rev 37490 – errors: separate business, integration and bug -- three failures logged ...

amit — Tue, 01 Sep 2026 12:20:10 +0530

amit – 3 file(s) modified
errors: separate business, integration and bug -- three failures logged three ways

Everything was logged identically: ERROR, titled 'Internal Server Error', and in
web stack-traced twice (log4j2 plus printStackTrace, the second copy landing in
catalina.out). A partner mistyping an IMEI produced the same output as a
NullPointerException.

That makes the error stream unalertable. Measured over six hours across web and
fofo: 909 ERROR lines, of which 294 (32%) were ProfitMandiBusinessException --
HTTP 400s where the user is simply told what to fix. Any rule on ERROR rate
fires constantly, and an error tracker would rank 'insufficient balance' as the
top issue.

business WARN, no stack trace, 4xx -- expected, user-correctable
integration ERROR + dependency name -- ours is fine, theirs is not
anything else ERROR + stack trace, 500 -- a bug

New IntegrationException carries getDependency(), so two hundred failures of one
gateway group as one problem rather than two hundred unrelated traces. That
category did not exist: such failures were previously either a bare Exception
(indistinguishable from our own bug) or a business exception (which wrongly
blames the user).

printStackTrace removed from the web handler -- it was writing a second copy of
every trace to catalina.out.

Prerequisite for wiring the GlitchTip appender, which must not be attached until
ERROR means something.

+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/exception/IntegrationException.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/GlobalExceptionHandler.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/GlobalExceptionHandler.java

Rev 37480 – mail: correct a wrong claim in r37479 -- the Google ...

amit — Mon, 31 Aug 2026 17:55:16 +0530

amit – 3 file(s) modified
mail: correct a wrong claim in r37479 -- the Google app password IS valid

r37479 stated googleMailSender's app password was rejected. That was wrong. The
test behind it resolved smtp.gmail.com over IPv6; repeating it over IPv4 with
the same credential gives AUTH OK on both 465 and 587.

The real fault is not the credential and not the bean config, both of which are
correct. SMTP from this host works over IPv4 only:

smtp.gmail.com IPv4 -> AUTH OK IPv6 -> 535 5.7.8 Username and Password not accepted
smtp-relay IPv4 -> 250 MAIL FROM IPv6 -> 550 5.7.1 Invalid credentials for relay

The JVM prefers IPv4, which is the only reason mail leaves this box at all.
Anything that prefers IPv6 fails on both paths.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/config/AppConfig.java

Rev 37479 – mail: make the relay the default sender, not the Google ...

amit — Mon, 31 Aug 2026 17:49:38 +0530

amit – 3 file(s) modified
mail: make the relay the default sender, not the Google identity

Correcting r37474-37476. Those made googleMailSender @Primary on the assumption
its credentials worked. Tested against the live servers from the prod host:

googleMailSender 535 5.7.8 Username and Password not accepted (BadCredentials)
-- the app password in the source is no longer valid
relay over IPv4 250 OK for MAIL FROM:<noreply@smartdukaan.com>
relay over IPv6 550 5.7.1 Invalid credentials for relay

So promoting google would have replaced one broken default with another. The
relay is what actually delivers today and it becomes 'mailSender'. It does not
authenticate -- Workspace authorises it by allowlisted source IP -- so sending
as noreply@ is legitimate there and AuthenticatedIdentityMailSender correctly
leaves it alone.

googleMailSender stays available by qualifier. Point the default back at it once
a valid app password is issued for sdtech@smartdukaan.com.

Also noted in the javadoc: the relay allowlist covers the IPv4 address only, so
anything that prefers IPv6 will be refused.

Rev 37475 – mail: delete the dead SendGrid bean from web, make the ...

amit — Mon, 31 Aug 2026 17:11:39 +0530

amit – 1 file(s) modified
mail: delete the dead SendGrid bean from web, make the authenticated identity primary

Removes the live SendGrid bean plus two commented-out corpses (an old
build@shop2020.in sender and a dead alias). googleMailSender is now @Primary and
answers to 'mailSender', so unqualified injections get the working authenticated
sender instead of one that rejects with 535.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/config/AppConfig.java

Rev 37454 – Build googleMailSender as AuthenticatedIdentityMailSender The bean authenticates as sdtech@smartdukaan.com, ...

amit — Sat, 29 Aug 2026 07:24:40 +0530

amit – 1 file(s) modified
Build googleMailSender as AuthenticatedIdentityMailSender

The bean authenticates as sdtech@smartdukaan.com, so Google Workspace only permits
that address in From. Callers hardcode noreply@, which Gmail refuses with 535
'Authenticated user is not authorized to send mail', silently dropping every alert
sent through it. The sender now rewrites From to its own username at send time.

See profitmandi-common r37451.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/config/AppConfig.java

Rev 37415 – Whatsapp Apis

vikas — Wed, 26 Aug 2026 13:46:51 +0530

vikas – 14 file(s) modified
Whatsapp Apis

x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/dtr/Optin.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/OptinRepository.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/OptinRepositoryImpl.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/CpassWhatsappService.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/GupshupWhatsappService.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappListRow.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappListSection.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappProvider.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappProviderResolver.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappReplyButton.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappTemplateSender.java
x /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/whatsapp/WhatsappProviderResolverTest.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/CpassTestController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/CpassWebhookController.java

Rev 37412 – Whatsapp Apis

vikas — Wed, 26 Aug 2026 13:16:24 +0530

vikas – 6 file(s) modified
Whatsapp Apis

Rev 37411 – v2 version some fixes

ranu — Wed, 26 Aug 2026 13:13:33 +0530

ranu – 1 file(s) modified
v2 version some fixes

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2InsuranceController.java

Rev 37404 – Serve the canonical state list from inventory.statemaster Add GET ...

amit — Tue, 25 Aug 2026 22:59:47 +0530

amit – 1 file(s) modified
Serve the canonical state list from inventory.statemaster

Add GET /master-data/states returning each state's name and GST state code.

Clients were each carrying their own hardcoded state list, which drifted from the
master. Anything we store is later resolved back through that master by name, so a
drifted list writes values nothing can resolve - which is how customer addresses
ended up with states like 'Daman & Diu' that the master no longer holds, leaving
those invoices unable to generate. Serving the list means a correction to the
master reaches every client without a release.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/MasterDataController.java

Rev 37399 – Use the shared insurance invoice line builder for standalone policy ...

amit — Tue, 25 Aug 2026 20:30:12 +0530

amit – 1 file(s) modified
Use the shared insurance invoice line builder for standalone policy invoices

Replace the duplicated CustomInsurancePolicy block with InsuranceInvoiceLine.
Drop the setTotalAmount call - the renderer derives totals from the item lines,
so the value was never read - and the repository field it orphaned.

Derive and set the invoice state codes, as the partner invoice already does, so
the place of supply prints when billing a registered buyer.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/InsuranceController.java