| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37536 |
2 d 6 h |
amit |
/trunk/profitmandi-fofo/src/main/ |
purchase return: order the invoice-return queue by what still needs doing
A return with no debit note sorts first - it is the one still owing an action -
and the screen reflects that ordering. Also refuses the cancel path when any order
on the invoice is in a state that must not be cancelled. |
|
| 37533 |
3 d 3 h |
ranu |
/trunk/ |
loi process added, revival and code changes process |
|
| 37531 |
3 d 11 h |
amit |
/trunk/profitmandi-fofo/src/ |
offer circular: stop letter-led model names inheriting the previous variant
A part that is ONLY a memory spec inherits the preceding model name, because Oppo
writes 'RENO 15 PRO 256GB, 512GB' and the second part is not a product. The pattern
matched too loosely: the optional unit group matched the FIRST letter of a model
name and the rest fell through the trailing character class, so 'G06, G37, G37
Power' inherited its way to 'G06 G37' - two Motorola phones fused into one entity
that matches no SKU, costing G37 its cashback on five offers.
Requiring a leading digit makes it a memory spec rather than anything that merely
contains G/T and digits. Realme 'GT 7' matches the same way and survived only
because it never follows a comma.
Same root cause as the word-boundary guards on CAPACITY and MEMORY_PAIR: a digit
glued to letters belongs to the model name.
ProductNamesTest: 11 -> 12, covering 'G06, G37, G37 Power' and 'GT 7T, GT 7'. |
|
| 37530 |
3 d 11 h |
amit |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ |
purchase return: use the auto-approve check on invoice cancellation
Calls GstProService.isCancellableWithoutApproval (r37529) so a DC invoice, or an
unshipped order whose IRN is still cancellable, skips the approval step. |
|
| 37528 |
3 d 11 h |
amit |
/trunk/profitmandi-fofo/src/ |
offer circular: apply the supersede rule on ingest (fofo)
A published circular now expires still-running offers from earlier circulars, and
deactivates the web offers they produced, so the same cashback is never current
twice. The converse also holds: re-ingesting an older circular while a newer one is
live leaves it expired rather than resurrecting it.
Older offers remain readable as reference - only status changes, never end_date.
Counts appear in the ingest summary as supersededOlderOffers / expiredAsSuperseded
and, on the web side, supersededOlderMonths / notPublishedSuperseded.
ScopeConfigTest's stub gains the two new CircularIngestRepository methods - the same
brittleness the scripts/offer_circular README notes for JdbcIngestRepo. |
|
| 37526 |
3 d 11 h |
amit |
/trunk/profitmandi-fofo/src/ |
offer circular: scope config screen, resolve screen, web offer sync (fofo)
Screens (each its own endpoint, under the OFFER CIRCULAR menu):
- /offerCircularScope - add/edit divisions, take a brand in or out of scope,
register label aliases. 'Remove' is in_scope=0 + a required reason, never a
DELETE: offer.division_id is an FK and the history would go with it.
- /offerCircularResolve - the product queue, split out of the review screen. The
editor was a <td colspan=6> pretending to be a form, which is why it never
aligned; it is now master-detail. Naming and Coverage are separate tabs because
an alias cannot answer a bundle at all - the coverage panel says so and offers
the two answers that ARE safe (ignore, or reclassify as naming).
Ingest:
- ScopeConfig resolves division aliases and carries the canonical label on
Decision. insertOffer and ProductAliases.find use it; offer_raw_row keeps the
verbatim label, being the source of truth for re-parsing.
- CircularIngestRunner publishes to dtr.web_offer after the document is marked
PUBLISHED, in its own transaction with exceptions swallowed - a circular that
parsed correctly must stay published even if the web sync fails.
Review screen:
- the ingest summary was a raw Map.toString() inside a nowrap span and ran off
the card; now parsed into chips with the drop reasons behind a disclosure.
jsVersion -> 417 (merged with r37525's 412; cssVersion 53 kept from that commit). |
|
| 37523 |
4 d 4 h |
ranu |
/trunk/ |
loi process added, revival and code changes process |
|
| 37519 |
4 d 10 h |
ranu |
/trunk/ |
rbm drr dashboard position wise data |
|
| 37516 |
5 d 10 h |
ranu |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ |
pending loi download access given to raj singh |
|
| 37513 |
5 d 10 h |
ranu |
/trunk/ |
notification live |
|
| 37508 |
5 d 11 h |
ranu |
/trunk/ |
notification live new ....api and modification , ui |
|
| 37505 |
5 d 11 h |
ranu |
/trunk/ |
rbm drr dashboard , all today po rbm view maped |
|
| 37497 |
5 d 13 h |
ranu |
/trunk/ |
rbm drr dashboard , all today po rbm view maped |
|
| 37493 |
5 d 16 h |
amit |
/trunk/profitmandi-fofo/src/main/ |
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. |
|
| 37490 |
5 d 17 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. |
|
| 37487 |
6 d 10 h |
ranu |
/trunk/ |
rbm drr dashboard , all today po rbm view maped |
|
| 37480 |
6 d 11 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 |
6 d 11 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. |
|
| 37476 |
6 d 12 h |
amit |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/ |
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. |
|
| 37460 |
8 d 13 h |
ranu |
/trunk/ |
rbm drr dashboard new ui looks |
|