SmartDukaan – /

Rev 37513 – notification live

ranu — Tue, 01 Sep 2026 18:46:42 +0530

ranu – 7 file(s) modified
notification live

+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/model/NotificationTargetCriteria.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/dtr/NotificationSchedule.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/NotificationScheduleRepository.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/NotificationScheduleRepositoryImpl.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
+ /trunk/profitmandi-fofo/src/main/webapp/resources/js/notification-calendar.js
+ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/notification-calendar.vm

Rev 37512 – notification live

ranu — Tue, 01 Sep 2026 18:41:08 +0530

ranu – 1 file(s) modified
notification live

+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/model/LinkedEntity.java

Rev 37511 – notification live

ranu — Tue, 01 Sep 2026 18:40:18 +0530

ranu – 1 file(s) modified
notification live

+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/enumuration/NotificationFormat.java

Rev 37510 – sales target and achievement added cron and flags

ranu — Tue, 01 Sep 2026 18:39:11 +0530

ranu – 1 file(s) modified
sales target and achievement added cron and flags

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java

Rev 37509 – rbm drr dashboard , all today po rbm view maped

ranu — Tue, 01 Sep 2026 18:38:33 +0530

ranu – 1 file(s) modified
rbm drr dashboard , all today po rbm view maped

+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/enumuration/NotificationCategory.java

Rev 37508 – notification live new ....api and modification , ui

ranu — Tue, 01 Sep 2026 18:12:41 +0530

ranu – 11 file(s) modified
notification live new ....api and modification , ui

~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/model/Notification.java
~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/model/SendNotificationModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/dtr/NotificationCampaign.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/SimpleCampaignParams.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/NotificationCampaignRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/NotificationCampaignRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/NotificationService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/NotificationServiceImpl.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/NotificationController.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/send-notification.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/send-notification.vm

Rev 37507 – rbm drr dashboard , all today po rbm view maped

ranu — Tue, 01 Sep 2026 18:11:31 +0530

ranu – 1 file(s) modified
rbm drr dashboard , all today po rbm view maped

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/SalesHierarchyMonthlyTargetModel.java

Rev 37506 – rbm drr dashboard , all today po rbm view maped

ranu — Tue, 01 Sep 2026 18:10:56 +0530

ranu – 1 file(s) modified
rbm drr dashboard , all today po rbm view maped

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/SalesHierarchyAchievedByMovementModel.java

Rev 37505 – rbm drr dashboard , all today po rbm view maped

ranu — Tue, 01 Sep 2026 17:49:23 +0530

ranu – 3 file(s) modified
rbm drr dashboard , all today po rbm view maped

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/RbmTargetService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/RbmTargetServiceImpl.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/monitors/RbmDrrDashboardController.java

Rev 37504 – Stop invoice read paths creating directories (AccessDeniedException 500s) getInvoicePath ...

amit — Tue, 01 Sep 2026 16:59:34 +0530

amit – 1 file(s) modified
Stop invoice read paths creating directories (AccessDeniedException 500s)

getInvoicePath called Files.createDirectories, and getInvoiceFile called it on every
download. Invoices are generated by the cron app as root, so /SaholicInvoices/<month>
is 755 root-owned; a download served by Tomcat cannot create a retailer subdirectory
and threw AccessDeniedException.

It threw on line 1 of getInvoiceFile, before the Files.exists check, so the
ProfitMandiBusinessException on the next line was unreachable and the callers'
deliberate 404 handler ("Invoice not yet generated, please retry shortly") never ran.
Downloads for a not-yet-generated invoice 500ed instead of 404ing - the exact log
noise that handler was added to remove.

Split the path computation out: resolveInvoicePath is side-effect free and used by
getInvoiceFile; getInvoicePath keeps the mkdir for the two generation callers
(InvoiceService:558, GstProService:952). The legacy relocation branch creates the
target directory only when there is actually a file to move.

No ops change needed - generation as root already works.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/invoicing/InvoiceService.java

