| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37368 |
32 m |
amit |
/trunk/profitmandi-cron/src/main/ |
Cron: raise SMTP timeouts, rotate app password, add offer-circular ingest keys
- SMTP 10s -> 30s connect / 120s read-write on both senders; the 10s read timeout was
cutting off larger attachment sends. App password rotated to match the current
Google account credential.
- offer.circular.ingest.enabled / offer.circular.review.url added to dev, staging and
prod. Off by default in all three: enabling it makes the job pick up DRAFT circulars
uploaded from the FOFO portal, parse them and mail the uploader, which should only be
switched on once offer.circular.dir is a real path in that environment. There is no
fallback between profiles, so the key has to exist in each one. |
|
| 37367 |
32 m |
amit |
/trunk/profitmandi-web/src/main/ |
Mail: raise SMTP timeouts and rotate the sdtech app password
The 10s read timeout was cutting off larger attachment sends (policy PDFs, invoice
attachments) and surfacing as a send failure the outbox then retried. Raised to 30s
connect / 120s read-write on both senders. App password rotated to match the current
Google account credential.
Also fills in new.solr.url and store.app.url in staging.properties - staging carries no
fallback to dev/prod, so a missing key stops the context from starting. |
|
| 37366 |
32 m |
amit |
/trunk/profitmandi-fofo/src/main/resources/META-INF/ |
Staging config: fill in the keys fofo needs to start on staging
staging.properties is much thinner than dev/prod and there is no fallback between
profiles - a missing key stops the context from starting. Adds react.app.url (no
dedicated staging build of the react partner app exists, so it points at the prod
host), app.token.url (profitmandi-web is co-deployed on the same Tomcat there) and
media.document.url. |
|
| 37365 |
32 m |
amit |
/trunk/profitmandi-fofo/src/main/ |
Debit note receive: surface the partner-declared condition and warn before rejecting
The receive screen defaulted every row's condition to GOOD regardless of what the
partner declared, so a warehouse user could not see what they were disagreeing with -
and the backend treats any disagreement as a rejection of the whole debit note.
- Show 'Declared By Partner' per row and preselect the condition to match it, so
submitting unchanged is a genuine agreement rather than an accident of the default.
- A changed row now switches the submit button to 'Reject Return', shows what rejection
means (no refund; partner, Logistics, RBM and Sales notified), makes the remark
mandatory and confirms before posting.
- SMTP timeouts raised to 30s connect / 120s read-write; the 10s read timeout was
cutting off larger attachment sends.
- jsVersion 405 -> 406 for the return.js change. |
|
| 37364 |
33 m |
amit |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/ |
Offer circular ingest: report discarded rows instead of counting attempts
Pairs with the repository change that makes insertBenefit/insertTenure/insertBank return
their affected row count. The summary now bumps only when a row actually landed, and
records a drop naming the likely unseeded master (offers.txn_mode / emi_scheme / bank)
when it did not. Without this an ingest over empty masters reported a full, healthy
parse while writing nothing. |
|
| 37363 |
33 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers/ |
Offer circular ingest: return affected rows so INSERT IGNORE cannot hide an FK failure
insertBenefit/insertTenure/insertBank use INSERT IGNORE for idempotency, which also
makes MySQL downgrade a foreign key violation to a warning. Production was bootstrapped
without the bank / txn_mode / emi_scheme masters, so all 872 benefit and tenure inserts
were silently discarded: the ingest reported PUBLISHED with 239 offers carrying no
amounts, no tenures and no bank eligibility, and nothing anywhere said so.
The three methods now return the affected row count (1 written, 0 discarded) so the
caller can count what landed rather than what it attempted. |
|
| 37362 |
33 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/external/ |
External feed: keep placeholder 'Any Colour' SKUs out of the partner feed
catalog.item rows whose color is a placeholder ("Any Colour", "f_Any Color", ...) are
not real sellable variants and must never reach partners. Excluded from every feed and
count query via a single NO_PLACEHOLDER_SKU predicate so the SKU list and its count
cannot drift apart. The boundary check leaves real colors like "Rainbow" untouched. |
|
| 37361 |
33 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Mail outbox: one transaction per mail, retry once more, stable Message-ID
processPendingMails ran the whole batch in a single REQUIRES_NEW transaction, so a
crash mid-batch rolled back the status of every mail already delivered in that cycle
and the next run re-sent them.
- Split into selectPendingIds (read-only) plus sendOne per mail, each REQUIRES_NEW via
a @Lazy self-reference so the proxy actually applies. Outcome is committed as soon
as it is known; a crash now loses at most the mail in flight.
- MailOutbox.selectPending retries FAILED rows once more (retryCount < 2).
- Stable per-row Message-ID so a retry arrives as the same message and the receiving
server can collapse it instead of showing a duplicate. |
|
| 37360 |
35 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/icicilombard/ |
ICICI policy issuance: stop losing policies to a proposal read timeout
hitAfinityProposal called ICICI's gadget proposal endpoint on the default 10s socket
timeout. That POST issues the policy, so a read timeout abandons a request ICICI is
still completing. The exception then unwound through generateIciciLombardPolicy into
the controller's @Transactional(rollbackFor = Throwable.class), rolling back the whole
request - including the wallet debit - before the tracker row was ever touched. Result:
policy possibly live at ICICI, no trace on our side, and the 'policy already exists'
retry path dead-ends because its Redis cache is only written on a parsed success.
- Proposal and policy-certificate calls move to a dedicated RestClient built on
HttpClientFactory.insuranceIssuanceRequestConfig() (socket 45s). JWT and quote stay
on the default client - fast, and no remote write.
- Transport failures are classified via HttpTransportFailures and reported as 'outcome
unknown', not as an ICICI rejection.
- IciciPolicyTrackerBookkeeping writes the tracker in REQUIRES_NEW, so both the UNKNOWN
outcome and the issued policy number survive the request rollback. Recovery from an
UNKNOWN row is the existing recoverPolicyNumberByProposalNumber path.
Code only, no DDL: status is varchar(20) and remarks is text on prod already. |
|
| 37359 |
35 m |
amit |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/web/client/ |
ICICI proposal read timeout: add insurance-issuance HTTP config + shared transport-failure classifier
The default RestClient carries a 10s socket timeout, sized for quick lookups. ICICI's
gadget proposal endpoint underwrites and issues the policy synchronously and needs
longer; abandoning the read discards the only response carrying the policy and
proposal numbers for a policy that is already live at the insurer.
- HttpClientFactory.insuranceIssuanceRequestConfig(): connect 5s, socket 45s. Not
slowRegulatorRequestConfig() - its contract forbids request-thread use with an open
transaction, which is exactly the ICICI call site.
- HttpTransportFailures: cause-chain check separating 'the call never completed' from
'the remote said no'. Needed because RestClient rewraps transport errors as
RuntimeException(GE_1006), so the top-level exception type is uninformative. |
|
| 37358 |
3 h 2 m |
ranu |
/trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/ |
total show on warehouse wise stock value on item detail |
|
| 37357 |
3 h 4 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/cs/ |
Add CsService.getAuthUsersByPartnerIdAndCategory for partner+category+escalation lookup
sendMailForActionOnDispatch mailed every L1 position on the partner, which on live data
means the DESIGN (17), SALES (4) and WAREHOUSE (11) owners as well as the RBM (18). It
also hand-rolled the partner_position -> position -> auth_user walk against repositories.
Add a single reusable resolver on CsService: active auth users holding one position
category against a partner, optionally narrowed to escalation levels. It follows the
house resolver shape - the partner's own regions plus ALL_PARTNERS_REGION, partner_id in
(0, fofoId) - so region-wide mappings are honoured, and it short-circuits on empty id
lists because selectByIds builds an IN () predicate that breaks on an empty list.
The call site in TransactionServiceImpl went in with r37356; without this commit trunk
does not compile. |
|
| 37356 |
3 h 6 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/ |
Fixed max limit to 15 lac for Credit limit |
|
| 37355 |
7 h 42 m |
aman |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ |
AI lead intake (fofo, live): assign new leads to a random active BGC L1 instead of the hardcoded Khushbu/Archana round-robin |
|
| 37354 |
7 h 44 m |
aman |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/ |
AI lead intake: pool is BGC L1 (category 20), not Sales L1 - BGC is the desk that works AI leads |
|
| 37353 |
7 h 49 m |
aman |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/ |
AI lead intake: assign new leads to a random active Sales L1 instead of fixed auth id 53 |
|
| 37352 |
8 h 35 m |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
Fixed max limit to 15 lac for Credit limit |
|
| 37351 |
10 h 1 m |
ranu |
/trunk/ |
code committed for sales l3 added in bi and other model |
|
| 37350 |
11 h 13 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/ |
Fix SD Credit daily statement showing zero interest on overdue loans
sdDirectService classified each day's interest by exact-matching the
loan_statement description ('Interest On Loan Per Day' /
'Penalty On Loan Per Day'). Once a loan crossed its due date the cron
switches the label to 'Overdue Interest On Loan Per Day', which matched
neither filter, so the daily statement reported 0.00 interest for every
overdue day even though the charge was booked correctly in
loan_statement and loan.interest_accured.
Classify by tenure window against loan.getPenaltyDate() instead - the
same test addInterest() uses to pick the rate - and net the day's full
interest out of the opening balance so penalty days are consistent too.
Seen on loan 120277 (invoice NSLCK35860): Rs.73-83/day accruing from
08-Aug, displayed as 0.00. |
|
| 37349 |
1 d 2 h |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/ |
super retailer club 5 live |
|