Printer icon

Informacje o wersji 1.15.6.2
z dn. 25-03-2026

W tej wersji

Wymagane działania

  • Konfiguracja i walidacja dozwolonych typów załączników :

    Migracja związana z tą zmianą ustawi dozwolone typy plików na podstawie rozszerzeń zdefiniowanych w ustawieniach systemowych oraz we wszystkich kategoriach załączników w danym tenancie. Do listy dozwolonych nie zostaną jednak dodane typy plików określone w kategoriach za pomocą smart numbers. W takich przypadkach konieczne będzie ręczne dodanie typu pliku kodowanego przez smart numbers do ustawień w tenancie.

    WSKAZÓWKA

    Ustawienia w kategoriach załączników pozostaną bez zmian, zarówno w przypadku jawnego podania rozszerzeń, jak i za pomocą smart numbers.

Kompatybilność aplikacji

Migracja aplikacji jest możliwa tylko między wersjami nAxiom kompatybilnymi na poziomie bazy danych.

Bieżąca wersja bazy danych: 20260313101300

W tej wersji nAxiom struktura bazy danych zmieniła się. Przed migracją aplikacji do tej wersji wymagane jest zaktualizowanie środowiska źródłowego.

Nowe i zmodernizowane funkcje

1. Konfiguracja i walidacja dozwolonych typów załączników

Rozbudowano obsługę konfiguracji typów plików dla załączników oraz sposób ich walidacji w API i modułach administracyjnych.

Najważniejsze zmiany:

  • Zmieniono sposób walidacji formatu pliku; obecnie, w większości przypadków, weryfikowana jest sygnatura pliku.
  • Konfigurację dozwolonych formatów pliku dla załączników przeniesiono do ustawień tenanta.
  • Jeśli lista dozwolonych plików jest pusta, typy plików załączników nie są walidowane. Rozszerzenia plików określone w katagoriach załączników są w takim przypadku ignorowane.
  • Rozszerzono zestaw obsługiwanych formatów plików (pełna lista w dokumentacji ).
  • Uzupełniono domyślne typy plików o svg.

Zmiana zwiększa bezpieczeństwo i przewidywalność przesyłania plików oraz ogranicza ryzyko akceptowania niepożądanych formatów.

Informacja

Po aktualizacji należy zweryfikować konfigurację dozwolonych typów plików dla tenantów, aby potwierdzić zgodność z polityką bezpieczeństwa organizacji.

2. Kontrola ACL dla operacji na załącznikach

Wprowadzono następujące zmiany w mechanizmie sprawdzania uprawnień dla załączników, w tym także wersji załączników:

  1. Usunięcie załącznika wymaga uprawnienia ACL do modyfikacji instancji dokumentu do której dołączony jest załącznik. Wcześniej ta operacja wymagała uprawnienia ACL do usuwania instancji.
  2. Podczas dodawania/usuwania załącznika z poziomu sekcji załączników na formularzu weryfikowane są uprawnienia ACL do instancji dokumentu, której dotyczy operacja. Do tej pory w tym przypadku walidowane były wyłącznie uprawnienia zdefiniowane na poziomie formularza (dodawanie/usuwanie dla sekcji załączników). Teraz weryfikowane będą zarówno uprawnienia do instancji dokumentu jak i do sekcji formularza.

3. Uprawnienia ACL dla listy rozwijanej i sekcji formularza

Przebudowano logikę sprawdzania uprawnień ACL dla kontrolek list rozwijanych i sekcji formularza innych niż sekcja pól formularza. Obecnie, aby API zwróciło dane do listy rozwijanej lub sekcji, użytkownik musi mieć uprawnienie do odczytu tej listy/sekcji. W przypadku, gdy kontrola uprawnień ACL jest wyłączona, ale są zdefiniowane ustawienia dostępności SQL, dane zostaną przesłane do kontrolki tylko wtedy, kiedy będzie ona widoczna. Celem zmian jest uniemożliwienie dostępu do danych w przypadku braku uprawnień poprzez wysyłanie preparowanych żądań API.

4. Ochrona pól modelu i pola techniczne formularza

W kreatorze modeli danych we właściwościach pola modelu danych (każdego typu) dodano właściwość Dostęp chroniony (domyślnie wyłączona). Po włączeniu tej właściwości, jeśli widoczność powiązanej z polem kontrolki zostanie wyłączona (uprawnieniami ACL lub ustawieniami dostępności), dane z tego pola nie będą przesyłane do kontekstu formularza.