Rev 37503 – sales target and achievement added cron and flags

ranu — Tue, 01 Sep 2026 16:35:38 +0530

ranu – 1 file(s) modified
sales target and achievement added cron and flags

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java

Rev 37502 – sales target and achievement added cron and flags

ranu — Tue, 01 Sep 2026 16:32:50 +0530

ranu – 1 file(s) modified
sales target and achievement added cron and flags

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/icicilombard/model/LastTransactionsResponseModel.java

Rev 37501 – sales target and achievement added cron and flags

ranu — Tue, 01 Sep 2026 16:26:05 +0530

ranu – 1 file(s) modified
sales target and achievement added cron and flags

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/icicilombard/model/LastTransactionsRequestModel.java

Rev 37500 – sales target and achievement added cron and flags

ranu — Tue, 01 Sep 2026 16:19:27 +0530

ranu – 3 file(s) modified
sales target and achievement added cron and flags

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/inventory/SalesAchievements.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/catalog/SalesAchievementsRepository.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/catalog/SalesAchievementsRepositoryImpl.java

Rev 37499 – sales target and achievement added cron and flags

ranu — Tue, 01 Sep 2026 16:09:28 +0530

ranu – 7 file(s) modified
sales target and achievement added cron and flags

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledSkeleton.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledTasks.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/inventory/SalesTargets.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/catalog/SalesTargetsRepository.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/catalog/SalesTargetsRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/icicilombard/IciciLombardService.java

Rev 37498 – Fix: namespace document-level handlers in remaining vm fragments Completes ...

amit — Tue, 01 Sep 2026 15:55:04 +0530

amit – 35 file(s) modified
Fix: namespace document-level handlers in remaining vm fragments

Completes the sweep started in r37493/r37494. These fragments are injected
with .html(), which re-executes their inline <script>, so every load stacked
another $(document) delegated handler. Mutating handlers then fired N
identical requests and were rejected as duplicates; read-only ones silently
fired N GETs (never deduped, so no alert - just N times the load).

35 fragments, 70 bindings. Adopts the create-purchase-return.vm convention:
one $(document).off('.ns') before the first binding, every event namespaced,
so only the newest binding survives a re-injection.

Notes:
- ticket.vm binds via jQuery(document).on, which the earlier passes did not
match, and its clear must sit OUTSIDE ready() - that callback fires async,
so an inside-ready clear would wipe the top-level binds registered before it.
- agreement-esign-panel, full-stock-payment-panel and create-purchase-return
were left alone; they already clear their handlers (selector-targeted
.off('click', sel) and .off('.createpr') respectively).

Behaviour-preserving: every diff line is either a namespace suffix on an
event string or a new off() call. Selectors, handlers and ordering untouched.
Verified no unprotected document-level bindings remain in any fragment.

~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/activation-tabular.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/add-wallet-rejected.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/add-wallet-req.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/add-wallet-request.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/auth_user_partner_detail.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/beat-plan-deferred.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/beat-report-data.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/beat-report-user-detail.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/bulk-order.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/bulletin-list.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/catalog.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/dashboard-modal.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/design-completed.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/finance-services.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/lead-geo-review.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/lead.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/loi-form.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/managerTicket.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/my-partner-tickets.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/onboarding_timeline.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/order-index.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/partner-onboarding-design-index.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/partner-onboarding-index.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/partner-onboarding-open.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/partner-onboarding-reject.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/partner-readonly-info.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/post-bulletin.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/price-drop-tabular.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/returnables.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/ticket.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/update_PartnerCriteria.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/upgrade-offer-tabular.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/visit-approvals.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/wallet-details.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/warehouse-grn-correction-detail.vm

Rev 37497 – rbm drr dashboard , all today po rbm view maped

ranu — Tue, 01 Sep 2026 15:51:22 +0530

ranu – 4 file(s) modified
rbm drr dashboard , all today po rbm view maped

Rev 37496 – Handle empty IN collections instead of failing the query ...

