| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37405 |
43 m |
amit |
/trunk/profitmandi-fofo/src/main/ |
Drive the onboarding/HR state dropdowns from inventory.statemaster
fofo-form.vm, fofo-edit.vm and hr_employee_form.vm each hardcoded their own state
list instead of using $stateNames. Six of those 37 values do not exist in the
master (& vs and variants, Uttaranchal, the pre-merger UTs), so anything picked
from them could not be resolved back.
Only the name="state" select changed in hr_employee_form.vm; its other dropdowns
are untouched. |
|
| 37404 |
43 m |
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. |
|
| 37403 |
43 m |
amit |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/model/ |
Add the canonical state list URL constant
Serves inventory.statemaster to clients so none of them carry their own copy. |
|
| 37402 |
2 h 46 m |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
Vivo IMEI activation: report Vivo's captcha verdict back to the solver
Only this cron ever learns whether Vivo accepted a captcha (status 0 means it
was wrong), so it is the only place that can label the solver's training data.
After each checkCode response it now posts the image, the code and the outcome
to the solver's /verdict endpoint, which files the sample as accepted (the
prediction was right - a free label) or rejected (needs a human to label it).
The solver has been running at a measured 22.3% accept rate and no training
data was ever collected, so the model could not be improved at all.
Strictly best-effort: 2s connect / 3s read timeouts and every exception
swallowed. Data collection must never slow down or break IMEI activation.
The shared secret is read from CAPTCHA_VERDICT_TOKEN in the environment,
falling back to a captcha.verdict.token property, so it need not be committed.
Without a token the call is skipped entirely.
Also drops /tmp/captcha.jpg: the captcha bytes are needed in memory for the
verdict report anyway, so the two concurrently-scheduled Vivo jobs no longer
share one file and overwrite each other's image. |
|
| 37401 |
3 h 13 m |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
Drop commented reference to the removed InvoiceFormatter |
|
| 37400 |
3 h 13 m |
amit |
/trunk/profitmandi-fofo/src/main/ |
Merge the three sale-invoice download endpoints into /invoice/download
generateInvoice, generateInvoices and downloadInvoices differed only in how they
resolved the order ids and who was allowed to ask; everything after that was the
same. That drift meant only the single-order download stapled the policy
certificates, so the same invoice pulled from sale history came out without
them. One handler now selects by orderId, partner date range (admin only) or the
caller's own sale-history search, over reusable resolvers plus a shared
render-and-respond step. The old URLs stay as deprecated shims.
The admin range download is now fault tolerant - one unbillable order used to
fail the whole batch.
Remove the commented-out thermal variant of generateInvoice and the unused
paymentOptionIdPaymentOptionMapUsingPaymentOptions. Bump the asset version for
the sale.js change. |
|
| 37399 |
3 h 13 m |
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. |
|
| 37398 |
3 h 13 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Share one insurance invoice line builder across partner and standalone invoices
Extract InsuranceInvoiceLine next to the partner invoice builder so both callers
- OrderServiceImpl.getInvoicePdfModel(FofoOrder) and the standalone policy
invoice in InsuranceController - produce the SAC, tax split and description from
one place. Arithmetic is unchanged (verified bit-identical); policyPlan is null
for policies sold outside a device sale, so it falls back to a generic plan name
instead of printing null.
Add IciciLombardService.policyCertificatePath so the service that writes the
certificate owns the path; callers were rebuilding it and hardcoding the prod
directory, so lookups silently missed off prod.
Add selectByInvoiceNumbersAndProviderId so bulk invoice downloads fetch policies
in one query instead of one per invoice. |
|
| 37397 |
3 h 13 m |
amit |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/util/ |
Consolidate insurance invoice line rendering; drop dead thermal-printing path
Remove the unused 58/80mm thermal chain (InvoiceFormatter, PrinterType and the
PrinterType overload of generateAndWrite) - its only caller was a commented-out
endpoint, and it bypassed the insurance line folding in DocumentData.items().
Drop generateMarginSchemeInvoice, a no-op alias for generateInvoiceV2 with no
production callers. |
|
| 37396 |
3 h 18 m |
amit |
/trunk/profitmandi-fofo/src/main/resources/ |
observability: delete the log4j1 config left alongside log4j2.xml in fofo
The module logs through log4j2 (log4j2.xml). This log4j.properties is a
log4j1-era leftover that nothing reads. |
|
| 37395 |
3 h 19 m |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ |
observability: retire the dead Nagios monitoring path, migrate balance signals to Micrometer
There is no Nagios server and the NRPE daemons have been removed from every
host, so the properties files written under /var/log/services were being
produced for nobody.
Deleted:
- CronMetricsService: zero references. Spring instantiated the @Service so its
constructor registered three meters, but nothing ever incremented them --
cron_execution_* read 0 in prometheus while cron_job_count_total (from
CronJobMonitorAspect) had recorded 1,597 executions.
- NagiosMonitoringScheduledSkeleton.
Removed the nagios properties writes from ScheduledSkeleton (-155 lines) and
KnowlarityCallMonitorScheduler (-46, including its now-purposeless
markTaskComplete helper). These recorded a per-job 0/1 status that
CronJobMonitorAspect already captures properly as success, failure and
duration metrics.
Kept the two signals that are genuinely useful: SMS gateway balance and the
ThinkWalnut recharge wallet balance now publish as Micrometer gauges via the
new BalanceGauges component, scraped from /actuator/prometheus. -1 means 'not
read yet' so a scrape before the first run is distinguishable from a real zero.
No behaviour change to any scheduled job. Compiles clean. |
|
| 37394 |
3 h 49 m |
ranu |
/trunk/ |
total show on warehouse wise stock value on item detail |
|
| 37393 |
6 h 44 m |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
Vivo IMEI activation: validate captcha solver response before submitting to Vivo
The captcha solver at 45.79.121.178 was down from 09-Jul-2026 to 25-Aug-2026
(uwsgi never restarted after a host reboot). nginx returned a 502 page for
every request. RestClient.executeJson returns the response body regardless of
HTTP status, so CaptchaService handed that HTML page to Vivo as the captcha
code and Vivo logged it as 'Found invalid captcha' - indistinguishable from an
ordinary wrong guess. The outage went unnoticed for 46 days.
CaptchaService now checks the response against the solver model's own 31-class
alphabet (^[1-9A-HK-NP-Z]{4}$) and returns null for anything else, logging the
offending payload. VivoImeiActivationService skips the IMEI when the code is
null instead of posting the garbage; it is retried on the next run.
Also drops a System.out.println of the full base64 captcha image. |
|
| 37392 |
1 d 5 h |
vikas |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/ |
Whatsapp Apis |
|
| 37391 |
1 d 5 h |
vikas |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/services/ |
Whatsapp Apis |
|
| 37390 |
1 d 6 h |
ranu |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ |
total show on warehouse wise stock value on item detail |
|
| 37389 |
1 d 6 h |
ranu |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ |
total show on warehouse wise stock value on item detail |
|
| 37388 |
1 d 6 h |
vikas |
/trunk/ |
Whatsapp Apis |
|
| 37387 |
1 d 8 h |
vikas |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/ |
Disable UPI data |
|
| 37386 |
1 d 10 h |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/ |
aging stock report put dp after stock qty |
|