W ramach tego zadania w kreatorze formularzy dodano kartę Pola techniczne, na której można definiować pola formularza niepowiązane z polami modelu danych. Pola techniczne sa dostępne w kontekście formularza. Dla pola można zdefiniować typ danych (string, number lub boolean) oraz wartość domyślną dla nowego rekordu i rekordu istniejącego. Wartości pól technicznych można ustawiać funkcją Javascript (skrypt na zmianę kontekstu formularza) przez odwołanie formContext.nazwaPolaTechnicznego. W innych przypadkach można stosować standardowe odwołania {@nazwaPolaTechnicznego}.

5. Zasady dostępu do aplikacji SPA w nAxiom

Zmodernizowano obsługę dostępu do serwisów SPA w zależności od roli systemowej użytkownika. Obecnie użytkownik z rolą systemową inną niż konsultant zawsze jest kierowany do aplikacji Front SPA, natomiast konsultant ma dostęp tylko do serwisów związanych z budową aplikacji.

Poprawki i usunięte błędy

1. Unieważnianie tokenu

Zmodyfikowano zasady dotyczące ważności tokenu dostępu przez internal api. Obecnie po wylogowaniu użytkownika token jest natychmiast usuwany z pamięci podręcznej API. Próba jego ponownego wykorzystanie spowoduje zwrócenie błędu 401.

Ponadto dodano mechanizm powodujący, że zablokowanie konta użytkownika przez administratora spowoduje natychmiastowe wylogowanie zablokowanego użytkownika.

Zmiana poprawia bezpieczeństwo i spójność zachowania sesji po wylogowaniu użytkownika oraz blokadzie jego konta.

2. Przekazywanie tokenu dostępu

W celu podniesienia bezpieczeństwa zmodyfikowano sposób nawiązywania połączenia z WebSocket. Token dostępu nie jest już przekazywany poprzez adres URL, tylko przez specjalny plik cookie.

3. Odświeżanie tokenu w aplikacjach SPA

Naprawiono problem z odświeżaniem tokena w WorkflowSPA oraz BpmnSPA. Problem powodował, że po okresie bezczynności nie można było wznowić pracy na otwartej karcie z diagramem procesu lub modelem decyzyjnym. Komunikat informował, że użytkownik nie jest zalogowany.Obecnie token jest odświeżany do czasu wylogowania użytkownika z AdminSPA.

4. Załączniki - walidacja rozmiaru

Dodano sprawdzanie maksymalnego rozmiaru pliku podczas nadpisywania załącznika. Użytkownik otrzymuje czytelny błąd walidacji przed zapisem zbyt dużego pliku.

5. Weryfikacja ACL przy pobieraniu załączników

Dodano weryfikację uprawnień ACL przy próbie pobrania załącznika żądaniem z pominięciem GUI. Aby pobrać załącznik z danej instancji dokumentu, użytkownik musi mieć uprawnienie ACL do odczytu tego dokumentu.

6. Uszczelnienie dostępu przez URL

Dodano mechanizm zabezpieczający dostęp przez URL do funkcji we FrontSPA, dla których pozycje menu nie są wyświetlane, np. ze względu na brak uprawnień PBA do ustawień systemowych bądź brak uprawnień roli do pozycji menu aplikacji biznesowej. W przypadku pozycji menu dla aplikacji biznesowych, w definicji listy dodano ustawienie Dostęp dla posiadaczy ról globalnych. W tym polu należy wybrać role, których posiadacze mogą wyświetlić listę powiązaną z danym dokumentem. W ramach zadania uszczelniono także dostęp do endpointów API umożliwiających pobieranie danych.

7. Eliminacja dyrektyw unsafe-inline/eval

Zmodyfikowano domyślne wartości polityki Content Security Policy. Z domyślnych odpowiedzi API usunięto dyrektywy unsafe-inline oraz unsafe-eval. Zmiana ma wpływ na serwis uwierzytelniania nAxiom. Te dyrektywy pozostały niezmienne dla raportów Telerik z uwagi na mechanikę działania tego komponentu systemu.

8. Raporty - konfiguracja timeout dla komend

W pliku appsettings.json dla aplikacji reportsapi dodano ustawienie:

"ReportCommandTimeoutInSeconds": 120

Gdy ma ono wartość większą od 0, domyślny czas DbCommand (30 sekund) jest nadpisywany przez tę wartość. Zmiana pozwala ograniczyć ryzyko przekroczenia limitu czasu dla zapytań raportów.


Copyright © 2025 OPTEAM SA. Theme Copyright © 2017-2020 Patrick Marsceill. Distributed by an MIT license.