Informacje o wersji 1.14.9.0
z dn. 05-08-2025

W tej wersji

• Dodano funkcjonalność formularzy publicznych - użytkownik końcowy może bez zalogowania tworzyć instancje dokumentu biznesowego w nAxiom
• Na potrzeby formularzy publicznych dodano integrację z mechanizmem Google reCAPTCHA v3
• Dodano możliwości definiowania zaawansowanych reguł walidacji na poziomie definicji dokumentu
• Rozbudowano ustawienia kategorii załączników
• Zmodyfikowano tabelę core.UserTaskData
• Poprawiono błędy w różnych obszarach

Wymagane działania

• Modyfikacja core.UserTaskData :

  1. Podczas aktualizacji do bieżącej wersji tabela core.UserTasksData jest tworzona ponownie, dlatego przed aktualizacją zaleca się wyłączenie opcji Pokazuj instancje tego dokumentu na liście zadań użytkownika dla tych definicji dokumentu, dla których nie jest to konieczne.

  2. Wystąpienie zduplikowanej wartości ACLId dla instancji różnych definicji dokumentów uniemożliwi uruchomienie witryny po aktualizacji. Aby tego uniknąć, można sprawdzić tabele użytkownika w bazie danych przy użyciu poniższego skryptu. Zakłada się, że wszystkie tabele użytkownika są w schemacie dbo.

  DECLARE @sql NVARCHAR(MAX) = N'';
  DECLARE @tableName NVARCHAR(128);
  -- Cursor to iterate over tables with ACLId column
  DECLARE table_cursor CURSOR FOR
  SELECT t.name
  FROM sys.tables t
  JOIN sys.columns c ON t.object_id = c.object_id
  WHERE c.name = 'ACLId' AND SCHEMA_NAME(t.schema_id) = 'dbo';
  
  OPEN table_cursor;
  FETCH NEXT FROM table_cursor INTO @tableName;
  
  WHILE @@FETCH_STATUS = 0
  BEGIN
    SET @sql +=
      CASE
        WHEN LEN(@sql) = 0 THEN ''
        ELSE ' UNION ALL '
      END +
      'SELECT CAST(ACLId AS NVARCHAR(255)) AS ACLId, ''' + @tableName + ''' AS SourceTable FROM dbo.' + QUOTENAME(@tableName);
  
    FETCH NEXT FROM table_cursor INTO @tableName;
  END
  
  CLOSE table_cursor;
  DEALLOCATE table_cursor;
  
  -- Wrap the combined query to find duplicates and show their source tables
  SET @sql = '
  WITH AllACLIds AS (
    ' + @sql + '
  ),
  DuplicateACLIds AS (
    SELECT ACLId
    FROM AllACLIds
    GROUP BY ACLId
    HAVING COUNT(*) > 1
  )
  SELECT a.ACLId, a.SourceTable
  FROM AllACLIds a
  JOIN DuplicateACLIds d ON a.ACLId = d.ACLId
  ORDER BY a.ACLId, a.SourceTable;
  ';
  -- Execute the final query
  EXEC sp_executesql @sql;
  

• Zadania użytkownika :

  Sprawdzić, czy w definicjach widoków list z włączoną weryfikacją uprawnień ACL według szablonów statusów zapytania źródłowe zwracają kolumnę Status. Brak tej kolumny spowoduje, że widok listy nie będzie się wyświetlał.

Kompatybilność aplikacji

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

Bieżąca wersja bazy danych: 20250716083104

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. Formularze publiczne

Dodano funkcjonalność formularzy publicznych. Formularze publiczne są dostępne bez konieczności logowania pod adresem <adres_URL_witryny_nAxiom>/front/public/<adres_względny>, gdzie <adres_względny> jest elementem definicji formularza.

Na definicję formularza publicznego składają się:

• standardowe metadane (kod, nazwa, aplikacja, moduł, opis)
• język (kod języka zgodny z ISO; określa język komunikatów o błędach i tłumaczenia etykiet pól danych)
• definicja dokumentu: w tabeli powiązanej z tym dokumentem będą zapisywane dane z formularza, a załączniki będą trafiać do kategorii załączników powiązanej z tą definicją.
• HTML, CSS i Javascript formularza
• HTML i CSS stron wyświetlanych w przypadku powodzenia i niepowodzenia przesłania danych

W definicji formularza obsługiwane są style Bootstrap oraz biblioteki jQuery.js, Moment.js i DateRangePicker.js (https://www.daterangepicker.com/#examples). W panelu pomocy dostępne są dwa formularze przykładowe, które można skopiować do definicji i dostosować do swoich potrzeb. W jednym z nich użyto komponentu do dodawania załączników.

Aby dane z formularza mogły być zapisywane w tabeli powiązanej z wybraną definicją dokumentu, znaczniki kontrolek formularza muszą mieć atrybut name z wartością odpowiadającą nazwie kolumny z tabeli modelu danych. Nazwy tych kolumn są wyświetlane w panelu pomocy w oknie definicji formularza. Na przykład dane z pola tekstowego:

<input type="text" class="form-control" name="FirstName" placeholder="Wprowadź imię" required>

zostaną zapisane w kolumnie FirstName w tabeli powiązanej z definicją dokumentu.

Zapis danych z formularza publicznego wyzwala sprawdzanie reguł walidacji po stronie serwera konfigurowanych w oknie definicji dokumentu.

Punkty końcowe API obsługujący żądanie wyświetlenia formularza i zapis danych są chronione przez mechanizm rate limiter (maksymalnie 100 żądań na minutę). Z kolei punkt końcowy obsługujący zapis można zabezpieczyć przez mechanizm Google reCAPTCHA 3. Odpowiednie ustawienia znajdują się w TenantsAdmin SPA w sekcji Global settings.

2. Google reCAPTCHA v3

Dla nowej funkcjonalności formularzy publicznych dodano możliwość włączenia mechanizmu Google reCAPTCHA v3, który weryfikuje, czy dane są wysyłane przez człowieka. Odpowiednie ustawienia znajdują się w TenantsAdmin SPA (Global settings > Google reCAPTCHA v3). Mechanizm reCAPTCHA konfiguruje się dla witryny nAxiom, to jest dla wszystkich tenantów. Wymagane jest zarejestrowanie domeny witryny w usłudze Google reCAPTCHA. Rejestracja obejmuje domenę i wszystkie domeny podrzędne. Możliwe jest zarejestrowanie wielu domen dla różnych witryn nAxiom.

Wynikiem rejestracji jest przydzielenie klucza publicznego witryny (SiteKey) oraz klucza tajnego (SecretKey). Oba parametry należy podać w TenantsAdmin SPA. Dodatkowo należy skonfigurować parametr Acceptable scoring, to jest minimalną wartość oceny zwracanej przez reCAPTCHA, dla której weryfikacja będzie uznawana za pomyślną (zwracane wartości należą do zakresu od 0 do 1). W przypadku oceny niższej od podanej wartości, dane z formularza nie zostaną zapisane i nastąpi przekierowanie na stronę komunikatu o błędzie. Dodatkowo zostanie zalogowana informacja o niepowodzeniu weryfikacji.

Włączenie mechanizmu reCAPTCHA spowoduje dodanie do kodu HTML formularza publicznego nagłówka:

<script src="<https://www.google.com/recaptcha/api.js?render=klucz_publiczny_witryny>"></script>

Kiedy użytkownik kliknie przycisk wysłania danych formularza, skrypt wyśle żądanie do API reCAPTCHA w celu uzyskania tokenu. Następnie token zostanie przekazany wraz z danymi formularza do punktu końcowego API nAxiom. Ten punkt przed zapisaniem danych wyśle żądanie weryfikacji, podając w nim przekazany token i klucz tajny. Odpowiedź w formacie JSON wygląda następująco:

{
"success": true|false,      // określa, czy przesłany token reCAPTCHA dla danej witryny był prawidłowy
"score": number             // wynik oceny żądania (0.0 - 1.0)
"action": string            // nazwa akcji dla tego żądania (na potrzeby weryfikacji)
"challenge_ts": timestamp,  // datownik wczytania wyzwania (format ISO yyyy-MM-dd'T'HH:mm:ssZZ)
"hostname": string,         // nazwa hosta witryny, dla której wykonano weryfikację reCAPTCHA
"error-codes": [...]        // opcjonalne kody błędów
}

Ponadto skrypt generuje logo mechanizmu reCAPTCHA w prawym dolnym rogu formularza.

Uwagi:

1. Bezpłatny limit dla usługi Google reCAPTCHA wynosi 10 tysięcy żądań na miesiąc dla jednorazowo zarejestrowanych domen. Po przekroczeniu limitu usługa może stale zwracać wynik weryfikacji równy 0,9.
2. Korzystanie z Google reCAPTCHA wymaga otwarcia połączeń do domen:
   • http://www.google.com
   • www.gstatic.com
   • fonts.gstatic.com

3. Opcje dostępu publicznego w Tenantsadmin SPA

Rozbudowano globalne ustawienia w TenantAdminSPA pod kątem zabezpieczenia punktów końcowych API z dostępem anonimowym oraz zabezpieczenia formularzy publicznych za pomocą Google reCAPTCHA V3.

• Wprowadzono ustawienie limitu żądań dla następujących punktów końcowych API:
  • pobranie formularza publicznego,
  • zapis formularza publicznego.

  Limit określa maksymalną dozwoloną liczbę żądań na minutę dla danego adresu IP. Brak wartości oznacza brak limitu. Zmiany limitów wymagają ponownego uruchomienia serwisów z przyczyn technicznych i braku możliwości modyfikacji tych limitów dynamicznie w trakcie działania aplikacji.

• Wprowadzono możliwość konfiguracji Google reCAPTCHA V3.

  Konfiguracja została wprowadzona na poziomie globalnym witryny z uwagi na zgodność konfiguracji Google reCAPTCHA z modelem wielu tenantów w systemie nAxiom. Konfiguracja pozwala na włączenie lub wyłączenie zabezpieczenia formularzy publicznych poprzez detekcję botów. Po włączeniu weryfikacji należy podać klucz publiczny i klucz prywatny dla integracji z Google reCAPTCHA. Klucze są wymagane i muszą mieć 40 znaków. Należy także podać akceptowalną wartość oceny z zakresu od 0.0 do 1.0. Domyślnie akceptowalna wartość to 0.5. Im wyższa wartość zwrócona przez API weryfikujące token captcha tym wyższe prawdopodobieństwo, że formularz został wysłany przez człowieka.

Zmiany w konfiguracji wymagają ponownego uruchomienia serwisu API. Planowane są zmiany znoszące to wymaganie.

4. Walidacje po stronie serwera

Definicję dokumentu rozbudowano o kartę Walidacje po stronie serwera. Na tej karcie można zdefiniować reguły walidacji dla definiowanych przez użytkownika pól modelu danych (także kilka reguł dla tego samego pola). Nie można definiować reguł walidacji dla pól systemowych.

Reguły walidacji są sprawdzane przed zapisem instancji dokumentu (akcja zapisu, zapis z formularza publicznego, zapis z Public API, zapis instancji dokumentu dla podprocesu, mail monitor, zapis danych dodatkowych użytkownika/organizacji).

Reguły walidacji nie są sprawdzane w przypadku akcji importu dokumentów.

Dostępne typy walidacji (operatory) zależą od typu danych pola. Oprócz standardowych operatorów dla danych liczbowych i tekstowych dostępny jest np. typ walidacji Predicate, który sprawdza czy wartość reguły jest równa 1. Umożliwia to napisanie dowolnego SQL który wykona walidację i zwróci wartość równą 1 w przypadku sukcesu a różną od 1 w przypadku błędu walidacji. Inny przykład typu walidacji to RegexMatch, który sprawdza czy wartość dla danego pola modelu spełnia wyrażenie regularne przekazane jako wartość reguły.

Dla każdej reguły walidacji można dodatkowo zdefiniować warunek sprawdzania danej reguły. Reguła zostanie sprawdzona tylko wtedy, gdy warunek sprawdzania będzie spełniony.

Komunikaty walidacji obsługują tłumaczenia (na język użytkownika, lub w przypadku formularzy publicznych język formularza). Nazwy pól których dotyczy dany błąd walidacji pochodzą z tłumaczeń dla pola Etykieta z kreatora modeli danych.

Reguły walidacji zaimplementowano w oparciu o bibliotekę .NET FluentValidation.

5. Ustawienia kategorii załączników

W definicji kategorii załączników oraz w ustawieniach systemowych dodano parametry maksymalnego rozmiaru pliku załącznika w kilobajtach. W nowych środowiskach domyślny rozmiar maksymalny dla pliku to 51200 KB w ustawieniach systemowych oraz 10240 KB dla nowych kategorii załączników.

W polach maksymalnego rozmiaru oraz dozwolonych rozszerzeń dodano obsługę smart numbers.

Zmodyfikowano zachowanie nAxiom w obszarze dozwolonych rozszerzeń nazw plików. Obecnie w kategorii załączników można wskazać rozszerzenie spoza listy w ustawieniach systemowych. Ustawienia systemowe są stosowane tylko wtedy, gdy rozszerzenia dla kategorii nie zostaną określone. Jeśli w ustawieniach systemowych nie będzie określonych rozszerzeń, domyślnie będą obsługiwane następujące rozszerzenia:

• Microsoft Office: docx, doc, xlsx, xls, pptx, ppt, ppsx, potx.
• Inne: pdf, csv, txt, jpg, jpeg, png, zip, svg.

Zasady weryfikacji rozmiaru plików są identyczne jak dla rozszerzeń: pierwszeństwo mają limity z definicji kategorii, a jeśli nie zostaną podane, limity z ustawień systemowych. Należy przy tym pamiętać, że bezwzględny priorytet ma ustawienie serwera IIS.

Dodatkowo zmodyfikowano okno dialogowe wyboru plików, aby dozwolone rozszerzenia plików były też ustawiane w filtrze plików.

W celu poprawy wydajności obsługi załączników zaimplementowano cache dla takich elementów jak kategorie załączników, repozytoria załączników i źródła danych. Do momentu wydania wersji nAxiom z kolejką RabbitMQ, po modyfikacji wyżej wskazanych elementów aplikacji wymagane jest ponowne uruchomienie serwisów innych niż API, aby uwzględniły wprowadzone zmiany.

6. Modyfikacja core.UserTaskData

W celu eliminacji zakleszczeń bazy danych podczas wyświetlania widoków list i wywołania funkcji core.UserTasks_View zmieniono sposób aktualizacji tabeli core.UserTasksData na asynchroniczny. Do zakleszczeń dochodziło podczas próby pobrania danych z tej tabeli w trakcie jej aktualizacji. Dodatkowo usunięto kolumnę ACLEntryId i dodano kolumnę ACLId jako kolumnę klucza głównego, co pozwala ograniczyć liczbę rekordów w tej tabeli do jednego na dokument.

Wprowadzając zmiany założono, że wszystkie wartości ACLId w bazie danych są niepowtarzalne. To wynika ze sposobu ich tworzenia. Gdyby jednak tak nie było, migracja bazy danych do nowej wersji nie powiedzie się i witryna nie uruchomi się po instalacji nowej wersji.

7. Transakcje w mail monitorze

W działaniu mail monitora wprowadzono zmiany polegające na tym, że błąd wykonania akcji post procesu powoduje usunięcie nowo utworzonej instancji dokumentu oraz dodanych załączników. Do tej pory w takim przypadku pozostawał nowy dokument z załącznikami. Obecnie proces obsługi każdej odebranej wiadomości e-mail działa na zasadzie „wszystko albo nic”.

Na poprawną obsługę wiadomości składa się:

• pobranie wiadomości,
• utworzenie instancji dokumentu,
• obsługa załączników wiadomości,
• wykonanie akcji post procesu.

Poprawki i usunięte błędy

1. Zadania użytkownika

Wyłączono aktualizację danych zwracanych przez funkcję core.UserTasks_View, jeśli w definicji dokumentu opcja Pokazuj instancje tego dokumentu na liście zadań użytkownika jest wyłączona. Ponadto, zmodyfikowano sposób obsługi uprawnień ACL dla list, w związku z tym zapytanie listy musi zwracać kolumny:

• AclId: w przypadku włączonej walidacji uprawnień dla statusów lub instancji; obecność tej kolumny była dotychczas wymagana, ale nie była sprawdzana; obecnie dodano walidację na zapisie definicji listy.
• Status: w przypadku walidacji uprawnień ACL dla statusów; obecność tej kolumny była wymagana do wersji 1.9, potem kolumna nie była wymagana.

Do zapytania zwracającego rekordy z uwzględnieniem uprawnień ACL dodano dyrektywę DISTINCT, aby nie zwracało zduplikowanych rekordów.

Wprowadzone zmiany mają na celu poprawę wydajności systemu.

2. Powtarzanie żądań do TenantAPI

Dodano mechanizm powtarzania żądań do TenantAPI w przypadku błędów połączenia lub przekroczenia czasów oczekiwania. Mechanizm korzysta z klucza HttpRetryDelaysInMs z domyślnymi wartościami 500, 1000, 2000, 4000 w plikach appsettings.json poszczególnych serwisów. Wartości to lista interwałów oczekiwania pomiędzy powtórnymi żądaniami wyrażona w milisekundach.

Niepowodzenie żądania do TenantAPI powodowało na przykład zablokowanie zadań wykonywanych przez Taskservice i wymagało restartowania odpowiedniej puli aplikacji. Problem w szczególności dotyczył środowiska Windows IIS.

3. Puste pliki załączników

Zmodyfikowane obsługę plików dodawanych jako załączniki na formularzu oraz przez żądania do PublicAPI. Obecnie nie można dodawać pustych plików.

4. Ukrywanie sekcji

Zmodyfikowano zachowanie formularza w przypadku ukrywania sekcji skryptem Javascript dla zmiany kontekstu formularza. Jeśli w danej kolumnie formularza nie ma innych aktywnych sekcji, cała kolumna zostanie ukryta. Do tej pory pusty kontener kolumny pozostawał widoczny jak puste miejsce na formularzu. W przypadku ukrywania sekcji akcją Javascript można osiągnąć ten efekt, używając kodu:

const element = document.querySelector('[data-code="<kod-kolumny>"]');
if (element) {
  element.style.display = 'none';
}

Wskazówka: w celu ukrycia sekcji w skrypcie na zmianę kontekstu formularza można używać funkcji wbudowanej setSectionAsHidden("\<kod-sekcji\>").

5. Ikona workflow

Poprawiono błąd, który powodował, że po odświeżeniu formularza znikała ikona workflow.

6. Grupowanie rekordów na listach

Przywrócono wyświetlanie przycisków zwijania/rozwijania zgrupowanych rekordów na liście.

7. Sygnalizacja walidacji

Przywrócono sygnalizację błędów walidacji kontrolek formularza w przypadku, gdy przycisk Zapisz był objęty grupowaniem przycisków.

8. Sygnalizacja walidacji

Uzupełniono wskazanie sekcji z nieustawionymi wartościami wymaganymi w przypadku grupy przycisków typu radio.

×