Server-tools: [RFC]函数的新api.groups装饰器

我认为这是个好主意-通过模糊（隐藏按钮）进行安全性无法正常工作。

问题是放在哪里。 我制作了一个实现有api.foreach实现的OCA Python模块，但是将其引入OCA前端并没有太多的动作

我仍然认为拥有OCA API库是一个好主意。 @lasley，您只需要按照OCA实例任务（“创建项目”）中介绍的方法创建存储库并进行PR。

关于此功能，：+1：用于添加它，但不能与装饰器add_groups等一起使用。 这应该通过继承来处理：如果您在装饰器上通过重写的方法添加任何新组，则该组将添加到列表中。 关于删除组，那么您应该使用核心中的其他技术（例如，另一个具有较少组的方法调用原始方法）。

你好 ！ 感谢您的回答。 OCA API库LGTM。 好想法 ！

但不能与装饰器add_groups等一起使用

您是对的，的确可以简化。

关于删除组，那么您应该使用核心中的其他技术（例如，另一个具有较少组的方法调用原始方法）。

不确定它是否能满足所有需求，但是我们将在针对新仓库的特定PR中讨论它。

@lasley，您只需要按照OCA实例任务（“创建项目”）中介绍的方法创建存储库并进行PR。

@lasley ，请在创建存储库时对我执行ping操作，然后我将开始POC，并尝试在接下来的开放日（/封闭日）完成工作。

我仍然认为拥有OCA API库是一个好主意。 @lasley，您只需要按照OCA实例任务（“创建项目”）中介绍的方法创建存储库并进行PR。

好点-当时我没有执行此操作的权限。 不过，我在OCA实例中找不到此过程-我会做更多的事情，并用新的回购报告。

嗯，是的，所以我找不到创建回购协议的过程，所以我只是继续创建回购协议-但看来我没有权限。 @pedrobaeza您介意创建一个空白的OCA / python-oca存储库，以便向其提交PR吗？

👍对于具有执行此操作的装饰器。 我的想法是创建一个@privileged装饰器，该装饰器将执行相同的操作，并且可以从服务器工具中的新工具模块中导入该装饰器。

但是，将装饰器作为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 。

mi

@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装饰器。 名称应取决于软件包所涵盖的功能范围或您想要的任何内容。 至少名称必须有意义。 IMO'python-oca'太宽。

我对oca-decorator很好，尽管我们需要对模块进行一些不同的构造，然后我才能使装饰器成为命名空间中的顶级。 可以肯定的是，我本来就是这样，但是我们在LasLabs / python-oca＃1中将其推回oca.helpers

无论如何，进行更改很容易，我认为最好在代码上下文中进行讨论。 看到我进行了回购后，将提交PR并包括您的建议-然后我们可以在上下文中进行讨论，而不是在劫持的PR中进行讨论。

@lasley oca名称空间必须保持为空。 否则，将无法在同一命名空间下创建其他python软件包。

知道了，因此我们基本上只想将helpers包重命名为decorators ，然后将其称为Python东西的架构？ 抽象例如oca-package-sub == oca.package.sub

是的：傻笑：就是这个主意。

ocapi太糟糕了：smile_cat：

https://github.com/OCA/oca-decorators/pull/1提交

我对这段代码的结构有疑问。 （也许我的问题无关紧要，对不起）

基本上，我看到两种编写此代码的方法。

A）通过经典的odoo模块（在现有或新存储库中）。 因此，要使用它，我们必须写一些

from odoo.addons.my_oca_lib_in_module import my_decorator

B）通过python库。

似乎大家都在谈论解决方案“ B”，当然，它是更干净的解决方案。
但另一方面，我担心这种技术会阻止一些没有技术技能的用户使用依赖于新oca-python lib的模块。 我认为这是通过UI或通过odoo.sh（以及明天在OCA appstore，也许！）中安装模块的人们的一个例子。 我不确定所有托管系统都将允许轻松安装自定义python lib。
如果某些用户将无法安装OCA模块，将非常可惜，因为这取决于某些人无法安装的额外库。

目前，OCA中只有一个示例。 openupgradelib。 该代码最初在OpenUpgrade项目中，然后被移至外部python-lib。 对我而言，这不是openupgradelib的障碍，因为进行升级是技术性的工作。