amit — Tue, 01 Sep 2026 15:42:57 +0530

amit – 1 file(s) modified
Handle empty IN collections instead of failing the query

An empty IN list rendered as "in ()" (invalid SQL) or threw, in three inconsistent ways:
SQLGrammarException from prepareInPredicate, RuntimeException from prepareEqualPredicate,
and ProfitMandiBusinessException from selectAllByInOrderByDesc. A partner with no activity
for a brand legitimately produces an empty set, so these were 500ing on valid input
(~436 errors/week, mostly V2FofoSchemeController.getBrandWiseIncome).

An empty IN matches nothing: route every IN site through inPredicateOrNone, which returns
an empty disjunction. Empty NOT IN excludes nothing, so it matches everything (conjunction).
selectAllByInOrderByDesc returns an empty list without a DB round-trip.

Also covers three sites that had no guard at all: selectAllByInEqualOrderBysDesc,
selectCountByIn and mapToPredicate. Public API unchanged.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/GenericRepositoryImpl.java

Rev 37495 – Fix Pine Labs affordability prod config: drop placeholder pinelabs.api.* overrides ...

amit — Tue, 01 Sep 2026 15:42:49 +0530

amit – 1 file(s) modified
Fix Pine Labs affordability prod config: drop placeholder pinelabs.api.* overrides

r36839 re-added pinelabs.api.base.url/client.id/client.secret to the web module with
REPLACE_WITH_* values, reintroducing the duplication removed in r35832. AppConfig loads
shared-prod first and the module file second, so these shadowed the real credentials and
every affordability call failed with UnknownHostException on plural.v2.pinepg.in
(NXDOMAIN) - 1,254 errors in one week. Removing them restores the working values from
shared-prod.properties (api.pluralpay.in).

pinelabs.account.* deliberately left in place: the web module pins merchant 11467 while
shared-prod has 356460, so removing those would switch the live payment merchant.

~ /trunk/profitmandi-web/src/main/resources/META-INF/prod.properties

Rev 37494 – Fix: namespace document-level handlers in re-injected vm fragments Same ...

amit — Tue, 01 Sep 2026 15:35:52 +0530

amit – 5 file(s) modified
Fix: namespace document-level handlers in re-injected vm fragments

Same defect class as r37493. These fragments are injected with .html(),
which re-executes their inline <script>, so every load stacked another
$(document) delegated handler. One click then fired N identical requests;
PostInterceptor claimed the first and rejected the rest as duplicates.

Confirmed in prod today: beat-plan-day-view #avSubmit produced bursts of
3-4 rejections on POST /beatPlan/assignVisit/submit. The other four are the
same shape - chart-filter-lms, franchisee-account-creation and beat-plan-bulk
re-inject themselves directly, placement-plan-details does so indirectly by
clicking .search-partner-stock after createPo.

Adopt the create-purchase-return.vm convention: one $(document).off('.ns')
before the first binding, every event namespaced. Only the newest binding
survives, which also fixes handlers holding a stale Velocity closure from a
previously rendered record.

Behaviour-preserving: the only changes are the namespace suffix on 22 event
strings plus the five off() calls. Selectors, handlers and ordering untouched.

Read-only self-injecting fragments (activation-tabular, catalog,
partner-onboarding-*, etc) still stack handlers but only fire GETs, which are
never deduped - left for a separate pass.

~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/beat-plan-bulk.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/beat-plan-day-view.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/chart-filter-lms.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/franchisee-account-creation.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/placement-plan-details.vm

Rev 37493 – Fix: scheme item inline date edit fired N duplicate PUTs ...

amit — Tue, 01 Sep 2026 12:56:08 +0530

amit – 3 file(s) modified
Fix: scheme item inline date edit fired N duplicate PUTs per click

