Subversion Repositories SmartDukaan

Rev

Show changed files | Details | Compare with Previous | Blame | RSS feed

Filtering Options

Rev Age Author Path Log message Diff
37526 36 d 5 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).
 
37335 52 d 11 h amit /trunk/profitmandi-fofo/src/main/ Show offer circular ingest state on the review screen

Upload and parsing run in different processes - the portal stores the PDF as DRAFT
and the cron job claims it minutes later - so the screen looked identical before and
after a successful ingest. A reviewer had no way to tell "not parsed yet" from
"parsed and produced nothing", and a FAILED circular showed nothing at all.

- the selected circular's state is shown as queued / parsing / parsed / failed,
with the recorded reason on failure and the ingest summary on success
- while it is DRAFT or PROCESSING the screen polls every 15s and pulls in the rows
the moment the parse lands. Polling stops as soon as the state settles, so it
cannot spin forever, and a transient error keeps waiting rather than giving up
- jsVersion 403 -> 404, since offer-circular-review.js is already being served and
this is a modification rather than a new file

Pairs with the stall reaper: a circular abandoned mid-parse is now both recovered
and explained on screen instead of sitting silently in PROCESSING.
 
37331 52 d 23 h amit /trunk/profitmandi-fofo/src/main/ Add offer circular review and curation screen

Shows the nine verbatim PDF columns beside what the parser made of them, uploads a
new monthly circular, and resolves the products the matcher could not.

Upload deliberately does not parse - it stores the PDF, sha256-deduped, and
registers it DRAFT, so an upload can never half-populate the offer tables. The cron
ingest job picks it up from there.

The curation queue groups by distinct (division, raw text) because that is the
product_alias key: one answer clears every row carrying that text, on this circular
and on every later one. On the Aug'26 circular that turns 152 unresolved rows into
106 decisions. Three actions mirror product_alias.action - PIN to a catalog id,
REWRITE to the catalog's spelling and match again, or IGNORE.

- Writes product_alias only, so nothing the screen does can set manually_curated
and lock a circular against re-ingest. Coverage decisions, which do need that,
are listed but visibly parked rather than offered a naming answer.
- A saved decision changes nothing until re-ingest, because aliases are read at
ingest time; the queue says so and the re-ingest button puts the document back
to DRAFT for the scheduler. The portal cannot run the ingest itself - that lives
in profitmandi-cron, which fofo does not depend on.
- The closest rejected match is shown for context and never pre-selected. Four new
OnePlus models each "nearly" matched a 2015 OnePlus 2 at 0.80-0.84, and offering
that as a suggestion invites a reviewer to confirm it. Where the catalog has no
such SKU the search says so and steers to IGNORE.
- aliasExport emits every decision as replayable SQL, because the portal writes to
one database and environments would otherwise drift apart silently.

Access is an email allowlist AND the admin role. Both are enforced in the
controller; the sidebar entry repeats the allowlist because visibility in auth.menu
is role-driven and cannot express a per-email rule.

No jsVersion bump: offer-circular-review.js is a new file that was never cached,
so it needs no cache-buster, and churning that shared counter only conflicts with
whoever is mid-edit on it.