| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37783 |
15 d 17 h |
vikas |
/trunk/profitmandi-fofo/src/main/ |
Corrected LMS Data |
|
| 37780 |
15 d 19 h |
amit |
/trunk/profitmandi-fofo/src/ |
feat(partner-access): demo partner access page + validation
- Demo Partner Access page (Admin Control): grant partners to a Sales person,
list and revoke active grants; server-guarded by canManage
- Partner access dropdown: position partners + active demo partners "(Demo)";
shared cached mapping is copied, never mutated
- /login-as-partner-readonly: partner must be in caller's positions or demo
grants (was unchecked; Partner access is its only caller)
- /mobileapp?emailId=: Sales position holders get the partner app token only
for position/demo partners; other admins (Partner Info) unchanged
- DemoPartnerAccessTest (5, local DB, rolled back)
- jsVersion 437
Needs dao r37779 and migration_demo_partner_access.sql applied. |
|
| 37777 |
16 d 12 h |
amit |
/trunk/profitmandi-fofo/src/ |
returns: finance endpoint to reverse a return whose goods never reached the warehouse
PUT /return/reverse?imei=&reason=&dryRun= calls ReturnReversalService (r37776) for one
IMEI. Finance only, same canRefund gate as the refund it undoes, and dryRun defaults to
true so a call without it reports the plan and writes nothing.
ReturnReversalTest covers the four cases against the local database with NIC on the
sandbox: the dry run writes nothing, a note past its 24h window issues a DBN and undoes
every effect of the refund (warehouse scan and stock, partner stock and offers, order
status, wallet, return item, debit note, audit row), a note inside the window has its IRN
cancelled and drops out of the statement, and bad input or a second reversal is refused.
Run it as `gradle :test --tests ...` - without the colon the filter also reaches
profitmandi-common and fails with "No tests found". |
|
| 37775 |
16 d 13 h |
ranu |
/trunk/ |
aging po approval process |
|
| 37773 |
16 d 13 h |
amit |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ |
fix: show live partner investment on sanction request approval screens
Total/short investment on /getSanctionRequest, /getRbmL2SanctionRequest and the
row re-render after submit now read the 2-minute partner_investment snapshot via
PartnerInvestmentService instead of yesterday's partner_daily_investment row. |
|
| 37770 |
16 d 13 h |
amit |
/trunk/profitmandi-fofo/src/main/ |
fix(movement): GRN of a movement invoice validated against its own PO + billed IMEIs; Reopen removed; PO list shows Created By; supplier state from GSTIN; jsVersion 436 |
|
| 37765 |
16 d 15 h |
amit |
/trunk/profitmandi-fofo/src/main/ |
feat(store-closure): closure popup with reason, remark and approval mail upload
- Close Store (inactive stores page and deactivate flow) opens one shared popup; /closeStore
delegates to StoreClosureService (dao r37764)
- store status access checks read StoreAccess lists; mohit.gulati removed from extend billing
- jsVersion 435 |
|
| 37761 |
16 d 19 h |
ranu |
/trunk/ |
aging po approval process |
|
| 37760 |
17 d 13 h |
vikas |
/trunk/profitmandi-fofo/src/main/ |
Upload directory and Data correction for lead |
|
| 37750 |
17 d 13 h |
ranu |
/trunk/ |
aging sku purchasing need to approval of niranjan kala sir |
|
| 37749 |
17 d 14 h |
vikas |
/trunk/ |
Upload directory and Data correction for lead |
|
| 37748 |
17 d 16 h |
ranu |
/trunk/profitmandi-fofo/src/main/ |
today po rbm view showing only for l7 and above |
|
| 37747 |
17 d 17 h |
ranu |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/monitors/ |
today po rbm view showing only for l7 and above |
|
| 37746 |
17 d 17 h |
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 |
17 d 17 h |
ranu |
/trunk/profitmandi-fofo/src/main/ |
today po rbm view showing only for l7 and above |
|
| 37743 |
19 d 14 h |
vikas |
/trunk/ |
LMS checklist for call |
|
| 37737 |
19 d 19 h |
vikas |
/trunk/ |
LMS checklist for call |
|
| 37734 |
19 d 20 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 |
|
| 37729 |
19 d 20 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. |
|
| 37728 |
19 d 20 h |
amit |
/trunk/ |
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. |
|