你怎么认为 ？

我们知道Odoo.sh如何处理pip依赖性吗？

IMO负责修正清单中的external_depencies键-我们有很多使用它的模块。 我认为使用此新库的模块与要求barcode barcodes_generator_abstract没有什么不同

更不用说Odoo.sh（或法国人的Odoo.hs）是下一个Runbot。 下注。

😆是的，我们知道我的赌注在哪

我们有很多使用它的模块（@lasley编写）

的确如此，但这是完全不同的。 当然，如果要使用处理条形码生成的系统，则应安装条形码库。 星号等也一样...
但这是非常有限的，也许世界上某些用户由于无法安装或不知道如何安装而无法安装此类模块。 但是别无选择。 要使用条形码生成，您需要条形码库。

在这里，是不同的。 我刚刚更新了OCA代码源分析。 今天有4182个模块。 （存在于两个里程碑中的模块将被计算两次）。 另一方面，在所有4182个模块中，只有274个python依赖项。 因此， 94％的OCA模块不依赖于外部python库，并且可以非常容易地安装。 细节 ：

如果明天有一个额外的oca python库，它带有有用的装饰器（例如我们试图在此线程中描述的尝试解决安全性问题的装饰器），则大多数OCA模块将逐步依赖于此lib。

OCA的目标是促进OCA成员的工作。 因此，如果这样的决定（创建要安装的库）减少了人们使用OCA模块的可能性，那么我认为我们暂时不应该朝这个方向发展。 我们可以首先使用经典模块创建一个小的oca-decorator存储库。 而且如果在1/2年内成熟，并且如果部署和托管系统也更加成熟（*），则将所有代码放入外部库中将非常容易。

openupgrade代码已存在于openupgrade存储库中多年，最近由@StefanRijnhart设置在外部库中。 我认为这种变化不是什么大问题。

（*）：托管和部署系统在过去几年中发生了很大变化。 （通过bzr获取代码，通过github获取代码，使用构建技术，以及最近的pypi部署）

我想听听@ OCA / board在考虑这一点。 这不仅是技术决策，还是战略决策

现在https://github.com/OCA/oca-decorators可用了，该RFC可以移到那里。

@legalsylvain-在将其创建为库之前，我最初以api.foreach提交了一个模块。 看看这个PR ，您会明白为什么我们放弃了这个策略。

当您开始考虑一个60-70个字符的导入路径时，该API的使用几乎是不可能的，并且必须围绕每个导入进行一次try / except。 这将使模块的采用率基本上为零-导入比记录循环难。

有趣的是，我们的try / except策略在装饰器中失败了，但这是一个完全不同的话题。 同样，我希望Odoo可以修复其external_dependencies密钥。

@dreispt-有什么好方法可以将此先前存在的讨论移至另一个存储库吗？ 这里有很多要点，我不确定是否会顺其自然。

当您开始考虑60-70个字符的导入路径时，该API的使用几乎是不可能的，并且必须对每个导入进行一次try / except操作

我不知道什么是该解决方案中的try /除外。

要使用oca @ foreach装饰器，请在oca_api库或模块中定义。 ：

库解决方案的影响
部署 ：

• 点安装或通过扩展。 Saas限制。

清单文件：

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

Python文件：

from oca_api import oca

模块解决方案的影响
部署 ：

• pip安装或通过UI或通过buildout下载或安装，或仅在addons文件中添加模块。 没有saas限制。

清单文件：

'depends': ['oca_api'],

Python文件：

from odoo.addons.oca_api import oca

还是我错过了什么？ 如果是，请纠正我。

亲切的问候。

我不知道什么是该解决方案中的try /除外。

导入不是核心Odoo的内容时，我们必须做try / except，所以您的示例将改为以下示例：

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就在这里，我们应该以lib形式提供它。 IIRC他的建议也是我将foreach装饰器也移出模块的主要原因。

嗨@lasley。

哦，谢谢！ 我以为对模块的依赖足以假设该模块已存在，但是在整理所有OCA代码后，我看到了很多您所讲内容的示例。 （很多用于report_xls和连接器）。

由于模块的原因，我不具备了解安全问题的技能。 对我来说，如果未安装该模块，则不应调用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）
问候和感谢您的所有评论。