Częste pytania

Nie. Narzędzia pakuje się takimi, jakie są; kodu się nie rusza. Pakowanie dokłada wyłącznie metadane: identyfikator pakietu, wersję, obsługiwane wersje AutoCAD-a i rejestrowane polecenia.

Nie — prędzej szybciej. Narzędzia ładują się przy pierwszym wywołaniu polecenia, a nie przy starcie. Poza tym **na ścieżce startu AutoCAD-a nie ma żadnego zapytania sieciowego**; to wiążąca reguła tego produktu, a nie optymalizacja.

Pracują dalej. Zainstalowane narzędzia stoją na komputerze inżyniera i nie zależą od serwera. Dopóki jest nieosiągalny, czekają tylko nowe instalacje i aktualizacje.

Nie: instalacja na Państwa serwerze istnieje właśnie po to. Produkt nie łączy się na zewnątrz, a sprawdzenie licencji też jest lokalne: podpisany plik czyta się na miejscu, bez pytania jakiegokolwiek serwera. (Instalacja w chmurze połączenia oczywiście potrzebuje.)

2025, 2026 i 2027. Każda wersja ma własną warstwę dopasowania, więc nowa wersja AutoCAD-a nie oznacza przepisywania całej reszty.

Na Państwa serwerze nigdzie: archiwa pakietów, lista użytkowników i dziennik audytu zostają w Państwa bazie danych, my nie mamy do nich dostępu, a produkt nic nie wysyła na zewnątrz. Przy wyborze chmury te same dane stoją na serwerze zarządzanym przez nas, we własnej bazie. **Pliki rysunków w żadnym z tych przypadków nie wchodzą do systemu.**

Pakiety są podpisane ECDSA, a podpis sprawdza się **także po stronie klienta**. Klucz prywatny do podpisywania nigdy nie leży na serwerze, więc kto przejmie serwer, nie podmieni pakietu i nie podpisze go ponownie. Lista zaufanych kluczy publicznych też nie pochodzi z serwera — gdyby pochodziła, cały mechanizm byłby daremny.

Wprost: być administratorem znaczy móc publikować, a dwóch administratorów działających razem nie zatrzyma żaden mechanizm. Przeciwko **jednemu** istnieje opcjonalna zasada czworga oczu: drugi administrator zatwierdza wydanie, a ten, kto poprosił, nie zatwierdzi własnej prośby. Poza tym jest dziennik audytu, którego się nie kasuje, i opublikowane wersje, których się nie zmienia.

Nie. Logowanie odbywa się kodem jednorazowym wysłanym na adres poczty użytkownika. Nie ma skarbca haseł do prowadzenia ani bazy haseł, która mogłaby wyciec.

Serwer zwykle pół dnia: kreator instalacji sprawdza bazę danych, pocztę i magazyn **naprawdę je wypróbowując** — żaden krok nie kończy się słowem „zapisano”. Prawdziwy czas idzie na uporządkowanie i spakowanie narzędzi, które już są.

Jest obsługiwany. PostgreSQL i SQL Server to wybory pierwszej kategorii: ta sama bateria testów chodzi na obu serwerach, więc żaden nie jest wariantem „pewnie tam też działa”.

Decyzja należy do Państwa. Automatyczna migracja może zostać włączona albo można ją wyłączyć i dział IT uruchamia skrypty migracyjne ręcznie; skrypty leżą w folderze instalacyjnym, gotowe pod obie bazy danych.

Pocztą. Produkt zapisuje awarie z **numerem korelacji**; dział IT znajduje po nim całe zdarzenie w dziennikach lokalnych i może udostępnić nam wpis diagnostyczny. To usuwa niemal cały ruch typu „czy mogą Państwo przysłać zrzut ekranu”.

Nic nie staje. Przy wygasłej licencji użytkownicy logują się jak wcześniej, katalog ładuje się jak wcześniej, a zainstalowane narzędzia pracują dalej; system po prostu powiadamia administratora. To zachowanie jest przytwierdzone testem wewnątrz produktu.

Tak, a pilotaż to prawdziwa instalacja: na Państwa serwerze, z kilkoma Państwa narzędziami i ograniczoną grupą inżynierów. Pilotaży nie fakturujemy.

Przy standardowym abonamencie nie. Dla nabywców enterprise można umówić depozyt kodu źródłowego u strony trzeciej. Na warunkach uruchomienia określonych w tej umowie może on dać dostęp do kodu i pomóc utrzymać instalację w ruchu.

Instalacja w chmurze jest w przygotowaniu, a jej ceny są wypisane na stronie cennika; konta otwieramy z listy wczesnego dostępu, w miarę pojemności. Jeśli chcą Państwo zacząć dziś, instalacja na Państwa serwerze jest gotowa. To ona powstała pierwsza, bo dla większości biur projektowych trzymanie danych o rysunkach i narzędziach wewnątrz firmy nie podlega negocjacji.