|
22 | 22 | * COLUMNS both work in this deployed shell, so it is the canonical |
23 | 23 | * UI-driven CRUD subject. |
24 | 24 | * - Component (`module` schema) + Moduleversie — persistence proven at the |
25 | | - * OpenRegister data layer (real create/find/update/delete verbs). Their |
26 | | - * UI-create paths are NOT headlessly drivable here (the Component schema |
27 | | - * has no manifest index page; the Moduleversie create form is blocked by a |
28 | | - * `maxLength: null` validation bug), so the UI legs are documented |
29 | | - * test.fixme. Organisatie has its own spec (organisatie-crud.spec.ts). |
| 25 | + * OpenRegister data layer (real create/find/update/delete verbs) AND the |
| 26 | + * Moduleversie UI-create leg is now driven end-to-end through the manifest |
| 27 | + * create modal (was previously blocked by a `maxLength: null` validation |
| 28 | + * bug on the `versie`/`pakketversie_beschrijving`/`beschrijvingLang` string |
| 29 | + * properties — fixed in the register schema, see the UI-create test below). |
| 30 | + * The Component schema still has no manifest index page, so its UI-create |
| 31 | + * leg is data-layer only. Organisatie has its own spec |
| 32 | + * (organisatie-crud.spec.ts). |
30 | 33 | * |
31 | 34 | * NOTE on other index pages: Contract (schema 41) requires object-reference |
32 | 35 | * fields (`dienst`/`gebruik`) with no guaranteed referents; Reviews/Compliance |
@@ -312,15 +315,18 @@ test.describe('Component (module) + Moduleversie persistence', () => { |
312 | 315 | expect(del.ok()).toBeTruthy() |
313 | 316 | }) |
314 | 317 |
|
315 | | - // BUG (deployed nextcloud-vue CnIndexPage form validation): a string schema |
316 | | - // property declared with an explicit `maxLength: null` (moduleVersie.versie, |
317 | | - // pakketversie_beschrijving, beschrijvingLang) makes the create form render |
318 | | - // "Maximum null characters." for any typed value and refuse to save — the |
319 | | - // "Create" click never closes the dialog, so a Moduleversie can NOT be |
320 | | - // created through the UI. (Creation via the OR API succeeds — see the |
321 | | - // data-layer test above — so it is a FORM-VALIDATION defect, not a backend |
322 | | - // one.) Re-enable this UI leg once the validator treats `maxLength: null` as |
323 | | - // "no maximum". |
| 318 | + // REGRESSION GUARD (was a real bug): the moduleVersie create modal used to |
| 319 | + // refuse to save because the `versie` / `pakketversie_beschrijving` / |
| 320 | + // `beschrijvingLang` string properties were declared with an explicit |
| 321 | + // `maxLength: null`. The CnIndexPage form validator rendered "Maximum null |
| 322 | + // characters." for any typed value and blocked the "Create" click, so a |
| 323 | + // Moduleversie could not be created through the UI (a direct OR API create of |
| 324 | + // the same payload persisted fine, and the contactpersoon manifest create |
| 325 | + // worked — an isolated create-flow defect on the moduleVersie surface). |
| 326 | + // FIX: removed the `maxLength: null` declarations from those string |
| 327 | + // properties in lib/Settings/softwarecatalogus_register.json (absent = "no |
| 328 | + // maximum", matching the working contactpersoon string fields). This test |
| 329 | + // drives the real manifest create modal and asserts the new version persists. |
324 | 330 | test('UI create -> module-version row appears', async ({ page }) => { |
325 | 331 | await navClickTo(page, 'Module versions') |
326 | 332 | const main = indexMain(page) |
|
0 commit comments