================= Changes in 3.4.x ================= The changes of the 3.4.x builds that affect the work of users and administrators, newest first. Internal (development) changes are not listed. Changes of the Czech description rules (ZP2015) and code lists (CZ_BASE) are listed only in the Czech documentation. Entries that require an action of the administrator (a configuration change, a step during the upgrade) name the configuration key and link to the relevant chapter. Before an upgrade, read the entries of all builds between the installed and the new version; see :doc:`/03-upgrade`. 3.4.12 ====== Fixes ----- * Fix: DA - a batch downloaded over File Transfer is accepted as the directory tree the DA communication standard prescribes (one directory per package); a single zip file delivered in place of the tree is accepted as well, while a zip inside the directory of a package is a part of that package. The download request sends the transfer type ``download`` defined by the standard when *File Transfer download request type* is empty; see :doc:`/08-digital-repositories`. * Fix: DA - a unit date in the archival description of a package written as an interval that closes within the period it opens (a day as D-D, a year as Y-Y) is read as that single period; the import of the package no longer ends with an unexpected error. * Fix: DA - a package delivered inside the batch as one zip file in the directory of the AIP, or with its own root directory (named by the UUID of the package) inside, is unwrapped and loaded; a package that cannot be read reports what it holds instead of the missing file. An AIP whose package the batch does not carry fails with the names the batch does carry, instead of being closed as loaded. * Fix: DA - a File Transfer download that failed is reported with the outcome of the transfer instead of a missing file; the cause is in the server log (``com.lightcomp.ft``). * Fix: DA - an action over AIPs (loading of metadata, update and repair) whose download fails finishes with the error instead of running until the queue succeeds; the queue keeps retrying the download, which is followed on the AIP and in the queue view. * Change: DA - the originator of a package (the agent of the creation event in PACKAGE-INFO.xml) is resolved by its CAM identifier (``agentIdentifierType`` ``CAM_ID``, the entity id or UUID in CAM) to the access point taken over from CAM, whatever its type. An identifier that matches no access point is recorded as the AIP problem *Nenalezen původce*; take the entity over from CAM and run *Aktualizace a oprava AIP*. A package without the identifier keeps the originator by name and has no problem. Such a package failed before with "Cannot parse null string". * Fix: DA - the result dialog of an action over AIPs shows the message of each AIP in a readable colour. 3.4.11 ====== Before the upgrade ------------------ * Change: 10146 - Security audit log (``elza.siemLogFile``): the field names follow the OSSEC/Wazuh schema (``srcuser``, ``dstuser``, ``srcip``, ``result``, ``reason``, ``msg``, ...), fields without meaning for a SIEM (``LOG_FILE``, ``SIEM_LOG_FILE``, ``@version``, ``logger_name``, ``thread_name``, ``level_value``) are removed and the events are identified by ``event_type`` and ``action`` (e.g. a login is ``user_login`` with ``result`` ``success`` or ``failed``). **The format is not compatible with the previous one; adjust the decoders and rules of the SIEM system.** See :doc:`/05-security`. * Change: 10146 - Behind a reverse proxy, the security audit log records the address of the client (``srcip``) when ``elza.security.acceptForwardedHeaders`` is enabled. **The proxy must replace the header** ``X-Forwarded-For`` **with the address of the client** (NGINX ``$remote_addr``, Apache ``RequestHeader unset X-Forwarded-For early``); otherwise a client can choose the logged address. See :ref:`reverse-proxy-client-address`. * Change: 10146 - The administrator from the configuration (``elza.security.admin.username`` / ``.password``) is replaced by the list ``elza.security.override`` of user names and passwords. A missing user is created as an administrator without a password in the database; a listed user logs in with their own password or with the configured one, which is no longer written to the database. **With** ``elza.security.admin.*`` **set, the application does not start**; move the entry to ``elza.security.override``. See :ref:`install-users-from-config`. * Removed: 10146 - Recovering access with ``elza.security.recovery.username`` and ``elza.security.recovery.password``; the keys are ignored. Access is recovered with ``elza.security.override``, whose use is written to the security audit log; see :doc:`/05-security`. **Remove the recovery keys from** :file:`elza.yaml`. New --- * New: 10146 - Security audit log - new events: logout, password change, creation, activation, deactivation and renaming of users (including the first administrator of the initial setup), changes of permissions of users and groups, group membership, creation and deletion of groups, creation (including an import) and deletion of archival funds and deletion of their history. A failed login states the method (``authentication_type``) and a stable reason (``INVALID_USERNAME``, ``INVALID_PASSWORD``, ``INACTIVE_USER``, ...); a rejected JWT is logged as well. A login with the password from ``elza.security.override`` is logged as ``OVERRIDE``, and every startup records the users with such a password (``override_active``). * New: 10161 - CAM - the external system has the option *Verify TLS certificate*; a new system verifies the certificate of CAM. Existing systems are set to *No* by the upgrade and keep trusting any certificate, as before. **Where CAM has a valid certificate, switch the option to** *Yes*. See :doc:`/07-integrations`. * New: 10188 - DA - the repository has the option *REST API authentication*: *None*, *API key* (NDA-HMAC-SHA256 signature) or *HTTP Basic* with the username and password of the repository, which File Transfer uses as well. The upgrade sets *API key* for repositories with both parts of the API key filled in and *None* for the others, so their behaviour does not change. The API key is stored only with the *API key* method. See :doc:`/08-digital-repositories`. Changes ------- * Change: 9800 - The text search of archival entities puts the entity whose name is typed the way it is commonly used first ("Petr Pytelka", "Československá akademie věd"). The names of CZ_BASE entities get the index ``REAL_NAME`` - the name without supplements and degrees, a person as forename and surname - and the whole search text is matched against it whatever the order of the words and the diacritics. After the upgrade the CZ_BASE entities are regenerated in the background (the queue of entity validation); the ranking improves as the run proceeds. A rules package states such a field in ``index-search`` with ``index-type``, see the implementation guide. * Change: 10146 - Security audit log - a successful login with a JWT or an API key, which is checked on every request, is logged at most once per hour for the same key (or user) and address; failures are always logged. * Change: 10133 - Digital archive: the change package carries the contextual archival description of the AIP (``EAD-CONTEXT.xml``) from ELZA - the fund root, the path to the units linked to the AIP and their subtrees - instead of a fixed sample. An AIP linked to units of more than one fund is not exported; the export reports it. See :doc:`/08-digital-repositories`. * Change: 10165 - EAD output of the ZP2015 rules follows the Czech EAD3 profile ``CZ_EAD3_PROFILE_20260501`` (new and corrected mappings, roles of entities given as text are written as weak entities). Units are identified by ``id="uuid-…"``; **the URI in** ``base`` **(https://archdesc.nacr.cz/dids/…) is no longer written** - adjust systems that read it. Units linked to the digital archive refer to the AIP (``dao href="aip:…"``). * Fix: 10181 - CAM synchronization stopped completely (since 3.4.9) when CAM reported an entity as replaced (merged) and its ELZA record was in another scope than the external system; the record was retried forever. Such entities are now replaced and invalidated as before. A record whose synchronization fails for any other reason no longer blocks the others: its item in the synchronization queue ends in the state ``ERROR`` with the reason, and the record is synchronized again from the user interface once the cause is resolved. * Fix: 10189 - Digital archive: when the request to the REST API could not be signed with the API key (e.g. an empty key value), it was sent with ``Signature=null`` and rejected by the archive without the cause in the log. The call now fails with the cause. * Fix: 10190 - Digital archive: the signature with the API key depended on the default charset of the system; a request whose path contained characters outside ASCII (e.g. an AIP identifier with diacritics) was rejected by the archive on Windows. The signed text is always UTF-8. 3.4.10 ====== Before the upgrade ------------------ * Fix: 10128 - Storage of binary files (DMS): the move into the new structure in 3.4.8 and 3.4.9 set aside the files with an identifier from 1000 to 9999 into ``dms/_migrating/`` and did not take them back; their attachments and outputs report "Požadovaný soubor neexistuje". At the first start, 3.4.10 runs the move again: it puts every file whose database row points elsewhere to its place. This repairs installations upgraded to 3.4.8 or 3.4.9 and is the only move for older ones. Files that no database row claims stay in ``dms/_migrating/``; nothing is deleted. **Before the upgrade, back up the database and the dms directory from the same moment** (see :doc:`/10-backup`); **after it, read the report** ``dms/_migration--