scheme-details.vm is injected with .html(), which re-executes its inline
<script>, and a successful save re-injects it - so each load stacked another
$(document) handler for .edit/.cancel/.save-item-dates. One Save click then
fired N identical PUT /scheme/item/window, and PostInterceptor rejected all
but the first with 'Duplicate request.' (27 per click in prod today).
The stacked copies also carried a stale $scheme closure, so a save could
repaint the container with a previously viewed scheme.

Move the handlers to scheme.js (loaded once via include-scripts.vm) and read
the scheme id/window from data- attributes on the fragment root, keeping them
stateless. Fragment is now markup only.

Reuse cleanup while in here:
- configureMultiselect() replaces 3 near-identical multiselect configs
- loadBrandsByCategory/loadCatalogDescriptionByBrands take an optional
afterRender so the add-item modal reuses them instead of duplicating both
- toggleItemDateEdit()/initSingleDatePicker() collapse mirrored blocks
- SCHEME_DETAILS_CONTAINER single-sources the container id
- drop the template's duplicate toIsoDateTime (scheme.js already had it)
- updateSchemeItemWindow() now prefixes context like every other call

Bump jsVersion 409 -> 410.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/scheme.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/scheme-details.vm

Rev 37492 – errors: wire the GlitchTip appender into cron and fofo logging ...

amit — Tue, 01 Sep 2026 12:37:42 +0530

amit – 2 file(s) modified
errors: wire the GlitchTip appender into cron and fofo logging

Completes r37491, which committed only web's log4j2.xml. cron's and fofo's were
held back because they carried local development log paths -- a user.home
expansion in cron and an absolute /Users path in fofo. Neither can ship: /Users
does not exist on the server, so fofo logging would fail to open its file and
the Alloy stream tailing /var/log/tomcat7/fofo/fofo.log would go dead.

Both files are restored to their production paths and carry the Sentry appender.
Whoever needs the local override should re-apply it locally rather than
committing it.

~ /trunk/profitmandi-cron/src/main/resources/log4j2.xml
~ /trunk/profitmandi-fofo/src/main/resources/log4j2.xml

Rev 37491 – errors: ship ERROR events to GlitchTip via the log4j2 Sentry ...

amit — Tue, 01 Sep 2026 12:23:38 +0530

amit – 4 file(s) modified
errors: ship ERROR events to GlitchTip via the log4j2 Sentry appender

io.sentry:sentry-log4j2:7.22.6 in all three deployables. Pinned to 7.x because
8.x drops Java 8; verified class major version 52.

minimumEventLevel=ERROR is load-bearing. It only became safe after r37490 moved
business validations to WARN -- 32% of the ERROR stream was HTTP 400s where the
user is simply told what to fix, and sending those would have made "insufficient
balance" the top issue and buried real bugs. Breadcrumbs come from INFO so an
issue arrives with the log lines that preceded it.

Attached to the application loggers only; framework noise is not our bug.

web's log4j2.xml is committed here. cron's and fofo's are held back: both carry
uncommitted local development paths (a user.home expansion, and an absolute
/Users path) that would break production logging and the Alloy log tailing.
Their Sentry blocks are staged locally and should land with whoever owns those
path edits.

~ /trunk/profitmandi-cron/build.gradle
~ /trunk/profitmandi-fofo/build.gradle
~ /trunk/profitmandi-web/build.gradle
~ /trunk/profitmandi-web/src/main/resources/log4j2.xml

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 37489 – Restore Utils.html and Utils.htmlJson removed by r37477 r37477 reorganised ...

amit — Mon, 31 Aug 2026 19:34:41 +0530

amit – 1 file(s) modified
Restore Utils.html and Utils.htmlJson removed by r37477

r37477 reorganised Utils while consolidating the mail APIs and dropped its only two
instance methods. They have no Java callers -- they exist solely for Velocity, where
AppConfig binds new Utils() as $vmUtils -- so the compiler, IDE find-usages and any
grep over *.java all reported them dead.

