## 1.0.0 - 2026-09-14

First real changelog entry for this module, reconstructed from `git log` and from
`TEST-REPORT.md`'s fix rounds, since the placeholder that shipped before this covered none of the
actual work. No `v1.0.0` tag has been cut yet.

### Added

* OAuth2 connection to InPost (Authorization Code + PKCE), with a back-office screen showing
connection health broken down into credentials, token, organization and token scope, each
checked live against the API rather than cached.
* Category mapping between PrestaShop and Von Halsky categories, including recursive mapping and
the category attribute tree pulled live from the API.
* Listing templates: title patterns, description source, price markup/discount, shipping days and
unit, with support for multiple templates and one required default.
* Offer publishing, both single-product (inline) and bulk (queued), with a readiness screen that
checks every product against InPost's requirements before publish is even offered.
* Price and stock synchronisation, on a configurable schedule and on demand, plus a minimum-stock
threshold that closes an offer instead of sending a low stock count.
* Offer close, reopen and unlink actions.
* Order import from the marketplace event stream, with manual product matching when an order line
can't be resolved automatically, and an "Importuj teraz" manual trigger.
* Status mapping and carrier mapping (parcel locker / courier) for order import, plus outbound
status pushes (accept/refuse) back to the platform when a PrestaShop order reaches a configured
state.
* The module's own async job queue and the `cron.php` entry point that drives it, including a
recurring category-data refresh job with a per-caller time budget.
* A diagnostics screen (health check tiles, API error log, CSV export) and a log/audit trail of
every API call and response.
* A first product published end to end against InPost stage, and the category mapping fixes that
made that possible.

### Changed

* Orders now materialise in PrestaShop only once the marketplace order reaches `ACCEPTED`, rather
than earlier in its lifecycle.
* Marketplace order confirmation mail is suppressed at the mail layer by default, since the buyer
address on these orders is a pseudonymous InPost relay address, not a real mailbox.
* Price and stock are recorded as synced only once the platform confirms the change, not as soon as
this module sends it - the two "sent" columns on the offers screen reflect what InPost actually
knows, not what was last transmitted.
* OAuth client secret and access/refresh tokens are encrypted at rest instead of stored in plain
text.
* The cron token is read from a request header first (`X-VH-Cron-Token` / `X-VH-Cron-Shop`) and
stripped from `$_GET`/`$_POST`/`$_REQUEST` before PrestaShop's own bootstrap runs, so it no
longer leaks into a redirect `Location` header and from there into access and proxy logs. The old
query-string form still works as a fallback.
* `ps_versions_compliancy.min` raised from `1.7` to `1.7.7` - the code already relies on the `mpn`
columns and `hookDisplayAdminOrderMain`, neither of which exists before 1.7.7, so the
declared floor now matches what the module actually needs. Part of a wider compatibility campaign
checking PHP 7.1-8.4 and PS 1.7.7-9.0; see `COMPAT-CAMPAIGN.md`.

### Fixed

* On PrestaShop 1.7.7 the `orders.note` column does not exist yet (it arrived in 1.7.8), so the
marketplace order comment was assigned to a property that was never saved. The write is now
guarded by the `Order` definition, so 1.7.8+ keeps the comment and 1.7.7 skips it instead of
silently losing it (found by the compatibility campaign, cell a).
* On PrestaShop 1.7.7 re-applying the same order state fires `actionOrderStatusPostUpdate` again
and queued a second `order.push_status` job for the same target status. The synchronizer now
checks for a pending or reserved push of that status before queueing (cell a, integration test
F18).
* Log CSV export passed no `$escape` argument to `fputcsv()`, which PHP 8.4 reports as deprecated
on every exported row (cell h). The argument is now explicit.
* A GPSR manufacturer phone number that wasn't already in E.164 format (the normal case, since the
back office's own fix-it form accepted anything) caused InPost to reject the entire offer. Phone
numbers are now normalised before sending, or omitted if they can't be, and the readiness check
flags a bad value before publish is attempted.
* InPost's field-level validation detail was parsed out of API error responses but never actually
shown anywhere - the back office and the stored error message both said only "Validation failed"
with no indication which field. The field and reason are now included in both places.
* An offer whose EAN was edited after listing was sent to the platform anyway and rejected outright
("Once assigned field cannot be changed"). Changed immutable fields are now dropped from the
outgoing update instead of being sent.
* An offer name, brand, SKU or attribute value longer than InPost's limit was silently truncated
with no warning; an EAN over its limit threw a plain exception that escaped the job handler as an
uncaught fatal instead of failing the offer cleanly. Both now surface as proper validation
warnings/errors before publish.
* Product images served from a URL InPost's fetcher couldn't reach caused every offer for that
product to be rejected with no visible reason in the back office. Image reachability is now
checked as part of readiness validation, bounded so a bad image host can't turn a bulk readiness
sweep into a multi-minute hang.
* An offer rejected by the platform after publish was only ever noticed if an event happened to
arrive for it; one that fell outside the event window could sit "W trakcie wystawiania"
indefinitely with no error shown anywhere. Offers stuck in that state for more than 20 minutes are
now re-checked directly.
* A cron job configured with a typo'd shop id received a silent redirect to the storefront instead
of an error, making a broken cron schedule look like it was working.
* Order import ran on a schedule from the moment the module was installed, even though status and
carrier mapping start out empty and nothing warned that orders couldn't be imported correctly
until the first real order failed to build. The diagnostics screen and the order list now warn
while either mapping is incomplete.
* The diagnostics/log screen scrolled the entire page sideways on narrower viewports instead of
scrolling just the log table, the way every other wide table in the module already did.
* Internal ticket references (`VH-09`, `VH-10`) were visible in order-settings headings shown to
shop operators; removed.