Odoo 20 разширява офлайн режима, така че потребителите да могат да създават, редактират, архивират, деархивират и изтриват записи без активна връзка. Преди изпълнявани търсения също могат да се изпълняват офлайн. След възстановяване на свързаността опашките за синхронизация обработват промените, с офлайн интерфейс и инструменти за управление за наблюдение на процеса. (Odoo 20 Release Notes; Odoo Goes Offline) Това измества офлайн достъпа от резервен режим само за преглед към работен режим, който може да променя бизнес данни. Организациите, които оценяват Odoo 20, трябва да проучат как тези промени се държат при синхронизация, а не само дали записите остават достъпни по време на прекъсване.
Odoo Nightly посочва Odoo 20 като стабилно, препоръчително издание на Community Edition, датирано септември 2026 г. и поддържано до Odoo 23. (nightly.odoo.com) Този запис е важен за планирането на Community Edition, но не установява идентично офлайн покритие за всяка платформа, Enterprise среда или персонализирана база данни. Покритието трябва да се провери спрямо предвиденото внедряване.
Какво се промени спрямо Odoo 19
Офлайн режимът в Odoo 19 позволява на потребителите да преглеждат записи, отворени преди прекъсването на връзката, но не и да ги променят, докато са офлайн. Odoo 20 добавя създаване, редактиране, архивиране, деархивиране и изтриване на записи. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes) Това е функционално разширение, а не нов етикет за предишния кеш. В Odoo 19 потребителите могат да се подготвят за прекъсване, като отворят съответните записи, но работата, която променя тези записи, трябва да изчака свързаност. Odoo 20 поддържа както нови записи, така и промени по съществуващи, докато е офлайн. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes)
Оценките на версиите трябва да разграничават достъпа до кеширана информация от възможността да се завършват и поставят в опашка операции със записи. Работен процес, който изисква само справочни данни, има различни изисквания от такъв, който включва въвеждане на данни, промени в статус или изтриване. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes)
Потвърдени офлайн операции
Потвърдените действия в Odoo 20 обхващат пет части от жизнения цикъл на записа: създаване, редактиране, архивиране, деархивиране и изтриване. Преди изпълнявани търсения също са налични, докато сте офлайн. (Odoo 20 Release Notes) Приемателното тестване трябва да включва поне един сценарий за всяко действие и да потвърди, че очакваното състояние на записа се появява след повторно свързване и синхронизация.
Сесията Experience на Odoo описва специализиран офлайн интерфейс, опашки за синхронизация и инструменти за наблюдение и управление на синхронизацията. (Odoo Goes Offline) Тези функции трябва да бъдат обхванати в обучението на потребителите и в оперативните процедури. Потребителите трябва да знаят къде се показват поставените в опашка елементи, как да разпознаят нерешен елемент и кой го преглежда. Предоставеният материал потвърждава, че съществуват инструменти за управление, но не определя пълния им работен процес или административните разрешения.
Кеширането и обхватът на търсенето трябва да се проверят
Документацията на Odoo 19 описва офлайн достъпа по отношение на записи, отворени преди загубата на свързаност. Odoo 20 отделно потвърждава, че преди изпълнявани търсения могат да се изпълняват офлайн. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes) Предоставените източници не уточняват колко свързани данни се запазват, колко дълго остават налични, дали се прилагат ограничения за съхранение или дали всяко поле, свързано с кеширан запис, е достъпно. Те също така не установяват дали повторното изпълнение на търсене офлайн връща оригиналния набор от резултати или само вече съхранените на устройството данни.
Преди да одобрят офлайн работен процес, екипите трябва да определят търсенията и типовете записи, необходими за всяка роля. Тестването трябва да започне онлайн, като се изпълнят съответните търсения и се отворят нужните записи. След това тестерите могат да прекъснат връзката и да повторят предвидените задачи, включително всяко използване на прикачени файлове, свързани записи и задължителни полета. Това са точки за проверка, а не потвърдени ограничения, защото предоставената информация за изданието не описва тяхното поведение. (Бележки за изданието на Odoo 20)
Обработката на конфликти се нуждае от тестване
Опашките за синхронизация и инструментите за управление са потвърдени, но предоставените източници не обясняват как Odoo 20 решава конкуриращи се промени в един и същ запис, неуспешни проверки след повторно свързване или зависимости между операции в опашката. (Odoo Goes Offline) Наличието на опашка не установява политика за конфликти. Нейното поведение трябва да бъде демонстрирано в предвидената версия и конфигурация на Odoo.
Тест за конфликт може да включва един потребител, който променя запис офлайн, докато друг променя същия запис онлайн. След повторно свързване екипът трябва да провери получените стойности, състоянието на опашката и уведомлението към потребителя. Отделни тестове трябва да покрият офлайн редакция на запис, който е архивиран или изтрит другаде, както и новосъздаден запис, който не преминава правило на сървъра. Тестването трябва да документира дали промяната има предимство, дали се извършва обединяване или е необходима ръчна намеса. (Odoo Goes Offline)
Контрол на достъпа и разрушителни действия
Тъй като Odoo 20 включва офлайн архивиране, премахване от архив и изтриване, оценката трябва да надхвърля рутинното въвеждане на данни. (Бележки за изданието на Odoo 20) Организациите трябва да проверят дали правата за достъп, правилата за записи и изискванията за одобрение се прилагат при офлайн действието, по време на синхронизацията или и в двата етапа. Бележките за изданието потвърждават наличните действия, но не обясняват как се държи всеки контрол за сигурност без връзка.
Тестването трябва да използва представителни потребителски роли, а не само административен акаунт. Всяка роля трябва да опита разрешени и забранени действия, докато е свързана и несвързана. След това тестерите трябва да проверят дали наредените за синхронизация промени остават видими, дали съобщенията за отказ са ясни и дали архивираните, възстановените или изтритите записи достигат до желаното крайно състояние. Процеси, при които изтриването има значими последици, трябва да имат документирана офлайн процедура преди внедряването. (Бележки за изданието на Odoo 20; Odoo Goes Offline)
Персонализираните модули се нуждаят от целенасочено тестване
Потвърдената функция обхваща офлайн операции със записи и възможности за синхронизация в Odoo 20, но предоставените източници не посочват, че всеки персонализиран модул, модул на трета страна, автоматично действие или външна интеграция е съвместим с офлайн работа. (Бележки за изданието на Odoo 20; Odoo Goes Offline) Следователно персонализираните внедрявания трябва да оценят поддръжката модул по модул, вместо да приемат, че офлайн режимът се прилага еднакво за цялата база данни.
Тестването трябва да обхване персонализирани полета, поведение при onchange, задължителни стойности, изчисляеми стойности и проверки от страна на сървъра, използвани в работните процеси на организацията. Интеграциите, които обикновено реагират при създаване или редактиране на записи, също трябва да се наблюдават след синхронизация на наредените промени. Целта не е да се предполага неуспех, а да се установи дали всеки елемент работи офлайн, изчаква повторно свързване, поражда отказан елемент в опашката или изисква различен процес. (Бележки за изданието на Odoo 20; Odoo Goes Offline)
Въпроси за изясняване преди внедряването
Odoo 20 предоставя по-широк потвърден набор от офлайн възможности от Odoo 19, подкрепен от специализиран интерфейс и инструменти за синхронизация на работата в опашка. (Odoo 19.0 Docs: General Offline Mode; Бележки за изданието на Odoo 20; Odoo Goes Offline) Преди да разчита на тези възможности, организацията трябва да провери кои приложения и типове записи са обхванати, какво трябва да отворят или потърсят потребителите преди прекъсване на връзката, как се представят конфликтите и кой следи неуспешната или забавената синхронизация.
Решението за внедряване трябва също да записва поддържаните устройства и среди за внедряване, поведението при съхранение и задържане, резултатите за контрол на достъпа, резултатите от персонализираните модули и процедурите за изтриване или други последващи промени. Предоставеният материал за изданието не отговаря на тези въпроси за внедряване, но те определят дали потвърдените функции са подходящи за конкретен офлайн работен процес. (Бележки за изданието на Odoo 20; Odoo Goes Offline)
За планиране на Community Edition, списъкът на Odoo Nightly със стабилни и препоръчани версии предоставя посочения статус на версията, със поддръжка до Odoo 23. (nightly.odoo.com) Оперативното одобрение все пак трябва да зависи от тестване на точната версия, модулите, разрешенията и работните процеси, които потребителите ще използват офлайн. Потвърдената промяна е, че Odoo 20 надхвърля Odoo 19 с достъп само за четене до вече отворени записи, като позволява офлайн създаване и промяна в опашка. Тестването трябва да установи как тази възможност се държи в конфигурацията на организацията. (Документация на Odoo 19.0: Общ режим офлайн; Бележки по изданието на Odoo 20; Odoo преминава офлайн)