Server-tools: [RFC] новый декоратор api.groups для функции

Я считаю, что это хорошая идея - защита от неизвестности (скрытие кнопок) не работает.

Вопрос в том, куда это поставить. Я сделал модуль OCA Python, в котором есть реализация api.foreach , но не было особого движения по его внедрению в

Я все еще думаю, что иметь библиотеку OCA API - хорошая идея. @lasley, вам нужно только создать репо, следуя методу, указанному в задаче экземпляра OCA («Создать проект»), и сделать PR.

Об этой функции: +1: для ее добавления, но не с помощью декораторов add_groups и так далее. Это должно обрабатываться с помощью наследования: если вы добавляете новую группу в декоратор для перезаписываемого метода, эта группа добавляется в список. Что касается удаления групп, то вам следует использовать другие методы, такие как в ядре (например, другой метод с меньшим количеством групп, который вызывает исходный метод).

Здравствуй ! Спасибо за Ваш ответ. Библиотека OCA API LGTM. Отличная идея !

но не с декораторами add_groups и т. д.

Вы правы, это действительно можно было бы упростить.

Что касается удаления групп, то вам следует использовать другие методы, такие как в ядре (например, другой метод с меньшим количеством групп, который вызывает исходный метод).

Не уверен, что это покроет все потребности, но мы поговорим об этом в конкретном пиаре против нового репо.

@lasley, вам нужно только создать репо, следуя методу, указанному в задаче экземпляра OCA («Создать проект»), и сделать PR.

@lasley , пожалуйста, свяжитесь со мной, когда репо будет создано, я начну POC тогда и попытаюсь закончить работу в следующие открытые (/ закрытые) дни.

Я все еще думаю, что иметь библиотеку OCA API - хорошая идея. @lasley, вам нужно только создать репо, следуя методу, указанному в задаче экземпляра OCA («Создать проект»), и сделать PR.

Хороший момент - в то время у меня не было на это разрешений. Я не нахожу этот процесс в экземпляре OCA - я копаю еще немного и сообщу о новом репо.

Хммм, хорошо, да, я не могу найти процесс для создания репо, поэтому я просто собирался пойти дальше и создать репо - но, похоже, у меня нет разрешений. @pedrobaeza, не репозиторий OCA / python-oca, чтобы я мог отправить ему PR?

👍 За то, что у вас есть декоратор, который это делает. У меня возникла идея создать декоратор @privileged , который делал бы то же самое, и который можно было бы импортировать из нового модуля инструментов в server-tools.

Но декоратор может быть частью библиотеки pip. Меня интересует только название @ api.groups. Разве это не сбивает с толку, поскольку это не исходит от модуля odoo api python?

Привет @ NL66278!

ну, что касается пространства имен, я думаю, что столкновение будет невозможно, потому что имя будет @ oca.groups, а не @ api.groups. (или что-то подобное)

@legalsylvain Я реагировал на первый пример использования. Было бы здорово иметь @oca.groups .

@legalsylvain Хорошая идея!

Я бы предпочел оставить 'oca' как пакет пространства имен, доступный для всех пакетов oca. Мы могли бы назвать этот новый пакет «oca-decorator». Этот пакет предоставит oca.decorator (или oca.xyz)

from oca.decorator import groups

    @groups(..)
    def function_name():

О groups Я бы предпочел более явное имя, например allowed_groups .

lmi

@lasley это задача, в которой указан процесс для нового репозитория / PSC: https://odoo-community.org/web#id = 264 & view_type = form & model = project.task & action = 468 & active_id = 2

Боже, спасибо, Педро! По какой-то причине я искал все, от Project до Repo, но не подумал включить "PSC". Дерп!

Тем не менее, мне все равно понадобятся дополнительные права в OCA GitHub - у меня нет новой кнопки:

Попробуйте еще раз, когда я сменил вашу роль.

@lasley @pedro Почему python-oca ? Это имя бессмысленно. Как вы планируете назвать пакет python?

@lmignon - Я спрашивал предложения, и это было лучшее. Пакет python имеет аналогичное название.

Какая у вас идея? Я весь во внимании.

@lasley Моя главная забота - избежать создания монолитного пакета python. Если основная цель - предоставить новых специализированных декораторов, почему бы не oca-decorator. Имя должно зависеть от функциональной области, охватываемой пакетом, или от того, что вы хотите. По крайней мере, имя должно быть значимым. IMO python-oca слишком широк.

У меня хорошо получается oca-decorator , хотя нам нужно было бы структурировать модуль немного по-другому, я думаю, чтобы сделать декораторы верхнего уровня в пространстве имен. Уверен, что изначально у меня так было, но мы вернули его к oca.helpers в LasLabs / python-oca # 1

