| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37805 |
8 d 12 h |
amit |
/trunk/profitmandi-dao/src/main/ |
fix(catalog): trim f_ colour prefix space; age delisted listings from last activation
- Item.normalizeColor drops the space after f_ on every write (upload sheets typed
'f_ Black', which read ' Black' everywhere); ItemLoaderService uses it so the
duplicate-colour check compares the clean value
- tag_listing.last_activated, stamped by TagListing.setActive on off->on;
updateActiveById now goes through the entity (+flush) so the toggle stamps it
- delist cron + SQL script age a listing from GREATEST(start_date, last_activated),
so a re-activated listing is not delisted again the next morning
- migrations: add_tag_listing_last_activated_20260929.sql, fix_item_color_prefix_space_20260929.sql
(both applied on hadb1 2026-09-29; 174 items trimmed, 36830 excluded - clashes with 37089) |
|
| 37778 |
12 d 18 h |
amit |
/trunk/profitmandi-dao/src/main/ |
fix(catalog): delist cron retires only models it darkened in the same run
Step 4 scanned every mobile model with no active listing and moved it to OTHER,
so new launches (categorised before listing) and hand-paused models were retired
the next morning, e.g. Nothing Phone 4 1026596-603 on 2026-09-15. Scope it to
models whose listing this run delisted (_delist_audit run_date = today).
Add fix_dark_model_retire_20260924.sql to restore the 16 models still stuck on OTHER. |
|
| 37566 |
27 d 4 h |
amit |
/trunk/profitmandi-dao/src/main/ |
Delist logic v3: require a month of no movement; add CatalogDelistService
Zero stock alone was too weak a test. It fired on SKUs partners were still
transacting, where the recent movement was often the very sale that emptied the
stock. v3 additionally requires no movement for a month on either side:
- SmartDukaan via warehouse.scanNew (3.4M rows, live). Note warehouse.scan is a
dead Saholic relic - 2,476 rows, last write 2012.
- any partner via fofo.scan_record, any scan type.
Phrased as NOT EXISTS so they short-circuit on the first recent row and use the
(inventoryItemId, scannedAt) / (inventory_item_id, create_timestamp) indexes.
An item that has never moved still qualifies, which is correct.
Also in v3:
- the internal pseudo-brands (Dummy, FOC, FOC HANDSET, Live Demo) are no longer
excluded and are swept like anything else.
- vendor-PO guard narrowed to status = 1. PARTIALLY_FULFILLED is UNREACHABLE,
not merely rare: none of the 8 PO-status writes in the codebase sets it, no
native SQL writes the column, and status = 2 has 0 rows across 51,593+ POs
back to 2011. Partial receipt is modelled per line (unfulfilledQuantity), so a
part-received PO sits in READY and is already caught. Documented so it is not
'restored' later as a supposed gap.
CatalogDelistService/Impl mirrors the migration statement for statement, for the
daily scheduled run. Bulk SQL rather than per-row updateActiveById +
publishStatusChange, which would commit to Solr once per catalog (~1,750 times
on the 2026-09-10 backlog); the job is instead scheduled ahead of the existing
06:00 full reindex. The dark-model step is deliberately house-wide rather than
run-scoped so it converges instead of leaving pre-existing dark models on a
stale RUNNING forever.
rollback_delist_recent_movement_20260910.sql restores the 24 listings / 21
models that the v2 run delisted before NEW 3 existed; their partners had
transacted them within the month. Id list frozen, not re-derived. |
|
| 37563 |
27 d 14 h |
amit |
/trunk/profitmandi-dao/src/main/ |
Filter delisted SKUs out of creation pickers; add rolling 24m delist migration
Creation screens could offer items whose catalog.tag_listing.active = 0:
- Item.selectAllModels (scheme/offer model dropdown) joined tag_listing with
no active predicate. Adding tl.active = true also gives the model-level
rollup, since callers dedupe to catalogItemId: a model whose colours are
all inactive now yields no rows, one keeping a listed colour stays.
- The shared partner item picker had no active filter at all. Added a second
basis via getAllPartnerItemStringDescription(anyColor, activeOnly);
activeOnly participates in the fofoItems cache key so the two bases cannot
serve each other's cached results. Default stays false for screens that
inspect or edit existing records.
- New TagListing.selectActiveItemIds named query backs the filter.
Also adds the rolling 24-month delist migration: zero stock both sides, no
outstanding vendor PO (status IN (1,2), external supplier, unfulfilled > 0 --
INIT is excluded as it is a drawer of stale drafts), and re-categorises
fully-dark mobile models to OTHER. Idempotent, audited, rollback documented. |
|