With htmlJson gone, data-paramslist="$vmUtils.htmlJson(...)" stopped rendering usable
JSON on every report link (admin.vm:840, admin.vm:910, reports.vm:51). reports.js:7
then read $(this).data("paramslist") as undefined and returned true, letting the
browser follow the plain <a href> natively -- a GET against the @PostMapping
/reports/{projectName}/{fileName} (ReportsController:126), answered with GE_1007
"Request method 'GET' not supported". The modal POST path was the only way that
endpoint was ever reachable, so every partner report broke at once.

Confirmed against prod: zero occurrences in fofo.log for Aug 13/20/26/28/30, and 87
today starting 18:37:23, right after today's ROOT.war deploy. 13 distinct reports hit.

$vmUtils.html had two further callers that also come back:
offer_margin_detail_partner.vm:12 and :241 (offer description and notes).

Restored verbatim from r37476, and commented as template-only so the next refactor
does not read them as dead code again.

~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/util/Utils.java

Rev 37488 – rbm drr dashboard , all today po rbm view maped

ranu — Mon, 31 Aug 2026 18:50:22 +0530

ranu – 1 file(s) modified
rbm drr dashboard , all today po rbm view maped

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/WarehouseBuyingByMovementModel.java

Rev 37487 – rbm drr dashboard , all today po rbm view maped

ranu — Mon, 31 Aug 2026 18:49:06 +0530

ranu – 4 file(s) modified
rbm drr dashboard , all today po rbm view maped

Rev 37486 – mail: fix prod outage -- MailOutboxService must not implement MailQueue ...

amit — Mon, 31 Aug 2026 18:32:25 +0530

amit – 2 file(s) modified
mail: fix prod outage -- MailOutboxService must not implement MailQueue

r37478 added 'implements MailQueue' to MailOutboxService. That took down both
ROOT.war and profitmandi-web.war on the 18:19 deploy today; every route 404'd
because neither Spring context would start.

MailOutboxService has @Transactional methods, so Spring has to proxy it, and
@EnableTransactionManagement in both WebDBContextConfigure classes runs with the
default proxyTargetClass=false. While the class implemented no interface Spring
proxied it with a CGLIB subclass, which is still a MailOutboxService. Adding an
interface switched it to a JDK proxy implementing only MailQueue, so all 39
sites that inject the concrete MailOutboxService failed:

BeanNotOfRequiredTypeException: Bean named 'mailOutboxService' is expected to
be of type MailOutboxService but was actually of type com.sun.proxy.$Proxy1519

The interface moves to a new MailQueueAdapter, which delegates to
MailOutboxService and carries no transactional annotations. MailQueueHolder and
EmailServiceImpl inject it by the MailQueue interface, so Utils.sendMail* and
EmailService still reach the outbox unchanged. MailOutboxService goes back to
implementing nothing, and its ~112 existing call sites are untouched.

Chose this over proxyTargetClass=true, which would have flipped proxying for
every interface-implementing service in the app -- too broad for a hot fix.

Verified with javap inside both built WARs: MailOutboxService declares no
interfaces, MailQueueAdapter implements MailQueue.

Note for cron: it shares the dao jar, so a rebuild picks this up. Do not restart
cron on trunk without rebuilding it first.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/mail/MailOutboxService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/mail/MailQueueAdapter.java

Rev 37485 – carlcare: enable tecno alongside itel Itel went first because ...

amit — Mon, 31 Aug 2026 18:17:30 +0530

amit – 1 file(s) modified
carlcare: enable tecno alongside itel

Itel went first because it is the brand we can CHECK -- the DCR pull independently
produces itel dates to reconcile against, where tecno has no second source at all.
That check has passed:

- a 50-imei read-only trial answered 50/50, no errors, no sign rejections, and
agreed with our catalog brand on all 50
- 18 of the 50 carried a date, and every one of those 18 fell AFTER our own
billing date (3 to 1,111 days, median ~220)
- the first live tick after deploy returned the same rate: 16 dates, 32 not-yet-
activated, 1 malformed response absorbed by the has("status") guard

Tecno is also the reason this class exists. Itel was already served by the DCR pull;
tecno has been served by nothing since 2024-11-20 and has been manual CSV ever since.

