sdarbinyan/marketplaces
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(admin): move locale-hardcoding gap from Open to Fixed

Browse Source 
Follow-up to ff4fba3 - the admin/products + admin/categories
translation-tab locale-hardcoding gap flagged as deferred in the
bug-hunt audit docs is now fixed; updates docs/ADMIN.md's audit
section and moves docs/KNOWN-ISSUES.md's item from Open to Fixed.
This commit is contained in:
sdarbinyan
2026-07-17 22:25:58 +04:00
parent ff4fba379f
commit 6be3c5892d
2 changed files with 30 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
docs/ADMIN.md
View File

@@ -594,16 +594,25 @@ Found 2 real bugs in `admin/categories`, both fixed:
`{ id: 'c', order: 0 }` (tying `a` and `c`). After the fix, the gateway
receives the correct 3-way reshuffle: `c:0, a:1, b:2`.
One real gap was found but **not** fixed inline (real feature work, not a
wiring bug - see `docs/KNOWN-ISSUES.md`): both `admin-product-form.component`
and `admin-category-form.component` hardcode their translation-tab locales to
`['en', 'ru', 'hy']` rather than reading the tenant's actual configured
`supportedLocales` (which live on `ProjectEditorFacade.bootstrap()`, the same
source `static-pages-editor.component.ts` already reads correctly). Wiring
this up means threading `supportedLocales` from `ProjectEditorFacade` through
`AdminProductsFacade`/`AdminCategoriesFacade` (neither currently depends on
project-editor state at all) down to two presentational form components -
real cross-feature plumbing, not a bounded bug fix.
A third bug, found in the same pass, was fixed in a follow-up commit:
`admin-product-form.component` and `admin-category-form.component` both
hardcoded their translation-tab locales to `['en', 'ru', 'hy']` instead of
reading the tenant's actual configured `supportedLocales` (which live on
`ProjectEditorFacade.bootstrap()`, the same source
`static-pages-editor.component.ts` already reads correctly) - neither
`AdminProductsFacade` nor `AdminCategoriesFacade` depended on project-editor
state at all before this. Fixed by giving both facades a `supportedLocales`
computed (`bootstrap()?.localization.supportedLocales ?? ['en']`) and an
`ensureLocalesLoaded()` that calls `ProjectEditorFacade.loadBootstrap()` if
it hasn't loaded yet (same lazy-load pattern
`AdminDashboardFacade.ensureLoaded()` already uses for the same dependency);
both editor pages call it in their constructor and pass
`[locales]="facade.supportedLocales()"` down to the form components, which
now iterate a `locales: string[]` `@Input()` instead of the literal array.
Verified live: both `facade.supportedLocales()` and the form's bound
`locales` changed from the hardcoded `['en','ru','hy']` to the real tenant
order `['ru','en','hy']` (default locale first), confirmed by the rendered
tab order in both editors.
The already-documented, deliberately-scoped-down items from earlier sprints
(related-products picker limited to the current page, not a full catalog