| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37490 |
1 d 11 h |
amit |
/trunk/ |
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. |
|
| 37480 |
2 d 5 h |
amit |
/trunk/ |
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. |
|
| 37479 |
2 d 6 h |
amit |
/trunk/ |
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. |
|
| 37475 |
2 d 6 h |
amit |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/config/ |
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. |
|
| 37454 |
4 d 16 h |
amit |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/config/ |
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. |
|
| 37415 |
7 d 10 h |
vikas |
/trunk/ |
Whatsapp Apis |
|
| 37412 |
7 d 10 h |
vikas |
/trunk/profitmandi-web/src/main/ |
Whatsapp Apis |
|
| 37411 |
7 d 10 h |
ranu |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/ |
v2 version some fixes |
|
| 37404 |
8 d 0 h |
amit |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/ |
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. |
|
| 37399 |
8 d 3 h |
amit |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/ |
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. |
|
| 37392 |
9 d 5 h |
vikas |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/ |
Whatsapp Apis |
|
| 37391 |
9 d 5 h |
vikas |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/services/ |
Whatsapp Apis |
|
| 37388 |
9 d 7 h |
vikas |
/trunk/ |
Whatsapp Apis |
|
| 37387 |
9 d 8 h |
vikas |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/ |
Disable UPI data |
|
| 37383 |
9 d 12 h |
vikas |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/ |
Disable UPI data |
|
| 37382 |
12 d 4 h |
amit |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/ |
Unbreak profitmandi-web: pass the optional fofoId r37377 added
r37377 widened PurchaseReturnOrderRepository.selectByWarehouseIdsAndDateRange
with an optional fofoId so the FOFO Sale Returns partner filter could be a
predicate rather than a post-filter. r37378 updated the FOFO caller; this web
caller was missed, so it still passed 4 arguments to a 5-argument method and
profitmandi-web has not compiled since - the web war could not be built at all.
/return/invoice has no partner picker (its only params are fromDate/toDate; the
fofoId param elsewhere in this controller belongs to searchDebitNotes), so null
is the right value: the impl only adds the fofoId predicate when non-null, which
is exactly this endpoint's pre-r37377 behaviour. No listing change.
The other three methods r37377 added - selectPendingByWarehouseIds,
selectUnreceivedSince, selectEarliestCreateTimestamp - have no web callers; the
pending-queue screen is FOFO-only, so nothing else was left half-migrated.
Verified all five modules compile. |
|
| 37381 |
12 d 5 h |
amit |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/ |
Guard empty item IN () and null billing address on the app sale-details paths
Mirrors fofo r37380 on the profitmandi-web side, where the same two defects exist.
V2FofoOrderController (live mobile-app API, not the dormant fofo V2):
- sale details built itemIds from fofoOrderItems and passed them straight to
itemRepository.selectByIds. An insurance-only sale has no fofo_order_item row,
so the list is empty and selectAllByInOrderByDesc throws "List should not be
empty". The sibling sale-search method in this same file was already guarded;
the detail method was not.
- customerBillingAddressObj was put into the response unconditionally, so an
order with customerAddressId 0 (no address is required for a plain POS sale)
returned null and the app had no name or phone to show. Fall back to the
customer's own name and mobile, matching the invoice PDF. Applied at both sites.
CustomerController: same empty-IN exposure in the customer order-history batch
fetch, where a customer whose only order is an insurance sale yields no order
items. Adds the java.util.HashMap import this file needed (it imports java.util
members individually).
Verified profitmandi-web compiles clean with these changes. Note trunk currently
does NOT build: V2FofoPurchaseReturnController:635 still calls the 4-arg
selectByWarehouseIdsAndDateRange that r37377 widened to 5 args (r37378 updated
the fofo caller but not this one). That break is untouched here and needs its
own fix before a web war can be built. |
|
| 37373 |
13 d 8 h |
vikas |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/ |
Active Scratch Offers |
|
| 37369 |
13 d 12 h |
amit |
/trunk/ |
Fixed mail sender everywhere |
|
| 37367 |
14 d 3 h |
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. |
|