Capacity: ~10,400 itel + ~1,890 tecno pending against 14,400 lookups a day. The
round-robin splits a tick four ways only while all four queues have work; tecno is
much the smaller pool, so it is exhausted a few hours in, its queues then come back
empty and itel gets the full 50 again for the rest of the day. Itel still clears
daily -- roughly 1,875 + 10,650 = 12,525 itel lookups against a 10,401 pool.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/CarlcareImeiActivationService.java

Rev 37484 – cron metrics: register the status gauge as -1, not 0 ...

amit — Mon, 31 Aug 2026 18:17:00 +0530

amit – 1 file(s) modified
cron metrics: register the status gauge as -1, not 0

The gauge was created when a job STARTS, and 0 means failure, so any job still
running its first execution after a restart reported FAILED. Selenium-driven and
report jobs take minutes, so this is not a narrow window -- it put ten jobs on
the dashboard as failed after the 2026-08-31 restart when none had failed.

-1 means 'has not finished a run yet'. CronJobFailing matches == 0, so those
jobs are simply absent from the alert until they genuinely complete once.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/monitored/CronJobMonitorAspect.java

Rev 37483 – mail: migrate mail_outbox SENDGRID rows to RELAY (applied to production) ...

amit — Mon, 31 Aug 2026 18:11:23 +0530

amit – 2 file(s) modified
mail: migrate mail_outbox SENDGRID rows to RELAY (applied to production)

SENDGRID never meant SendGrid -- resolveSender() already routed it to the
Workspace relay, which is why outbox mail kept being delivered while direct
JavaMailSender injections failed against the real, dead SendGrid bean. So this
relabels rows without changing where anything is sent.

Applied to hadb1 2026-08-31 18:10 IST:
before SENDGRID=5956 RELAY=0 GOOGLE=4896 (total 10852)
after SENDGRID=0 RELAY=5956 GOOGLE=4896 (total 10852)
backup dtr.mail_outbox_sendgrid_backup_20260831_1810 (5956 rows)

The one PENDING row (id=26838) migrated cleanly and still routes to the relay.
Only GOOGLE and RELAY remain in the column. Rollback statement is in the script.

The comment claiming legacy SENDGRID rows exist is now false and has been
corrected; SendGrid appears nowhere in the codebase.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/mail/MailOutboxService.java
+ /trunk/profitmandi-dao/src/main/resources/sql/migration_mail_outbox_sendgrid_to_relay.sql

Rev 37482 – carlcare: recover tecno/itel activation dates, and fix trunk broken by ...

amit — Mon, 31 Aug 2026 17:59:36 +0530

amit – 4 file(s) modified
carlcare: recover tecno/itel activation dates, and fix trunk broken by r37479

r37479/r37480 swept a working-copy edit to Application.java into the mail commit: trunk
has called scheduledTasks.checkCarlcareImeiActivation() since then without containing it,
so profitmandi-cron has not compiled. This adds the rest.

WHAT THIS IS

The tecno feed has been dead since 2024-11-20, when transsion decommissioned the SAP
OData hosts cms.tecno-mobile.com:8099 / cms.itel-mobile.com:8099. The imwav DCR portal
recovers itel but has nothing for tecno -- all three tecno logins together expose 17
imeis over five years, against 31,928 tecno rows in fofo.activated_imei. Everything since
has been manual CSV via /imei/upload.

Carlcare is transsion's own after-sales arm, and the warranty-check page on carlcare.in is
backed by a public per-imei endpoint that answers for tecno, itel and infinix with no
login, no cookie and no captcha:

GET ind-mis-carl.shalltry.com/CarlcareClient/electronic-card/check-extended_warranty-web?imei=
sign: md5(SALT + imei)

The sign header is mandatory (without it: code 10022 "Sorry, web sign is error"). The salt
is in the site's own bundle, _nuxt/085537c.js module 688, along with the base url; re-read
that bundle if it ever stops working. status 3 = activated and carries activeTime, status
2 = device known but not activated yet and activeTime is null.

