================= 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.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`. 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. 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--