Server-tools: [RFC] neuer api.groups Dekorator für Funktion

Ich denke, das ist eine gute Idee - Sicherheit durch Dunkelheit (Verstecken der Tasten) funktioniert nicht.

Die Frage ist, wo dies zu setzen ist. Ich habe ein OCA-Python-Modul erstellt , das eine api.foreach -Implementierung enthält, aber es gab nicht viel Bewegung, um es in die OCA-Front zu bringen

Ich halte es immer noch für eine gute Idee, eine OCA-API-Bibliothek zu haben. @lasley Sie müssen das Repo nur nach der in der OCA-

Über diese Funktion: +1: zum Hinzufügen, aber nicht mit den Dekorateuren add_groups und so weiter. Dies sollte mit der Vererbung behandelt werden: Wenn Sie eine neue Gruppe im Dekorator mit einer überschriebenen Methode hinzufügen, wird diese Gruppe zur Liste hinzugefügt. Wenn Sie Gruppen entfernen möchten, sollten Sie andere Techniken wie im Kern verwenden (z. B. eine andere Methode mit weniger Gruppen, die die ursprüngliche Methode aufruft).

Hallo ! Danke für deine Antwort. Eine OCA-API-Bibliothek LGTM. Großartige Idee !

aber nicht mit den Dekorateuren add_groups und so weiter

Sie haben Recht, es könnte in der Tat vereinfacht werden.

Wenn Sie Gruppen entfernen möchten, sollten Sie andere Techniken wie im Kern verwenden (z. B. eine andere Methode mit weniger Gruppen, die die ursprüngliche Methode aufruft).

Ich bin mir nicht sicher, ob es alle Anforderungen abdeckt, aber wir werden in einer speziellen PR gegen das neue Repo darüber sprechen.

@lasley Sie müssen das Repo nur nach der in der OCA-

@lasley , bitte ping mich an, wenn das Repo erstellt wird. Ich werde dann einen POC

Ich halte es immer noch für eine gute Idee, eine OCA-API-Bibliothek zu haben. @lasley Sie müssen das Repo nur nach der in der OCA-

Guter Punkt - zu der Zeit hatte ich keine Berechtigung dazu. Ich finde diesen Prozess jedoch nicht in der OCA-Instanz. Ich werde ein bisschen mehr graben und mit dem neuen Repo Bericht erstatten.

Hmmm ok yeah, also kann ich keinen Prozess für die Repo-Erstellung finden, also wollte ich einfach das Repo erstellen - aber anscheinend habe ich keine Berechtigungen. @pedrobaeza Würde es Ihnen etwas

👍 Für einen Dekorateur, der dies tut. Ich hatte die Idee, einen @privileged -Dekorator zu erstellen, der dasselbe tut und der aus einem neuen Tools-Modul in Server-Tools importiert werden kann.

Aber der Dekorateur könnte auch Teil einer Pip-Bibliothek sein. Ich frage mich nur über den Namen @ api.groups. Wäre das nicht verwirrend, da dies dann nicht vom odoo api python Modul kommt?

Hi @ NL66278 ,

Nun, was den Namensraum betrifft, denke ich, dass eine Kollision nicht möglich sein wird, da der Name @ oca.groups und nicht @ api.groups sein wird. (oder etwas ähnliches)

@legalsylvain Ich habe auf das erste Beispiel reagiert. @oca.groups wäre großartig.

@legalsylvain Es ist eine gute Idee!

Ich möchte lieber 'oca' als Namespace-Paket für alle oca-Pakete verfügbar halten. Wir könnten dieses neue Paket "Oca-Dekorateur" nennen. Dieses Paket würde 'oca.decorator' (oder oca.xyz) bereitstellen.

from oca.decorator import groups

    @groups(..)
    def function_name():

Über groups Ich würde einen expliziteren Namen bevorzugen, zum Beispiel allowed_groups .

lmi

@lasley Dies ist die Aufgabe, bei der der Prozess für ein neues Repository / PSC angegeben wird: https://odoo-community.org/web#id = 264 & view_type = form & model = project.task & action = 468 & active_id = 2

Omg danke Pedro! Aus irgendeinem Grund habe ich alles von Project bis Repo durchsucht, aber nicht daran gedacht, "PSC" aufzunehmen. Derp!