It is also the semantically right source. The DCR portal serves an INVENTORY report and
the old SAP feed served a TERTIARY SALES report, whereas activeTime is the date the
handset was actually activated -- which is what fofo.activated_imei is meant to hold and
what tertiary payout is computed on.

Measured against hadb1 before writing any of this: tecno 355463920708766 -> 2026-08-28 and
itel 359207322028000 -> 2026-08-30, both exact matches to rows we already had. A read-only
trial of 50 itel imeis answered 50/50 with no errors and no sign rejections, agreed with
our catalog brand on all 50, and returned a date for 18 -- every one of those 18 falling
AFTER our own billing date, 3 to 1,111 days, median ~220.

SHAPE

Pool queries and saveActivation semantics are the vivo ones, so the two read alike, and no
DAO change was needed: the pending queries are already brand-generic. The far end is far
cheaper than vivo's, one signed GET per imei, so there is no captcha service, no cookie
store, no session seeding and no verdict reporting.

50 imeis every 5 minutes = 14,400 lookups a day against ~10,400 pending itel, so the whole
pool is covered daily with headroom. The pool reaches back to 2021, so the ticks are
themselves the backfill of the nov-2024 blackout; there is no one-off to run.

Two things worth knowing before changing it:

- The batch is drawn ROUND-ROBIN across each (brand, channel) queue, not by concatenating
them. A full daily pass can concatenate freely because it walks to the end, but a
50-at-a-time tick cannot: itel is ~1,550 secondary against ~8,851 tertiary, so the head
of a concatenated list is ~31 straight ticks of pure secondary before one tertiary imei
is asked about. The first trial batch was 100% secondary for exactly that reason.

- Every outcome stamps the row, failures included. This is the one deliberate departure
from vivo, which leaves a failure unrecorded so it retries next pass -- safe there
because the next pass is tomorrow. On a 5-minute cadence it is not: an unstamped imei is
due again in five minutes, the query keeps handing back the same 50 rows, the batch never
advances past them, and the endpoint is asked the same questions twelve times an hour for
as long as it keeps failing. See the runaway documented on oppoRealmeImeiActivation.

BRANDS is itel alone to start. That is a rollout order, not a limit of the endpoint: itel
is the brand we can CHECK, because the DCR pull independently produces itel dates to
reconcile against, where tecno has nothing. Add "Tecno" once a day's rows agree. Both feeds
may write itel meanwhile with no coordination -- the pool query only returns imeis whose
activationTimestamp is still null, so whatever one fills has left the other's pool.

Scheduled tick plus a --checkCarlcareImeiActivation flag, both wired.

+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/CarlcareImeiActivationService.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledSkeleton.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledTasks.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/StandAlone.java

Rev 37481 – imei activation: one 2-day billing floor for every brand, and ...

amit — Mon, 31 Aug 2026 17:59:05 +0530

amit – 3 file(s) modified
imei activation: one 2-day billing floor for every brand, and drop two dead methods

The pending pool is a UNION of two channels, not an intersection: an imei qualifies
if WE billed it to the partner (selectImeiActivationByBrand) or the PARTNER billed it
on to the end customer (selectImeiActivationByBrandTertiary). The two are disjoint by
construction -- the secondary query excludes anything carrying a FofoLineItem -- so a
unit moves from one to the other as it sells through and is never asked about twice.
Said so on the interface, since the pairing was only documented at the call sites.

billedBefore moves from now-1d to now-2d, so both channels ask only about stock billed
MORE THAN 2 DAYS ago. Anything sold in the last 48 hours has essentially never been
activated yet, so the lookup is spent for nothing; it is not lost, the same imei comes
back into the pool as soon as it crosses the floor, and again every day after that
until it activates. Kept in the repository rather than per caller so vivo, oppo, realme,
motorola and the new carlcare pass inherit one rule instead of drifting apart.

