Cloud Storage Solutions v.13

Nie, ta funkcja jest dopiero od wersji 15. Wcześniej moduł działa ze zdefiniowaną strukturą folderów:

1. Odoo - folder główny synchronizacji

2. Modele - foldery dla każdego typu dokumentu Odoo. Na przykład «Projects», «Partners». Według domeny mogą być węższe foldery: «Customer 1 Projects», «Projects of the Customer 2», «Internal Projects» itd.

3. Obiekty - foldery dla każdego dokumentu, np. «Project 1» lub «Customer 1»

4. Pliki i foldery powiązane z tym dokumentem Odoo do synchronizacji.

W efekcie możesz mieć na przykład:

• Odoo / Projects / Project 1 / pliki i foldery projektu 1

• Odoo / Customer 1 Projects / Project 1; Odoo / Customer 2 Projects / Project 3, ...

• Odoo / Customers / Customer 1 / pliki i foldery klienta 1

Struktura jest zawsze płaska: tylko te poziomy. Różnych typów dokumentów nie trzyma się w tej samej gałęzi. W folderze «Customer 1» nie można trzymać jednocześnie zamówień, faktur i projektów. Każdy typ ma własny folder (lub kilka). Inaczej synchronizacja wsteczna nie miałaby kryterium.

Nie, narzędzie opiera się na jednym punkcie końcowym użytkownika. Wszystkie procesy synchronizacji idą pod jednym administratorem chmury (aplikacją). Prawa do utworzonych folderów / plików nie są automatyzowane. Zarządzaj nimi w swoim magazynie w chmurze.

Aplikacja zakłada, że treść binarna załączników jest przechowywana w Cloud Client, a nie na serwerze Odoo. Takie załączniki w Odoo stają się typu URL i można do nich w każdej chwili wejść z pola załączników lub z Cloud Client.

Po konfiguracji nie są potrzebne działania ręczne: synchronizacja jest w pełni automatyczna. Zdecyduj, które typy dokumentów Odoo synchronizować, i ustaw powiązany model dla każdego z nich (klienci, zamówienia sprzedaży lub zakupu, zadania, projekty itd.).

Tak, możesz. Przygotuj regułę dla każdej i zastosuj filtry: na przykład według typu projektu.

Uczyń filtry wzajemnie wykluczającymi, aby dokument był jednoznacznie przypisany. Na przykład: «klient, ale nie dostawca», «dostawca, ale nie klient». W przeciwnym razie folder dokumentu przeskakiwałby z jednego modelu na inny.

Nie, narzędzie to tylko rdzeń techniczny. Potrzebujesz też konektora swojego klienta chmury.

Tak, choć przy wielu folderach/załącznikach proces może być wolny. Klienci zgłaszali jednak środowiska z >10k partnerów i ~5k wariantów produktu, a procesy były akceptowalne.

Kilka punktów:

1. Synchronizacja jest tak zbudowana, że każdy element zostanie zsynchronizowany i nie zginie, choć może to nie być szybkie. Gwarantują to kolejki FIFO i commit każdego zadania.
2. Liczbę obiektów można ograniczyć logicznie. Konfiguracja modeli pozwala wykluczyć przestarzałe pozycje (np. zarchiwizowani partnerzy lub zamówienia sprzed 2 lat).

Nie. Mamy mocne powody, by unikać synchronizacji w czasie rzeczywistym:

• Wydajność. Przy synchronicznym czasie rzeczywistym każde wysłanie pliku pokazuje ekran ładowania.

• Konflikty. Jeśli 2 użytkowników jednocześnie zmieni element, sytuacja może być nierozwiązywalna. Przy zwykłych zadaniach poprawimy to później; w czasie rzeczywistym potrzebna byłaby kolejka, jeszcze bardziej myląca.

• Funkcjonalność. Zwłaszcza zmiana nazwy i przebudowa. Synchronizacja wsteczna ściśle opiera się na logice katalogów i przy każdym uruchomieniu sprawdza 100 % elementów. Po każdej aktualizacji byłyby to tysiące żądań na sekundę. W przeciwnym razie zmiany zostałyby utracone.

Nie, ta funkcja jest dostępna dopiero od wersji 15.

Tak, w zależności od konfiguracji klienta chmury.

Zgodnie z biezacymi zasadami Odoo Apps Store:

• Modul kupiony dla wersji 12.0 lub starszej daje dostep do wszystkich wersji do 12.0.
• Od wersji 13.0 kazda wersja modulu musi byc kupiona osobno.
• Niezaleznie od wersji zakup daje prawo do wszystkich aktualizacji i poprawek w ramach wersji glownej.

Zespol faOtools nie kontroluje tych zasad. Pytania kierujcie bezposrednio do przedstawicieli Odoo Apps Store.

Najbardziej bezposrednie podejscie to wbudowany przeplyw sklepu Odoo:

1. Otworz strone modulu i kliknij Deploy on odoo.sh

2. Zostaniesz przekierowany do GitHub. Zaloguj sie i kliknij Create a new repo lub uzyj istniejacego. Repozytorium musi byc prywatne. Publikowanie aplikacji na licencji OPL-1 jest zabronione. W razie potrzeby utworz nowe repo dla projektu Odoo.sh

3. Nastepnie w odoo.sh kliknij Deploy, potwierdz i kliknij Continue. Instalacja sie rozpoczyna.

Te kroki instaluja aplikacje na galezi production. Dla innych galezi lub aktualizacji:

1. Pobierz kod zrodlowy ze sklepu Odoo

2. Zrob commit modulu do repozytorium GitHub. Zaden folder/plik aplikacji nie moze byc w .gitignore. Repo tworzone przez odoo.sh moga ignorowac wazne sciezki (np. /lib). Przeslij wszystkie katalogi i pliki modulu

3. Wdroz docelowa galaz projektu odoo.sh lub poczekaj na automatyczny build, jesli tak ustawiono.

Tak. Odoo automatycznie dodaje zaleznosci do koszyka: wylacz juz zakupione narzedzia, aby nie zaplacic dwa razy.

Czerwone/pomaranczowe ostrzezenie nie wplywa na funkcje aplikacji. Czasem nasze moduly nie przechodza standardowych testow automatycznych, bo te zakladaja zachowanie sprzeczne z celami aplikacji. Na przyklad zmieniamy obliczanie ceny, a testy Odoo porownuja cene koncowa ze standardowym algorytmem.

Najpierw sprawdz funkcje wdroznej bazy. Czy wszystko dziala?

Jesli nadal uwazasz, ze ostrzezenie wplywa na rzeczywiste funkcje, skontaktuj sie z nami i przeslij pelne logi instalacji oraz pelna liste wdroznych modulow (rdzen i firmy trzecie).

Nie, dystrybuujemy narzedzia tylko przez oficjalny sklep aplikacji Odoo.

Niestety nie mamy srodkow technicznych, by oferowac ceny indywidualne.

Nie, aplikacji innych firm nie mozna uzywac na Odoo Online. Odoo SaaS blokuje te mozliwosc.

Tak, narzedzie wymaga wszystkich modulow oznaczonych jako zaleznosci. Cena na stronie aplikacji juz je obejmuje.