Ich benötige jedoch noch einige zusätzliche Rechte im OCA GitHub - ich habe den neuen Button nicht:

Versuchen Sie es jetzt noch einmal, da ich Ihre Rolle geändert habe.

@lasley @pedro Warum python-oca ? Dieser Name ist bedeutungslos. Wie wollen Sie das Python-Paket benennen?

@ lmignon - Ich bat um Vorschläge und dies war der beste. Das Python-Paket hat einen ähnlichen Namen.

Was ist deine Idee? Ich bin ganz Ohr.

@lasley Mein Hauptanliegen ist es, die Erstellung eines monolytischen Python-Pakets zu vermeiden. Wenn das Hauptziel darin besteht, neue spezialisierte Dekorateure bereitzustellen, warum nicht Oca-Dekorateure? Der Name sollte vom Funktionsumfang des Pakets oder von dem, was Sie möchten, abhängen. Zumindest muss der Name aussagekräftig sein. IMO 'Python-Oca' ist zu breit.

Ich bin gut mit oca-decorator , obwohl wir das Modul meiner Meinung nach etwas anders strukturieren müssten, um die Dekorateure im Namespace auf die oberste Ebene zu bringen. Ich bin mir ziemlich sicher, dass ich es ursprünglich so hatte, aber wir haben es in LasLabs / python-oca # 1 auf oca.helpers zurückgeschoben

Wie auch immer, es ist einfach genug, diese Änderung vorzunehmen, und ich denke, es wäre besser, sie im Kontext von Code zu diskutieren. Da ich das Repo gemacht habe, werde ich die PR einreichen und Ihren Vorschlag einschließen - dann können wir anstelle dieser entführten PR im Kontext diskutieren.

@lasley Der Namespace oca muss leer bleiben. Andernfalls können keine anderen Python-Pakete unter demselben Namespace erstellt werden.

Verstanden, also möchten wir unser helpers -Paket einfach in decorators umbenennen und dann unser Schema für das Python-Zeug nennen? Zusammenfassung zB oca-package-sub == oca.package.sub

yep: grinsen: das ist die idee.

Schade, dass ocapi ist: smile_cat:

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

Ich habe eine Frage zur Struktur dieses Codes. (Vielleicht ist meine Frage irrelevant, sorry)

Grundsätzlich sehe ich zwei Möglichkeiten, diesen Code zu schreiben.

A) über ein klassisches Odoo-Modul (in einem bestehenden oder neuen Repository). Um es zu benutzen, müssen wir einige schreiben

from odoo.addons.my_oca_lib_in_module import my_decorator

B) über eine Python-Bibliothek.

Es scheint, dass Sie alle über die Lösung "B" sprechen, und natürlich ist es die sauberere Lösung.
Andererseits befürchte ich, dass eine solche Technologie einige Benutzer blockieren wird, die keine technischen Fähigkeiten haben, um Module zu verwenden, die von der neuen oca-python lib abhängen. Ich denke zum Beispiel an Leute, die Module über die Benutzeroberfläche oder andere über odoo.sh installieren (und morgen vielleicht mit dem OCA-Appstore!). Ich bin nicht sicher, ob das gesamte Hosting-System die einfache Installation einer benutzerdefinierten Python-Bibliothek ermöglicht.
Es wäre schade, wenn einige Benutzer nicht die Möglichkeit hätten, OCA-Module zu installieren, da es abhängig von einer zusätzlichen Bibliothek gibt, die für einige Leute nicht installierbar ist.

Derzeit gibt es in der OCA nur ein weiteres Beispiel. Die openupgradelib. Der Code befand sich ursprünglich im OpenUpgrade-Projekt und wurde in eine externe Python-Lib verschoben. Für mich ist es kein Blockierungspunkt für die openupgradelib, da ein Upgrade eine technische Sache ist.

Was denkst du ?

Wissen wir, wie Odoo.sh mit Pip-Abhängigkeiten umgeht?

IMO liegt es an ihnen, den Schlüssel external_depencies im Manifest zu reparieren - wir haben viele Module, die ihn verwenden. Ich glaube nicht, dass Module, die diese neue Bibliothek verwenden, anders wären als beispielsweise barcodes_generator_abstract die barcode erforderlich sind

Nicht zu sagen, Odoo.sh (oder Odoo.hs für Franzosen) ist der nächste Runbot. Wette genommen.

