Cloud Storage Solutions v.8

Hayır, bu özellik yalnızca sürüm 15'ten itibaren vardır. Öncesinde modül önceden tanımlı klasör yapısıyla çalışır:

1. Odoo - senkronun kök klasörü

2. Modeller - her Odoo belge türü için klasörler. Örneğin «Projects», «Partners». Alana göre daha özel klasörler olabilir: «Customer 1 Projects», «Projects of the Customer 2», «Internal Projects» vb.

3. Nesneler - her belge için klasör, örn. «Project 1» veya «Customer 1»

4. Bu Odoo belgesine ait senkronize edilecek dosya ve klasörler.

Sonuç olarak örneğin şunlar oluşabilir:

• Odoo / Projects / Project 1 / proje 1'e ait dosya ve klasörler

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

• Odoo / Customers / Customer 1 / müşteri 1'e ait dosya ve klasörler

Yapı her zaman düzdür: yalnızca bu hiyerarşi düzeyleri. Farklı belge türleri aynı dalda tutulamaz. «Customer 1» klasöründe hem sipariş, hem fatura hem proje dosyaları olamaz. Her türün kendi klasörü (veya klasörleri) vardır. Aksi halde geri senkron için dayanak kalmaz.

Hayır, araç tek bir kullanıcı uç noktasına dayanır. Tüm senkron süreçleri tek bir bulut yöneticisi (uygulama) altında yapılır. Oluşturulan klasör / dosya hakları otomatik değildir. Bunları bulut depolama çözümünüzde yönetin.

Uygulama, eklerin ikili içeriğinin Odoo sunucusu yerine Cloud Client'te tutulduğunu varsayar. Bu yüzden Odoo'daki bu ekler URL tipine dönüşür ve onlara istediğiniz zaman ek kutusundan veya Cloud Client'ten erişebilirsiniz.

Kurulumdan sonra elle işlem gerekmez; senkronizasyon tamamen otomatiktir. Hangi Odoo belge tiplerinin senkronize edileceğine karar verin ve her biri için ilgili modeli ayarlayın (müşteriler, satış veya satın alma siparişleri, görevler, projeler vb.).

Evet, yapabilirsiniz. Bunun için her biri için bir kural hazırlayın ve filtre uygulayın: örneğin proje türüne göre.

Bir belgenin kesin atanması için filtreleri birbirini dışlar hale getirin. Örneğin: «müşteri ama tedarikçi değil», «tedarikçi ama müşteri değil». Aksi halde belgenin klasörü bir modelden diğerine atlar.

Hayır, araç yalnızca teknik çekirdektir. Bulut istemcinizin bağlayıcısına da i̇htiyacınız var.

Evet, çok klasör/ek varsa süreç yavaş olabilir. Yine de müşteriler >10 bin iş ortağı ve ~5 bin ürün varyantı olan ortamlar bildirdi ve süreçler kabul edilebilirdi.

Vurgulanacak noktalar:

1. Senkron, her öğenin senkronize edilip kaybolmamasını sağlar; hızlı olmayabilir. FIFO kuyrukları ve her işin commit edilmesi bunu garanti eder.
2. Nesne sayısı mantıksal olarak sınırlanabilir. Model yapılandırması eski öğeleri dışlar (ör. arşivlenmiş iş ortakları veya 2 yıl önceki siparişler).

Hayır. Gerçek zamanlı senkronizasyondan kaçınmamızın güçlü nedenleri var:

• Performans. Senkron gerçek zamanlıysa her dosya yüklemesi yükleme ekranı gösterir.

• Çakışmalar. 2 kullanıcı aynı anda bir öğeyi değiştirirse durum çözümsüz kalabilir. Düzenli işlerde sonra düzeltebiliriz; gerçek zamanda kuyruk gerekir ve bu daha kafa karıştırıcı olur.

• İşlevsellik. Özellikle yeniden adlandırma ve yeniden yapılandırma. Geri senkron dizin mantığına sıkı bağlıdır ve her senkronde öğelerin %100'ü kontrol edilir. Her güncellemeden sonra saniyede binlerce istek olur. Yoksa değişiklikler kaybolur.

Hayır, bu özellik yalnızca sürüm 15'ten itibaren kullanılabilir.

Evet, bulut istemcinizin yapılandırmasına bağlı olarak.

Güncel Odoo Apps Store politikalarina göre:

• 12.0 ve önceki sürüm için alinan her modül, 12.0'a kadar tum surumlere erişim verir.
• 13.0 surumunden itibaren her modül sürümü ayri satin alinmalidir.
• Surumden bagimsiz olarak satin alma, o ana sürüm içindeki tum güncelleme ve hata duzeltmelerine hak verir.

faOtools ekibi bu politikalari kontrol etmez. Sorulariniz için doğrudan Odoo Apps Store temsilcilerine ulasin.

En doğrudan yaklasim, Odoo magazasinin yerlesik is akisidir:

1. Modül sayfasini acin ve Deploy on odoo.sh düğmesine tiklayin

2. GitHub sayfasina yonlendirilirsiniz. Hesabiniza giriş yapin, ardindan Create a new repo'ya tiklayin veya mevcut birini kullanin. Depo özel olmalidir. OPL-1 lisansli uygulamalarin yayimlanmasi yasaktir. Gerekirse Odoo.sh projeniz için yeni bir depo oluşturun

3. Ardindan odoo.sh'e gidin, Deploy'a tiklayin, karari onaylayin ve Continue'ya tiklayin. Kurulum başlar.

Bu adimlar uygulamayi projenin production dalina kurar. Diğer dallar veya modül guncellemesi için:

1. Kaynak kodu Odoo magazasindan indirin

2. Modulu gerekli GitHub deposuna commit edin. Hiçbir uygulama klasörü/dosyasi .gitignore'da olmamalidir. odoo.sh'in oluşturduğu depolar varsayilan olarak önemli yollari (örneğin /lib) yok sayabilir. Tum modül dizinlerini ve dosyalarini istisnasiz yükleyin

3. odoo.sh projesinin hedef dalini deploy edin veya ayarlariniz otomatik derlemeyi ongoruyorsa bekleyin.

Evet. Odoo tum bagimliliklari sepete otomatik ekler: çift odemeyi onlemek için daha önce satin alinan araclari cikarin.

Kirmizi/turuncu uyari uygulamanin özelliklerini etkilemez. Bazen modüllerimiz standart otomatik testleri gecemez, çünkü bunlar uygulamamizin amaclarina aykiri davranis bekler. Örneğin fiyati farkli hesaplariz, Odoo testleri ise nihai fiyati standart algoritmayla karsilastirir.

Önce dagitilan veritabaninin özelliklerini kontrol edin. Her sey doğru calisiyor mu?

Uyarinin gerçek özellikleri etkiledigini dusunuyorsaniz bize yazin; tam kurulum günlüklerini ve dagitilan modüllerin tam listesini (çekirdek ve üçüncü taraf) gönderin.

Hayir, araclari yalnizca resmi Odoo uygulama magazasi üzerinden dagitiyoruz.

Ne yazik ki bireysel fiyat sunacak teknik imkanimiz yok.

Hayir, üçüncü taraf uygulamalar Odoo Online'da kullanilamaz. Odoo SaaS bunu engeller.

Evet, aracimizin doğru calismasi için bagimliliklarda isaretlenen tum modullere ihtiyaci vardir. Uygulama sayfasindaki fiyat bu bagimliliklari zaten içerir.