vendor 1.5.0

Upgrade

• Five database migrations run at start-up: 019 (RoI columns), 020 (subcontractor type of person), 021 (subcontractor additional identifier), 022 (vendor-maturity settings), 023 (questionnaire templates).
• Questionnaire links now open on the public vendor portal by default; set VENDOR_PORTAL_URL to keep them on a self-hosted portal.
• New routes: PATCH /projects/{id}/maturity-config; a version conflict (409) carries the header X-CT-Conflict: stale.

Added

• PATCH /projects/{id}/maturity-config writes the maturity configuration alone
• The subcontractor identity offers an additional identifier
• Subcontractor type of person, linked arrangement only for intra-group providers, rank checked against the subcontractors served, a LEI-only parent shown with what is missing
• The RoI screens offer the new fields and no value without an EBA code
• Consolidation type and hierarchy, open-ended, data stored and linked arrangement fields (migration 019)
• In the RoI Excel export, a cell left empty although the EBA data model requires it is red
• A questionnaire's Excel export is written in its own language
• Each default questionnaire exists in French and in English, identical question for question
• A questionnaire link opens on the public vendor portal by default, VENDOR_PORTAL_URL to self-host

Fixed

• One file opened at a time, and a save due goes out when the file cannot be read
• No project save or focus refresh while a file is being opened
• A file whose save fails leaves the project as it was
• A file opened into the project is saved once loaded, with its own DORA register
• The project save never writes back the DORA register loaded with the page
• Template version and question weight are escaped when rendered
• A restore clears a value of the wrong type and drops a template of the wrong shape
• Questionnaire templates are saved with the project (migration 023) — the whole-project save carried them, the server dropped them
• DORA rows are written table by table in foreign-key order — Postgres refused a branch before its entity, failing a restore or a whole-project save
• A restored or imported project goes through the input checks — values outside their lists and orphan references cleared, orphan rows dropped; a new project refuses two records with one code
• A 403 keeps its reason (the body is read once); a save refused for lack of rights is said in red, without an alert or a reload
• A refused save says the server's reason; only a version conflict shows the reload message; refused or failed edits shown in red
• The version-conflict 409 carries X-CT-Conflict: stale
• The maturity-config PATCH requires its field — an omitted one is refused, null resets
• The maturity configuration is written through its own route, sent when the page is left
• Maturity edits are written at once again — the shared save timer dropped chained edits and edits on leaving the page; an emptied setting shows its value once left
• The header follows the maturity while typing; escaped selectors; marks and emptied weights resynced; saves once typing pauses
• Maturity fields carry stable ids, the focus survives the one-off DORA re-render
• Maturity numbers apply as typed and refresh the computed cells in place; the field is marked when out of range; the panel keeps the state the user left it in
• Maturity numbers are saved when left, the panel stays open, the risk filter keeps the hidden columns
• A composed character is dispatched once in the Firefox and Safari event order too (socle)
• A character composed with a dead key or an IME is dispatched once, complete (socle)
• A maturity number out of range is marked and not kept
• A restored backup goes through the maturity-settings rule
• A cleared weight override is sent as null
• An assessment's weight override and exclusion, and the project's maturity configuration, are saved
• The vendor tab is not rebuilt under a field being edited; the taken message goes with the edit
• A stored identifier type without an EBA code does not block an unrelated change
• A taken code is said on the field it was set in (GLEIF too), no half-typed LEI or identifier kept, a refused project save is said and reloads
• Only a code a record gains is refused, by the EBA code of its type; the project save checks subcontractors; types without an EBA code refused
• A taken code is said under the field, in the vendor tab and the subcontractors table
• A code another vendor or subcontractor carries is refused on screen and not kept
• The project save refuses a new duplicate vendor code too
• A subcontractor without a LEI is identified by its additional identifier; a code another record carries is refused
• The parents of a vendor signing for a provider are reported in B_05.01
• The screen compares LEIs as the server does
• One LEI key for export, server and screen; a vendor signing for a provider is reported in full
• An arrangement keeps its vendor on screen; a new one offers the linked arrangement until its vendor is picked
• One spelling per LEI key, one row per code in B_01.02, B_05.01 and B_05.02, a provider's signing entity reported in B_05.01
• A subcontractor LEI is one key in B_05.01 and B_05.02, whatever its case
• The overarching and linked arrangement pickers list the register's arrangements
• RoI export passes the EBA key checks
• Resolve the three RoI model flags the data model leaves unreadable
• A rank n-1 of another rank is refused on screen; one B_03.02 row per key, empty ones too; a former LEI parent in upper case; linked arrangements of a removed vendor cleared
• No internal id or duplicate key in B_03.02, a removed parent is never exported as a LEI, the cited parent has its own B_05.01 row, unknown storage shows red, rank n-1 checked, orphan references cleared
• A list value with no EBA code key is not offered either
• RoI values that were wrong though present — rank n-1 recipient, entity performing a function, exit plan not stated, alternative not assessed, impact from the list
• The RoI export fills every required column the EBA FAQ settles — open dates, Not Applicable, own code without a group, intra-group rows, no internal ids
• A vendor's ultimate parent picked among the project's vendors is saved
• B_02.02 0160–0180 belong to B_02.02 in the EBA model; the export's columns are checked against it; the legend says what empty means
• No duplicate default template id after a language edit; the vendor e-mail and the Excel validation messages in the questionnaire's language
• A portal setting that is refused or cannot be read keeps links on the deployment's own portal; the help says where links open
• A DORA load invalidated meanwhile no longer writes its tree to the cache
• A DORA load's callers run on their own; invalidate forgets a load in flight
• The list re-rendered once the DORA tree arrives keeps the typing; one DORA load at a time
• The vendor, subcontractor and risk filters keep the focus while typing
• One lock predicate for approved and legacy completed assessments; exports of a locked legacy one carry what the screen shows
• Opening a locked legacy assessment does not heal or save the templates
• A locked legacy assessment opens on a copy, never written; no delete or import into an approved one; a lock refusal says so
• An approved assessment is locked — no change through PATCH or the project save, not removable, read-only in the app

Tests

• Failed file save, DORA left out or null
• File opening saves its DORA once loaded; wrong types are cleared
• Wrong types, template shapes, DORA kept by the project save
• DORA rows are restored in foreign-key order (SQLite foreign keys on)
• A stored type is kept on rename, a new one without an EBA code refused
• One row per empty key, upper-case former parent, linked arrangements cleared, rank n-1 refused on screen
• The red marking on a B_02.02 sheet