😆 Ja, wir wissen, wo meine Wette darauf liegt

Wir haben viele Module, die es verwenden (von @lasley)

In der Tat, aber es ist ganz anders. Wenn Sie ein System für die Barcode-Generierung benötigen, sollten Sie natürlich die Barcode-Bibliothek installieren. das gleiche für Sternchen, etc ...
Dies ist jedoch sehr begrenzt, und möglicherweise installieren einige Benutzer auf der Welt solche Module nicht, weil sie dies nicht können oder nicht können. aber es gibt keine alternative. Um die Barcode-Generierung nutzen zu können, benötigen Sie eine Barcode-Bibliothek.

Hier ist es anders. Ich habe gerade die Analyse der OCA-Codequelle aktualisiert. Heute gibt es 4182 Module. (Ein Modul, das in zwei Meilensteinen vorhanden ist, wird zweimal gezählt). Andererseits gibt es in all diesen 4182 Modulen nur 274 Python-Abhängigkeiten. 94% der OCA-Module sind also nicht von externen Python-Bibliotheken abhängig und können sehr einfach installiert werden. Einzelheiten :

Wenn es morgen eine gute zusätzliche Oca-Python-Bibliothek mit nützlichen Dekoratoren gibt (wie die, die wir in diesem Thread beschreiben, um ein Sicherheitsproblem zu beheben), hängen die meisten OCA-Module Schritt für Schritt von dieser Bibliothek ab.

Ziel der OCA ist es, die Arbeit der OCA-Mitglieder zu fördern. Wenn eine solche Entscheidung (eine zu installierende Bibliothek zu erstellen) die Möglichkeit für Benutzer verringert, OCA-Module zu verwenden, sollten wir meiner Meinung nach vorerst nicht in diese Richtung gehen. Wir könnten zuerst ein kleines Oca-Decorator-Repository mit klassischen Modulen erstellen. Und wenn es in 1/2 Jahren ausgereift ist und das Bereitstellungs- und Hosting-System auch ausgereifter ist (*), ist es sehr einfach, den gesamten Code in eine externe Bibliothek zu stellen.

openupgrade-Code war jahrelang im openupgrade-Repository und wurde kürzlich von @StefanRijnhart in einer externen Bibliothek festgelegt. Ich denke, dass diese Änderungen keine große Sache waren.

(*): Das Hosting- und Bereitstellungssystem hat sich in den letzten Jahren stark verändert. (Abrufen von Code von bzr, Abrufen von Code von github, Verwenden der Buildout-Technologie und in jüngerer Zeit Pypi-Bereitstellung)

Ich würde gerne hören, was @ OCA / board über diesen Punkt denken. Es ist nicht nur eine technische Entscheidung, sondern auch eine strategische Entscheidung

Nachdem https://github.com/OCA/oca-decorators verfügbar ist, kann dieser RFC dorthin verschoben werden.

@legalsylvain - Ich habe ursprünglich ein Modul für api.foreach eingereicht, bevor ich dieses als Bibliothek erstellt habe. Werfen Sie einen Blick auf diese PR und Sie werden sehen, warum wir diese Strategie aufgegeben haben.

Die Verwendung der API war verdammt unmöglich, als Sie anfingen, einen Importpfad mit 60-70 Zeichen zu berücksichtigen, und einen Versuch / mit der Ausnahme, dass jeder Import importiert werden muss. Dadurch wird das Modul im Grunde genommen auf Null gesetzt - der Import ist schwieriger als die Aufzeichnungsschleife.

Interessanterweise scheitert unsere Try / Except-Strategie bei Dekorateuren kläglich, aber das ist ein ganz anderes Thema. Wieder wünschte ich, Odoo würde ihren external_dependencies Schlüssel reparieren.

@dreispt - gibt es eine gute Möglichkeit, diese bereits bestehende Diskussion auf ein anderes Repo zu verschieben? Es gibt hier viele Punkte, von denen ich nicht sicher bin, ob sie flüssig übertragen werden.

Die Verwendung der API war verdammt unmöglich, als Sie anfingen, einen Importpfad mit 60-70 Zeichen zu berücksichtigen, und einen Versuch / mit der Ausnahme, dass jeder Import importiert werden muss

Ich verstehe nicht, was der Versuch / außer der Bedarf in dieser Lösung ist.

