OwnCloud / NextCloud Odoo Integration v.8

Не, тази функция е налична едва от версия 15. Преди тази версия модулът работи с предварително зададена структура от папки:

1. Odoo - основна папка за синхронизация

2. Models - папки за всеки тип документ на Odoo. Например 'Projects', 'Partners'. По домейн може да има по-конкретни папки: напр. 'Customer 1 Projects', 'Projects of the Customer 2', 'Internal Projects' и т.н.

3. Objects - папки за всеки документ, напр. 'Project 1' или 'Customer 1'

4. Файлове и папки, свързани с този документ на Odoo, които ще се синхронизират.

В резултат може да имате например:

• Odoo / Projects / Project 1 / файлове и папки, свързани с  project 1

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

• Odoo / Customers / Customer 1 / файлове и папки, свързани с customer 1

Тази структура е винаги плоска, тоест има само тези нива на йерархия. Затова е вярно, че различни типове документи не могат да са в една и съща структура. В папката 'Customer 1' не можем да държим файлове, свързани едновременно с поръчки за продажба, фактури и проекти. Всеки от тези типове документи има собствена папка (или няколко собствени). Иначе няма да можем да направим обратна синхронизация, защото няма да има критерий, на който да се опрем.

Не, инструментът разчита на една потребителска крайна точка. Всички процеси на синхронизация се изпълняват под един cloud администратор (приложение). Правата за достъп до създадените папки / файлове не са автоматизирани. Трябва да ги администрирате в решението си за облачно хранилище.

Приложението приема, че двоичното съдържание на прикачените файлове се съхранява в Cloud Client вместо на сървъра на Odoo. Такива прикачени файлове в Odoo стават от тип URL и можете по всяко време да ги отворите от полето за прикачени файлове или от Cloud Client.

След настройката не са нужни ръчни действия, защото синхронизацията е напълно автоматична. Решете кои типове документи на Odoo да се синхронизират и задайте свързан модел за всеки от тях (клиенти, поръчки за продажба или покупка, задачи, проекти и т.н.).

Да, можете. За целта подгответе правило за всеки и след това приложете филтри: например по тип на проекта.

Опитайте филтрите да са взаимно изключващи се, за да може документът да се присвои еднозначно. Например „клиент, но не доставчик“, „доставчик, но не клиент“. Иначе папката на конкретен документ ще скача от един модел към друг.

Не, инструментът е само техническо ядро. Нужен ви е и конекторът за вашия cloud client.

Да, макар че при много папки/прикачени файлове за синхронизация процесът може да е бавен. Същевременно клиенти съобщиха за среди с >10k партньори и ~5k продуктови варианти за синхронизация и процесите бяха приемливи.

Няколко точки за подчертаване:

1. Синхронизацията е така построена, че всеки елемент ще се синхронизира и няма да се загуби, макар да не е бърза. Гарантира се от опашки FIFO и от всеки commit-нат job.
2. Броят на обектите може да се ограничи логически. Конфигурацията на моделите позволява да ограничите синхронизацията на остарели елементи (напр. няма смисъл да се синхронизират архивирани партньори или поръчки от преди 2 години).

Не. Имаме сериозни причини да избягваме синхронизация в реално време:

• Проблеми с производителността. Ако синхронизацията е в реално време, всяко качване на файл ще показва екран на зареждане.

• Проблеми с конфликти. Ако 2 потребители променят едновременно елемент, може да възникнат неразрешими ситуации. При регулярни задачи можем да го оправим после, а при реално време трябва да го пазим като опашка, което е още по-объркващо за потребителите.

• Проблеми с функционалността. Особено преименуване и преструктуриране на елементи. При обратната синхронизация инструментът стриктно разчита на логиката на директориите и при всяка синхронизация се проверяват 100% от елементите. Ако това става след всяка промяна, ще има хиляди заявки в секунда. Ако не: промените ще се загубят.

Не, тази функция е налична едва от версия 15.

Да, в зависимост от конфигурацията на cloud client.

Не, етикетите не се синхронизират. Разглеждахме тази функция по-рано, но решихме да не я въвеждаме поради редица причини:

• Библиотеката на конектора не поддържа получаване или обновяване на етикети ownCloud

• Прикачените файлове в Odoo нямат атрибут „tags“ и не е напълно ясно кога тези етикети биха се присвоявали на потребители.

• Тъй като приложението предоставя двустранна синхронизация, при синхронизация може да възникнат критични конфликти, които ще са трудни за разрешаване.

Според действащите правила на Odoo Apps Store:

• Всеки модул, купен за версия 12.0 и по-стара, дава достъп до всички версии до 12.0.
• От версия 13.0 всяка версия на модула се купува отделно.
• Независимо от версията покупката дава право на всички обновления и поправки в рамките на основната версия.

Имайте предвид, че екипът на faOtools не контролира тези правила. За въпроси се обръщайте директно към представителите на Odoo Apps Store.

Най-прекият подход е да използвате вградения работен поток на магазина Odoo:

1. Отворете страницата на модула и щракнете бутона Deploy on odoo.sh

2. След това ще бъдете пренасочени към страницата на GitHub. Влезте в профила си, след което щракнете 'Create a new repo' или използвайте съществуващо. Уверете се, че хранилището е частно. Не е позволено публикуването на приложения под лиценз OPL-1. Ако е нужно, създайте ново repo за проекта Odoo.sh

3. След това отидете в odoo.sh и щракнете бутона Deploy. В изскачащия прозорец потвърдете решението и щракнете 'Continue.' Това стартира инсталацията.

Тези стъпки ще инсталират приложението в продукционния клон на проекта. Ако искате да разположите приложенията в други клонове или да обновите модула, направете следното:

1. Качете изходния код на приложението от магазина Odoo

2. Направете commit на модула в необходимото GitHub хранилище. Уверете се, че никои папки/файлове на приложението не се игнорират (т.е. не са в .gitignore на repo). Хранилищата се създават автоматично от odoo.sh и по подразбиране може да включват важни елементи (напр. /lib). Качете всички директории, поддиректории и файлове на модула без изключения

3. Разположете целевия клон на проекта odoo.sh или, ако настройките предполагат това, изчакайте да се изгради автоматично.

Да, разбира се. Едновременно Odoo автоматично добавя всички зависимости в количката, затова трябва да изключите вече купените инструменти, за да избегнете двойно плащане.

Червено/оранжево предупреждение не влияе на функциите на приложението. За съжаление понякога модулите ни не минават стандартните автоматични тестове, защото те очакват поведение в конфликт с целите на приложението. Например променяме изчислението на цената, а тестовете на стандартния модул Odoo сравняват крайната цена със стандартен алгоритъм.

Първо проверете функциите на разгънатата база. Всичко работи ли коректно?

Ако все пак смятате, че предупреждението влияе на реални функции, свържете се с нас и изпратете пълните регистрационни файлове от инсталацията и пълния списък на разгънатите модули (включително ядро и трети страни).

Не, разпространяваме инструментите само чрез официалния магазин за приложения Odoo.

За съжаление нямаме техническа възможност да предложим индивидуални цени. 

Не, приложения на трети страни не могат да се ползват в Odoo Online. За съжаление Odoo SaaS блокира тази възможност.

Да, инструментът изисква всички модули, посочени в зависимостите, за да работи правилно. Цената на страницата на приложението вече включва всички необходими зависимости.