В любом случае внести это изменение достаточно просто, и я думаю, что было бы лучше обсудить его в контексте кода. Увидев, что я сделал репо, отправлю PR и включу ваше предложение - тогда мы сможем обсудить в контексте вместо этого похищенного PR.

@lasley пространство имен oca должно оставаться пустым. В противном случае будет невозможно создавать другие пакеты python в том же пространстве имен.

Понятно, поэтому мы просто хотели бы переименовать наш пакет helpers в decorators , а затем назвать это нашей схемой для материала Python? Аннотация Например, oca-package-sub == oca.package.sub

yep: smirk: вот в чем идея.

Жаль, что ocapi взяты: smile_cat:

https://github.com/OCA/oca-decorators/pull/1 отправлено

У меня вопрос о структуре этого кода. (может быть, мой вопрос неактуален, извините)

В принципе, я вижу два способа написать этот код.

А) через классический модуль odoo (в существующем или новом репозитории). поэтому, чтобы использовать его, мы должны написать несколько

from odoo.addons.my_oca_lib_in_module import my_decorator

Б) через python lib.

Кажется, что вы все говорите о растворе «Б», и, конечно же, это более чистое решение.
но с другой стороны, я опасаюсь, что такая технология заблокирует некоторых пользователей, не имеющих технических навыков для использования модулей, зависящих от новой библиотеки oca-python. Я думаю, в качестве примера для людей, которые устанавливают модуль через пользовательский интерфейс или другой через odoo.sh (а завтра, возможно, с OCA appstore!). Я не уверен, что вся система хостинга позволит легко установить собственную библиотеку python.
было бы жаль, если у некоторых пользователей не будет возможности устанавливать модули OCA, потому что это зависит от дополнительной библиотеки, которая не может быть установлена ​​для некоторых людей.

На данный момент в ОСА есть только один пример. Файл openupgradelib. код изначально находился в проекте OpenUpgrade и был перемещен во внешний python-lib. Для меня это не препятствие для openupgradelib, потому что обновление - это техническая вещь.

Что вы думаете ?

Знаем ли мы, как Odoo.sh обрабатывает зависимости pip?

ИМО, это они, чтобы исправить ключ external_depencies в манифесте - у нас есть много модулей, которые его используют. Я не думаю, что модули, использующие эту новую библиотеку, будут чем-то отличаться от, скажем, barcodes_generator_abstract требующего barcode

не сказать, что Odoo.sh (или Odoo.hs для французов) будет следующим Runbot. Ставка принята.

😆 Да, мы знаем, где моя ставка на это

у нас есть много модулей, которые его используют (автор @lasley)

Действительно, но это совсем другое. Конечно, если вам нужна система, которая обрабатывает создание штрих-кода, вам следует установить библиотеку штрих-кода. то же самое для звездочки и т.д ...
но это очень ограничено, и, возможно, некоторые пользователи в мире не устанавливают такие модули, потому что они не могут или не знают, как это сделать. но альтернативы нет. чтобы использовать генерацию штрих-кода, вам нужна библиотека штрих-кода.

Здесь все по-другому. Я только что обновил анализ исходного кода OCA. сегодня насчитывается 4182 модуля. (модуль, присутствующий на двух этапах, засчитывается дважды). С другой стороны, во всех этих 4182 модулях есть только 274 зависимости Python. Таким образом, 94% модулей OCA не зависят от внешних библиотек Python и могут быть очень легко установлены. Детали :

Если завтра появится хорошая дополнительная библиотека oca python с полезными декораторами (вроде той, которую мы пытаемся описать в этой ветке, которая пытается исправить проблему безопасности), большинство модулей OCA будут зависеть от этой библиотеки, шаг за шагом.

Целью OCA является продвижение работы членов OCA. Так что если такое решение (создать библиотеку для установки) снижает возможность использования модулей OCA, я думаю, что нам не следует пока идти в этом направлении. Мы могли бы сначала создать небольшой репозиторий oca-decorator с классическими модулями . И если через 1/2 года он станет зрелым, и если система развертывания и хостинга также станут более зрелыми (*), будет очень легко поместить весь код во внешнюю библиотеку.

Код openupgrade в течение многих лет находился в репозитории openupgrade и недавно был установлен во внешней библиотеке @StefanRijnhart. Я думаю, что в этих изменениях не было ничего страшного.

(*): система хостинга и развертывания сильно изменилась за последние годы. (получение кода через bzr, получение кода через github, использование технологии buildout и, совсем недавно, развертывание pypi)

Я хотел бы услышать, что @ OCA / board думают по этому поводу. это не только техническое решение, это также стратегическое решение