Um einen oca @ foreach- Dekorator zu verwenden, definieren Sie ihn in einer oca_api-Bibliothek oder einem oca_api-Modul. ::

Auswirkungen der Lib-Lösung
bereitstellen:

• Pip installieren oder über Buildout. Saas Einschränkung.

Manifestdatei:

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

Python-Datei:

from oca_api import oca

Auswirkungen der Modullösung
bereitstellen:

• pip installieren oder herunterladen und über die Benutzeroberfläche oder über das Buildout installieren oder einfach ein Modul in die Addons-Datei einfügen. Keine Saas-Einschränkung.

Manifestdatei:

'depends': ['oca_api'],

Python-Datei:

from odoo.addons.oca_api import oca

Oder habe ich etwas verpasst? Wenn ja, bitte korrigieren Sie mich.

Mit freundlichen Grüßen.

Ich verstehe nicht, was der Versuch / außer der Bedarf in dieser Lösung ist.

Der Versuch / die Ausnahme ist das, was wir tun müssen, wenn wir etwas importieren, das nicht Kern-Odoo ist. Ihre Beispiele wären also stattdessen die folgenden:

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

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

Aber ja, mit Ihrer Modulbenennung ist es bei weitem nicht so schlimm wie meine.

Ich denke, viel davon hat damit zu tun, dass das Modul nicht in einer Datenbank installiert wird und nicht wie die meisten Module in die Umgebung eingekapselt ist. Dies bedeutet, dass es Funktionen für Umgebungen bereitstellt, die das Modul nicht explizit installiert haben und als Problem (Sicherheit oder auf andere Weise) angesehen werden können.

@lmignon hat gerade ein ähnliches Argument wie oben in https://github.com/OCA/webhook/pull/3#issuecomment -336935193 veröffentlicht. Ich denke, dies sind parallele Gespräche - im Grunde genommen geht es darum, wie wir solche Funktionen bereitstellen.

Ich persönlich bin der Meinung, dass @lmignon genau hier ist und wir sollten dies als foreach Dekorateur ebenfalls aus einem Modul entfernt habe.

Hallo @lasley.

Ow danke! Ich dachte, dass das Herstellen von Abhängigkeiten zu einem Modul ausreicht, um anzunehmen, dass das Modul vorhanden ist, aber als ich den gesamten OCA-Code wiederholte, sah ich viele Beispiele von dem, was Sie sprechen. (viel für report_xls und Connector).

Ich habe aufgrund eines Moduls nicht die Fähigkeiten, Sicherheitsprobleme zu verstehen. Wenn das Modul nicht installiert ist, sollte für mich der Code des Moduls von oca_api nicht aufgerufen werden. aber vielleicht irre ich mich.

Grüße.

Ich dachte, dass es ausreicht, Abhängigkeiten zu einem Modul herzustellen, um anzunehmen, dass das Modul vorhanden ist.

Weitere Informationen finden Sie unter https://github.com/odoo/odoo/pull/14850

Wenn das Modul nicht installiert ist, sollte für mich der Code des Moduls von oca_api nicht aufgerufen werden.

Darin liegt das Problem. Dies ist nicht der Fall - Odoo importiert alle Module im Pfad addons in den Speicher. Aus diesem Grund ist der Import in das Modul in jedem Modul erfolgreich - unabhängig davon, ob das abhängige Modul tatsächlich installiert ist oder nicht.

Dies ist der Kern von Odoo, und realistisch gesehen gibt es keine Umgehung. Dies ist auch der Grund, warum ich meine Kunden nicht auf die gleiche Weise wie Odoo SA co-hoste. Ich bin neugierig, ob sie es geschafft haben, dies mit Odoo.sh zu lösen, aber ich vermute, dass sie in ihrem SaaS eine tickende Zeitbombe auf ihren Händen haben

Vielen Dank für all diese Klarstellungen. Schade, dass odoo / odoo # 14850 nicht akzeptiert wird.
Ich denke immer noch, dass das Erstellen vieler OCA-Module in Abhängigkeit von einer externen Bibliothek die Verwendung dieser Module sicherlich einschränken wird. Aber ein Modul scheint in der Tat keine Lösung zu sein.
Grüße und vielen Dank für Ihren Einblick.

Ich schließe dieses Problem. (verschoben in https://github.com/OCA/oca-decorators/issues/7)
Grüße und danke für all deine Kommentare.