Blog

Strona Known Limitations w Tailoring guide dla IFS Cloud zawiera sekcję „Custom Attributes on Assistants”. Otworzyłem ją w dokumentacji 24R1 i 25R1, a obie wersje mają ten sam tekst. Sekcja zestawia zwykłe strony aplikacji, na których użytkownik wyszukuje dane, zmienia lub dodaje informacje i jawnie zapisuje, z asystentami, które według dokumentacji mają elastyczną implementację dopasowaną do zadania. Wniosek (w moim tłumaczeniu): obecnie nie można dodawać custom attributes do asystentów.

Ta strona nie wspomina o dialogach. Ta luka ma znaczenie, bo w codziennej rozmowie „pole własne” (Custom Field) oznacza i framework Custom Attributes, i pole widoczne na ekranie, a udokumentowane zdanie jest węższe niż problem, który zgłaszają użytkownicy. Dla dialogów jedynym dowodem, jaki mogłem otworzyć, jest wątek społeczności opisany niżej.

Wprowadzenie do Page Designera (narzędzia do zmiany standardowego układu i zachowania stron) w Tailoring guide 25R1 dodaje jedną istotną informację. Na liście możliwości jest konfiguracja kroków asystentów, a obok uwaga, że dialogi i asystenci mają ograniczone możliwości konfiguracji w porównaniu ze zwykłymi stronami. Żadne z tych zdań nie obiecuje dodania nowego pola.

Wątek „Missing CUSTOM Functions in Dialog and Assistant Views in IFS Cloud” zawiera jedno pytanie i dwie odpowiedzi z okresu 12 do 17 marca 2026, jest oznaczony jako 25R1 i rozwiązany. Każdą odpowiedź traktuję jako to, czym jest: wypowiedzią osoby na forum, nie stroną dokumentacji.

• Odpowiedź pracownika IFS mówi, że po konsultacji z kolegami dodanie pól własnych do widoków Dialog lub Assistant standardowymi Custom Fields nie jest możliwe, bo te widoki nie odpowiadają wzorcom, których wymaga framework Custom Attributes. To jedyne źródło, jakie znalazłem, które wprost nazywa dialogi, i ma wagę odpowiedzi pracownika, nie dokumentacji.
• Odpowiedź klienta podaje ten sam powód innymi słowy (strony muszą spełniać wspólne wzorce przechowywania i implementacji) i wymienia cztery obejścia, z których autor woli jedno, bo jego zespół ma do niego kompetencje wewnętrzne.
• Żadna odpowiedź nie podaje terminu zmiany. Nie znalazłem wypowiedzi IFS o dodaniu tej możliwości w przyszłości, więc projektuj rozwiązanie pod ograniczenie w obecnym kształcie.

Drugi wątek potwierdza stronę asystentów. W marcu 2025 w wątku o wersji 24R2 pracownik IFS pisze, że większość konfiguracji Page Designera działa w asystentach, na przykład warunkowa widoczność, możliwość edycji i wymagalność pól, a niewspierane jest tylko dodawanie pól własnych do asystenta. Inny pracownik IFS w tym samym wątku pisze, że workflow BPA typu process enrichment powinien umieć uzupełniać wartości domyślne.

W wątku i dokumentacji pojawia się sześć podejść. Numery 1, 3 i 4 mają oparcie w Tailoring guide albo Administration guide dla IFS Cloud. Numery 2, 5 i 6 opierają się na odpowiedziach z forum i tak je oznaczam.

1. Page Designer dla tego, co już istnieje. Page Designer zmienia etykiety, ukrywa pola, ustawia pola jako obowiązkowe i przestawia elementy. Odpowiedź klienta w wątku radzi spróbować dopisać ?showInPageDesigner=true do adresu dialogu, żeby otworzyć na nim Page Designer, i dodaje, że pól własnych w ten sposób się nie utworzy. Ten parametr znalazłem wyłącznie w wątku, więc przetestuj go poza produkcją, zanim na nim oprzesz rozwiązanie.
2. Wartości domyślne w asystentach. Odpowiedź pracownika IFS w wątku o 24R2 wymienia Conditional Default Values (24R2 i 25R1) oraz workflow BPA typu process enrichment. Obie rzeczy to stwierdzenia z wątku. Dokumentacji, do której prowadzą, nie otwierałem.
3. Custom Defined Events na encji bazowej. Administration guide 25R1 opisuje Custom Defined Events (zdarzenia własne) jako zdarzenia definiowane w jednej instalacji i wykonywane przez triggery bazodanowe, które odpalają się przy dodaniu, zmianie lub usunięciu wiersza. Akcją może być E-Mail, Application Message, Task, Workflow, Streams Message albo REST Call, a Execute Online SQL jest oznaczone jako deprecated. Pracownik IFS w wątku proponuje tę drogę dla logiki w tle lub walidacji po zmianie danych przez standardowe pola dialogu. To, czy dany dialog zapisuje do encji, na której można zdefiniować zdarzenie, trzeba sprawdzać osobno dla każdego dialogu.
4. Custom Entity obok rekordu. Tailoring guide 25R1 dokumentuje rozszerzenie standardowej strony o Custom Entity: dodajesz ją do projekcji, na której oparta jest standardowa strona, tworzysz dla niej listę w Page Designerze i ustawiasz filtr przez asocjacje. Dodatkowe dane trafiają wtedy na stronę, z której otwiera się dialog, nie do samego dialogu. Odpowiedź klienta w wątku sugeruje ten sam kształt dla zlecenia produkcyjnego (Shop Order): Custom Entity powiązana kluczami ze zleceniem produkcyjnym.
5. Standardowa strona własna zamiast dialogu. Pracownik IFS w wątku proponuje rozszerzyć encję bazową o pola własne przez framework Custom Attributes i zbudować standardową stronę własną, która oferuje funkcję dialogu, żeby użytkownicy pracowali na niej. Nie znalazłem strony dokumentacji opisującej to jako wzorzec, więc to propozycja pracownika.
6. Modyfikacje projekcji i fragmenty (fragments). Klient, który preferuje tę drogę, pisze, że wymaga ona zespołu z kompetencjami wewnętrznymi. Znalazłem ją opisaną tylko w wątku. To rozwiązanie z największą ilością kodu do przeniesienia przez każde wydanie.