Теперь, когда доступен https://github.com/OCA/oca-decorators , этот RFC можно переместить туда.

@legalsylvain - Я изначально отправил модуль для api.foreach прежде чем создавать его как библиотеку. Взгляните на этот PR , и вы поймете, почему мы отказались от этой стратегии.

Использование api было чертовски практически невозможно, когда вы начинаете учитывать путь импорта, который составляет 60-70 символов, и попытку / за исключением того, что нужно помещать вокруг каждого из импортов. Это сделает внедрение модуля практически нулевым - импорт сложнее, чем цикл записи.

Достаточно интересно, что наша стратегия try / except терпит неудачу с декораторами, но это совершенно другая тема. Опять же, я хочу, чтобы Odoo исправил их ключ external_dependencies .

@dreispt - есть ли хороший способ переместить это ранее существовавшее обсуждение в другое репо? Здесь раскрыто множество моментов, которые, я не уверен, будут перенесены плавно.

Использование api было чертовски невозможно, когда вы начинаете учитывать путь импорта, который составляет 60-70 символов, и try / за исключением того, что нужно помещать вокруг каждого из импортов

Я не понимаю, в чем состоит необходимость в этом решении.

Чтобы использовать декоратор oca @ foreach, определите в библиотеке или модуле oca_api. :

Влияние решения Lib
развертывать :

• pip install или через buildout. Ограничение Saas.

файл манифеста:

'external_dependencies': {'python': ['oca_api']}

Файл Python:

from oca_api import oca

Модульное решение влияет
развертывать :

• pip установить или загрузить и установить через пользовательский интерфейс или через buildout или просто добавив модуль в файл дополнений. нет ограничений saas.

файл манифеста:

'depends': ['oca_api'],

Файл Python:

from odoo.addons.oca_api import oca

Или я что-то упустил? Если да, пожалуйста, поправьте меня.

С уважением.

Я не понимаю, в чем состоит необходимость в этом решении.

Команда try / except - это то, что мы должны делать при импорте всего, что не является ядром Odoo, поэтому вместо этого ваши примеры будут следующими:

try:
    from oca_api import oca
except ImportError:...

try:
    from odoo.addons.oca_api import oca
except ImportError:...

Но да, с именами вашего модуля, это не так плохо, как у меня.

Я думаю, что во многом это связано с тем, что модуль не устанавливается в БД и не инкапсулируется в среду, как большинство модулей. Это означает, что он предоставляет функциональные возможности средам, в которых модуль явно не установлен, и это может рассматриваться как проблема (безопасность или иное).

@lmignon только что представил аргумент, аналогичный приведенному выше, в https://github.com/OCA/webhook/pull/3#issuecomment -336935193. Я думаю, что это параллельные разговоры - в основном они сводятся к тому, как мы предоставляем такие наборы функций.

Я лично считаю, что @lmignon находится прямо здесь, и мы должны предоставить его как библиотеку. Его совет IIRC был основной причиной, по которой я убрал декоратор foreach из модуля.

Привет @lasley.

Ой, спасибо! Я думал, что создания зависимостей для модуля было достаточно, чтобы предположить, что модуль присутствует, но, проанализировав весь код OCA, я увидел много примеров того, что вы говорите. (много для report_xls и коннектора).

У меня нет навыков для понимания проблем безопасности hre из-за модуля. По мне, если модуль не установлен, код модуля oca_api вызывать не надо. но может я ошибаюсь.

С Уважением.

Я думал, что создания зависимостей для модуля было достаточно, чтобы предположить, что модуль присутствует,

Взгляните на https://github.com/odoo/odoo/pull/14850 для получения дополнительной информации.

По мне, если модуль не установлен, код модуля oca_api вызывать не надо.

В этом и заключается проблема. Это не так - Odoo импортирует все модули в пределах пути addons в память. Из-за этого импорт модуля будет успешным в любом модуле, независимо от того, установлен ли зависимый на самом деле.

Это ядро ​​Odoo, и на самом деле обхода нет. Вот почему я не обслуживаю своих клиентов так же, как Odoo SA. Мне любопытно, удалось ли им решить эту проблему с помощью Odoo.sh, но я предполагаю, что у них есть тикающая бомба замедленного действия в их SaaS

Спасибо за все эти разъяснения. Жалко что odoo / odoo # 14850 не принимается.
Я все еще думаю, что создание большого количества модулей OCA в зависимости от внешней библиотеки, безусловно, ограничит использование этих модулей. Но что ж, модуль действительно не кажется решением.
С уважением и большое спасибо за понимание.

Закрываю этот выпуск. (перенесено на https://github.com/OCA/oca-decorators/issues/7)
С уважением и спасибо за все ваши комментарии.