Costs almost nothing today -- secondary pool, old floor vs new:

itel 1550 -> 1550 realme 849 -> 849 oppo 2021 -> 2019
vivo 5018 -> 5016 motorola 1168 -> 1153 tecno 502 -> 495

26 rows across six brands, each deferred by one day.

Removed as dead:

selectImeiActivationPendingByRealme -- a verbatim duplicate of
selectImeiActivationPendingByBrand down to the named query and the parameters. Nothing
called it; StandAlone already used the brand-generic method for realme and said so in
a comment, which is now updated.

selectImeiSoldNotActivatedByBrand -- interface, impl and named query. No callers
anywhere in web, fofo, cron or dao.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/fofo/ActivatedImei.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/ActivatedImeiRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/ActivatedImeiRepositoryImpl.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 37478 – mail: MailOutboxService implements MailQueue Adds the single entry point, ...

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

amit – 1 file(s) modified
mail: MailOutboxService implements MailQueue

Adds the single entry point, queue(MailRequest). The twenty-odd queueMail*
overloads remain as delegates because ~112 call sites use them, but they now
funnel through one path rather than each building their own argument list.

Selecting the transport moves here too: MailSenderType.GOOGLE maps to the
authenticated sender, anything else to the relay.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/mail/MailOutboxService.java

Rev 37477 – mail: one way to send mail, and nothing sends inline ...

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

amit – 8 file(s) modified
mail: one way to send mail, and nothing sends inline

There were three overlapping APIs -- Utils.sendMail* (7 static overloads),
EmailServiceImpl.sendMail* (7 more) and MailOutboxService.queueMail* (20). The
first two built their own MimeMessage, hardcoded From: noreply@smartdukaan.com
in eleven places, and pushed straight down whichever JavaMailSender the caller
passed.

That From is why mail was refused: an authenticated Workspace session may send
only as the account it logged in as, and noreply@ is a different identity in the
same domain. Sending inline also meant a failed send was lost outright and took
the calling job down with it, which is how one expired credential came to mark
ten report jobs FAILED.

New in profitmandi-common:
MailQueue - the single entry point; queue() returns once the mail is
recorded, not once it is sent
MailRequest - one value object replacing the 34 overloads
MailSenderType - GOOGLE (authenticated, From rewritten) or RELAY (IP-authorised)

The interface lives in common while MailOutboxService implements it in dao,
because dao depends on common and not the reverse -- Utils and EmailService
could not otherwise reach the outbox at all.

Utils and EmailService keep their signatures so the ~38 call sites still
compile, but now delegate and ignore the JavaMailSender argument; choosing a
transport was never the caller's business. Both are marked deprecated.
MailQueueHolder bridges the static helpers to the bean and is documented as a
compromise, not a pattern.

+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/mail
+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/mail/MailQueue.java
+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/mail/MailQueueHolder.java
+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/mail/MailRequest.java
+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/mail/MailSenderType.java
~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/services/EmailService.java
~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/services/EmailServiceImpl.java
~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/util/Utils.java

Rev 37476 – mail: delete the dead SendGrid bean from fofo, make the ...

amit — Mon, 31 Aug 2026 17:19:03 +0530

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

googleMailSender is now @Primary and answers to 'mailSender'. Two senders remain:
the authenticated Workspace identity and the IP-authorised relay.

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

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 37474 – mail: delete the dead SendGrid bean from cron, make the ...

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

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

The @Primary bean named 'mailSender' was SendGrid, so every unqualified
JavaMailSender injection got it -- and SendGrid rejects with 535, which is what
was failing 10 report/notification cron jobs (dailyTrackingReport,
monthlyTargetForPartner, sendFeebackSalesAndRbm and others). 420 occurrences in
one log.

googleMailSender now answers to both 'googleMailSender' and 'mailSender' and is
@Primary, so those injections resolve to a sender that works and whose From is
rewritten to the authenticated identity. No call site changes.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/MailOutboxScheduler.java