Tam, gdzie jedynym źródłem jest wątek, piszę „odpowiedź w wątku mówi”. Tam, gdzie obejście opisuje Tailoring guide albo Administration guide, powołuję się na dokumentację.

Kolumny kosztu utrzymania i ryzyka przy aktualizacji to moja ocena z praktyki, nie ocena IFS. Traktuj je jako punkt wyjścia do rozmowy o Twoim systemie.

Przechodź tabelę od góry i zatrzymaj się na pierwszym wierszu, który spełnia potrzebę. Im niżej, tym więcej rozwiązania musisz utrzymywać sam, a to ten sam rachunek, który stoi za wyborem między Quick Reports, Custom Fields i Custom Events.

Clean Core oznacza, że standardowe obiekty IFS zostają bez zmian, a każda zmiana siedzi w Extensibility Framework, skąd aktualizacja do nowego wydania może ją przenieść dalej. Ograniczenie dla dialogów i asystentów popycha zespoły ku jednemu z dwóch złych nawyków: modyfikacji standardowego widoku albo stosowi nieudokumentowanych zdarzeń, których nikt nie pilnuje. Tabela powyżej pozwala uniknąć obu.

• Wybieraj wiersz, który zostawia dialog w spokoju. Custom Entity na stronie nadrzędnej albo zdarzenie na encji nic nie zmienia w samym dialogu, więc aktualizacja ma mniej do zepsucia. Podejście opisuje artykuł Rozszerzenia IFS Cloud w modelu Update-Safe.
• Zapisz, dlaczego dialogu nie rozszerzono. Jedno zdanie przy każdym obejściu, z nazwą ograniczenia i datą sprawdzenia, oszczędza następnemu konsultantowi odkrywania tego od nowa.
• Po każdej aktualizacji sprawdź zdarzenia. Zdarzenie, które przestaje się odpalać, nie zgłasza błędu. Kontrola po wydaniu powinna potwierdzić, że zdarzenia nadal zapisują ślad wykonania.
• Policz koszt, zanim wybierzesz dolny wiersz. Kod z fragmentami projekcji trzeba przetestować po każdym wydaniu, więc im niżej w tabeli, tym więcej testów regresji spada na Ciebie.

O szerszej strategii piszę na stronie konsultingowej: The Clean Core i Strategic IFS Cloud Customization (obie po angielsku).

CRIMS to skrót od Configurations, Reports, Interfaces i Modifications: obiektów specyficznych dla klienta, dodawanych do standardowego IFS Cloud. Marketplace na tej stronie ma kategorię Modyfikacje, której pozycje opisano jako sprawdzone pod kątem utrzymywalności i zgodności „evergreen” z aktualizacjami IFS Cloud. To opis samej kategorii i nie mówi, jak testuje się poszczególną pozycję.

Są dwie drogi. Jeśli Twoja potrzeba pasuje do pozycji z tej kategorii, bierzesz gotowe rozwiązanie. Jeśli nie pasuje, pracę wyceniam jako budowę według tabeli decyzyjnej. W obu przypadkach proponowane podejście sprawdzam względem opisanych ograniczeń, zanim cokolwiek zostanie skonfigurowane, żeby nie powstało pole, którego framework nie przyjmie.

Umów 30-minutową rozmowę Zobacz kategorię Modyfikacje

• Known Limitations, Tailoring guide, IFS Cloud 25R1 (czytane także w wydaniu 24R1): sekcja „Custom Attributes on Assistants”.
• Introduction to Page Designer, Tailoring guide, IFS Cloud 25R1
• Extending an existing Page Model: adding a Custom Entity to a standard page, IFS Cloud 25R1
• Manage Event Actions, Administration guide, IFS Cloud 25R1
• Wątek IFS Community: Missing CUSTOM Functions in Dialog and Assistant Views in IFS Cloud (marzec 2026, 25R1)
• Wątek IFS Community: Is it Possible to Change Assistant Pages Using Configuration Only? (marzec 2025, 24R2)
• Marketplace CRIMS: Modyfikacje

Dokumentację czytano w wydaniach podanych wyżej. Ograniczenia mogą zmieniać się między wydaniami, więc sprawdź stronę Known Limitations dla wydania, z którego korzystasz. Źródła są po angielsku.

Dariusz Myśliwiec: 18 lat praktyki z IFS, obecnie z IFS Cloud. IFS Certified Associate Consultant. PRINCE2® 7. Niezależna praktyka z siedzibą w Krakowie, prowadzona zdalnie dla firm w Europie i poza nią. Rozmawiasz z konsultantem, który to buduje, nie z działem sprzedaży.

Wybrani klienci z mojej pracy z IFS: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.

IFS jest zarejestrowanym znakiem towarowym IFS AB; ta praktyka nie jest powiązana z IFS AB.