Server-tools: [RFC] dekorator api.groups baru untuk fungsi

Saya pikir ini ide yang bagus - keamanan dengan ketidakjelasan (menyembunyikan tombol) tidak berfungsi.

Pertanyaannya adalah di mana meletakkan ini. Saya membuat modul OCA Python yang memiliki implementasi api.foreach di dalamnya, tetapi tidak banyak pergerakan untuk memasukkannya ke depan OCA

Menurut saya, memiliki pustaka API OCA adalah ide yang bagus. @lasley Anda hanya perlu membuat repo dengan mengikuti metode yang dimasukkan ke dalam tugas instance OCA ("Buat proyek") dan buat PR.

Tentang fitur ini,: +1: untuk menambahkannya, tetapi tidak dengan dekorator add_groups dan seterusnya. Ini harus ditangani dengan pewarisan: jika Anda menambahkan grup baru di dekorator pada metode yang ditimpa, grup itu akan ditambahkan ke daftar. Tentang penghapusan grup, maka Anda harus menggunakan teknik lain seperti di inti (misalnya, metode lain dengan lebih sedikit grup yang memanggil metode asli).

Hai! Terima kasih atas jawaban anda. Pustaka API OCA LGTM. Ide yang hebat !

tetapi tidak dengan add_groups dekorator dan sebagainya

Anda benar, ini memang bisa disederhanakan.

Tentang penghapusan grup, maka Anda harus menggunakan teknik lain seperti di inti (misalnya, metode lain dengan lebih sedikit grup yang memanggil metode asli).

Tidak yakin itu akan mencakup semua kebutuhan, tetapi kami akan membicarakannya dalam PR khusus terhadap repo baru.

@lasley Anda hanya perlu membuat repo dengan mengikuti metode yang dimasukkan ke dalam tugas instance OCA ("Buat proyek") dan buat PR.

@lasley , tolong ping saya ketika repo dibuat, saya akan memulai POC kemudian dan mencoba menyelesaikan pekerjaan di Hari Terbuka (/ Tertutup) berikutnya.

Menurut saya, memiliki pustaka API OCA adalah ide yang bagus. @lasley Anda hanya perlu membuat repo dengan mengikuti metode yang dimasukkan ke dalam tugas instance OCA ("Buat proyek") dan buat PR.

Poin bagus - pada saat itu saya tidak memiliki izin untuk melakukan ini. Saya tidak menemukan proses ini dalam contoh OCA- Saya akan menggali lebih banyak & melaporkan kembali dengan repo baru.

Hmmm ok ya jadi saya tidak dapat menemukan proses untuk pembuatan repo, jadi saya hanya akan melanjutkan dan membuat repo - tetapi sepertinya saya tidak memiliki izin. @pedrobaeza maukah Anda membuat repo OCA / python-oca kosong sehingga saya dapat mengirimkan PR untuk itu?

👍 Untuk memiliki dekorator yang melakukan ini. Saya memiliki ide untuk membuat dekorator @privileged yang akan melakukan hal yang sama dan dapat diimpor dari modul alat baru di alat-server.

Tetapi memiliki dekorator sebagai bagian dari perpustakaan pip mungkin juga. Saya hanya ingin tahu tentang nama @ api.groups. Bukankah itu akan membingungkan karena ini tidak berasal dari modul odoo api python?

Hai @ NL278 ,

Nah, soal name space, menurut saya tabrakan itu tidak mungkin terjadi, karena namanya adalah @ oca.groups dan bukan @ api.groups. (atau sesuatu yang serupa)

@legalsylvain Saya bereaksi terhadap penggunaan contoh pertama. Memiliki @oca.groups akan menyenangkan.

@legalsylvain Itu ide yang bagus!

Saya lebih suka menyimpan 'oca' sebagai paket namespace yang tersedia untuk semua paket oca. Kita bisa menamai paket baru ini 'oca-decorator'. Paket ini akan menyediakan 'oca.decorator' (atau oca.xyz)

from oca.decorator import groups

    @groups(..)
    def function_name():

Tentang groups Saya lebih suka nama yang lebih eksplisit misalnya allowed_groups .

lmi

@lasley ini adalah tugas di mana proses untuk repositori baru / PSC ditentukan: https://odoo-community.org/web#id = 264 & view_type = form & model = project.task & action = 468 & active_id = 2

Omg terima kasih Pedro! Untuk beberapa alasan saya mencari semuanya dari Project hingga Repo, tetapi tidak berpikir untuk memasukkan "PSC". Derp!

Saya masih memerlukan beberapa hak tambahan di OCA GitHub - Saya tidak memiliki tombol baru:

Coba lagi sekarang setelah saya mengubah peran Anda.

@lasley @pedro Mengapa python-oca ? Nama ini tidak ada artinya. Bagaimana Anda berencana menamai paket python?

@lmignon - Saya meminta saran dan ini yang terbaik. Paket python memiliki nama yang mirip.

Apa ide Anda? Aku mendengarkan.

@lasley Perhatian utama saya adalah menghindari pembuatan paket python monolitik. Jika tujuan utamanya adalah untuk menyediakan dekorator khusus baru mengapa tidak oca-dekorator. Nama harus bergantung pada cakupan fungsional yang tercakup oleh paket atau apa pun yang Anda inginkan. Setidaknya nama harus bermakna. IMO 'python-oca' terlalu lebar.

Saya ahli dengan oca-decorator , meskipun kita perlu menyusun modul sedikit berbeda, saya pikir kemudian untuk membuat dekorator tingkat atas di namespace. Cukup yakin saya awalnya seperti itu, tetapi kami mendorongnya kembali ke oca.helpers di LasLabs / python-oca # 1

Bagaimanapun, cukup mudah untuk membuat perubahan itu, dan saya pikir akan lebih baik untuk membahasnya dalam konteks kode. Karena saya yang membuat repo, akan menyerahkan PR dan menyertakan saran Anda - kemudian kita bisa berdiskusi dalam konteks daripada PR yang dibajak ini.

@lasley namespace oca harus tetap kosong. Jika tidak, tidak mungkin membuat paket python lain di bawah namespace yang sama.

Mengerti, jadi pada dasarnya kami hanya ingin mengganti nama paket helpers menjadi decorators , lalu menyebutnya skema kami untuk Python? Abstrak Misalnya oca-package-sub == oca.package.sub

yep: seringai: itulah idenya.

Sayang sekali ocapi diambil: smile_cat:

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

Saya punya pertanyaan tentang struktur kode ini. (mungkin pertanyaan saya tidak relevan, maaf)

Pada dasarnya, saya melihat dua cara untuk menulis kode ini.

A) melalui modul odoo klasik (dalam repositori yang sudah ada atau yang baru). jadi, untuk menggunakannya, kita harus menulis beberapa

from odoo.addons.my_oca_lib_in_module import my_decorator

B) melalui lib python.

Tampaknya Anda semua berbicara tentang solusi "B", dan tentu saja, ini adalah solusi yang lebih bersih.
Namun di sisi lain, saya khawatir teknologi tersebut akan memblokir beberapa pengguna yang tidak memiliki keterampilan teknis untuk menggunakan modul yang bergantung pada lib oca-python baru. Saya pikir sebagai contoh untuk orang-orang yang menginstal modul melalui UI, atau lainnya melalui odoo.sh (dan besok dengan appstore OCA, mungkin!). Saya tidak yakin bahwa semua sistem hosting akan memungkinkan untuk menginstal lib python kustom dengan mudah.
akan sangat disayangkan jika beberapa pengguna tidak memiliki kemungkinan untuk menginstal modul OCA, karena tergantung pada lib tambahan yang tidak dapat diinstal untuk beberapa orang.

Hanya ada satu contoh lain di OCA untuk saat ini. Openupgradelib. kode awalnya ada di proyek OpenUpgrade, dan dipindahkan ke python-lib eksternal. Bagi saya itu bukan blocking point bagi openupgradelib, karena melakukan upgrade adalah hal yang teknis.

Bagaimana menurut anda ?

Apakah kita tahu bagaimana Odoo.sh menangani dependensi pip?

IMO ini pada mereka untuk memperbaiki kunci external_depencies dalam manifes - kami memiliki banyak modul yang menggunakannya. Saya tidak berpikir modul yang menggunakan pustaka baru ini akan berbeda dari, katakanlah, barcodes_generator_abstract membutuhkan barcode

bukan untuk mengatakan Odoo.sh (atau Odoo.hs untuk orang Perancis) adalah Runbot berikutnya. Taruhan diambil.

😆 Ya kita tahu di mana taruhan saya terletak pada yang satu itu

kami memiliki banyak modul yang menggunakannya (oleh @lasley)

Memang, tapi ini sangat berbeda. Tentu saja, jika Anda menginginkan sistem yang menangani pembuatan kode batang, Anda harus menginstal lib kode batang. sama untuk tanda bintang, dll ...
tetapi ini sangat terbatas, dan mungkin beberapa pengguna di dunia tidak menginstal modul seperti itu karena mereka tidak dapat atau tidak tahu bagaimana melakukannya. tapi tidak ada alternatif lain. untuk menggunakan pembuatan kode batang, Anda memerlukan pustaka kode batang.

Di sini berbeda. Saya baru saja memperbarui analisis sumber kode OCA. saat ini ada 4182 modul. (modul yang hadir dalam dua pencapaian dihitung dua kali). Di sisi lain, Di semua 4182 modul, hanya ada 274 dependensi python. Jadi 94% modul OCA tidak bergantung pada libs python eksternal dan dapat diinstal dengan sangat mudah. detailnya:

Jika besok, ada lib ekstra oca python yang bagus dengan dekorator yang berguna (seperti yang kami coba jelaskan di utas ini yang mencoba memperbaiki masalah keamanan), sebagian besar modul OCA akan bergantung pada lib ini, selangkah demi selangkah.

Tujuan OCA adalah untuk mempromosikan kerja anggota OCA. Jadi jika keputusan seperti itu (untuk membuat lib untuk diinstal) mengurangi kemungkinan orang menggunakan modul OCA, saya pikir kita tidak boleh pergi ke arah ini untuk saat ini. Pertama kita bisa membuat repositori oca-decorator kecil, dengan modul klasik . Dan jika dalam 1/2 tahun sudah matang, dan jika penerapan dan sistem hosting juga lebih matang (*), akan sangat mudah untuk meletakkan semua kode di lib eksternal.

kode openupgrade telah ada selama bertahun-tahun dalam repositori openupgrade dan telah ditetapkan di lib eksternal baru-baru ini oleh @StefanRijnhart. Menurut saya perubahan ini bukan masalah besar.

(*): hosting dan sistem penerapan telah banyak berubah selama beberapa tahun terakhir. (mendapatkan kode dengan bzr, mendapatkan kode melalui github, menggunakan teknologi buildout, dan penerapan pypi yang lebih baru)

Saya ingin mendengar apa yang dipikirkan oleh @ OCA / board tentang hal itu. ini bukan hanya keputusan teknis, ini juga keputusan strategis

Sekarang https://github.com/OCA/oca-decorators tersedia, RFC ini dapat pindah ke sana.

@legalsylvain - Saya awalnya mengirimkan modul untuk api.foreach sebelum membuat ini sebagai perpustakaan. Lihatlah PR ini , dan Anda akan melihat mengapa kami mengabaikan strategi ini.

Penggunaan api hampir tidak mungkin ketika Anda mulai menghitung jalur impor yang 60-70 karakter, dan percobaan / kecuali yang harus dilakukan di sekitar setiap impor. Ini akan membuat pengadopsian modul pada dasarnya nol - impor lebih sulit daripada loop rekaman.

Yang cukup menarik, strategi percobaan / kecuali kami gagal total dengan dekorator, tetapi itu adalah topik yang sama sekali berbeda. Sekali lagi, saya berharap Odoo akan memperbaiki kunci external_dependencies .

@dreispt - adakah cara yang baik untuk memindahkan diskusi yang sudah ada ini ke repo lain? Ada banyak poin yang terungkap di sini yang saya tidak yakin akan terbawa dengan lancar.

Penggunaan api hampir tidak mungkin ketika Anda mulai menghitung jalur impor yang 60-70 karakter, dan percobaan / kecuali yang harus dilakukan di sekitar setiap impor

Saya tidak mengerti apa yang perlu dicoba / kecuali dalam solusi itu.

Untuk menggunakan dekorator oca @ foreach, definisikan dalam lib atau modul oca_api. :

Dampak solusi Lib
terapkan:

• pip install atau via buildout. Batasan SaaS.

file manifes:

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

File Python:

from oca_api import oca

Dampak solusi modul
terapkan:

• pip install atau unduh dan instal melalui UI atau melalui buildout atau hanya menambahkan modul dalam file addons. tidak ada batasan saas.

file manifes:

'depends': ['oca_api'],

File Python:

from odoo.addons.oca_api import oca

Atau apakah saya melewatkan sesuatu? Jika ya tolong perbaiki saya.

Salam.

Saya tidak mengerti apa yang perlu dicoba / kecuali dalam solusi itu.

Percobaan / pengecualian adalah apa yang harus kami lakukan saat mengimpor apa pun yang bukan inti Odoo, jadi contoh Anda adalah sebagai berikut:

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

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

Tapi ya dengan penamaan modul Anda, itu tidak seburuk milik saya.

Saya pikir banyak dari ini ada hubungannya dengan fakta bahwa modul tidak diinstal ke dalam DB, dan tidak dienkapsulasi ke lingkungan seperti kebanyakan modul. Artinya, ia menyediakan fungsionalitas ke lingkungan yang belum menginstal modul secara eksplisit, dan dapat dianggap sebagai masalah (keamanan atau lainnya).

@lmignon baru saja memaparkan argumen serupa di atas di https://github.com/OCA/webhook/pull/3#issuecomment -336935193. Saya pikir ini adalah percakapan paralel - pada dasarnya membahas cara kami menyediakan rangkaian fitur seperti ini.

Saya pribadi merasa bahwa @lmignon ada di sini & kami harus menyediakan ini sebagai lib. IIRC sarannya adalah alasan utama mengapa saya memindahkan dekorator foreach dari modul juga.

Hai @las.

Ow terima kasih! Saya pikir membuat dependensi ke modul sudah cukup untuk mengasumsikan bahwa modul tersebut ada, tetapi rgreping semua kode OCA, saya melihat banyak contoh dari apa yang Anda bicarakan. (banyak untuk report_xls, dan konektor).

Saya tidak memiliki keterampilan untuk memahami masalah keamanan, karena sebuah modul. Bagi saya, jika modul tidak diinstal, kode modul oca_api tidak boleh dipanggil. tapi mungkin aku salah.

Salam.

Saya pikir membuat dependensi ke modul sudah cukup untuk mengasumsikan bahwa modul itu ada,

Kunjungi https://github.com/odoo/odoo/pull/14850 untuk info lebih lanjut

Bagi saya, jika modul tidak diinstal, kode modul oca_api tidak boleh dipanggil.

Disitulah letak masalahnya. Ini tidak terjadi - Odoo mengimpor semua modul dalam jalur addons ke dalam memori. Karenanya, impor pada modul akan berhasil di modul mana pun - baik dependennya diinstal maupun tidak.

Ini adalah inti di Odoo, dan secara realistis tidak ada pengelakan. Ini juga mengapa saya tidak menjadi tuan rumah bersama bagi pelanggan saya dengan cara yang sama seperti yang dilakukan oleh Odoo SA. Saya ingin tahu apakah mereka berhasil menyelesaikan ini dengan Odoo.sh, tetapi dugaan saya adalah bahwa mereka memiliki bom waktu di tangan mereka di SaaS mereka.

Terima kasih untuk semua klarifikasi ini. Sayangnya odoo / odoo # 14850 tidak diterima.
Saya masih berpikir bahwa membuat banyak modul OCA bergantung pada lib eksternal pasti akan membatasi penggunaan modul ini. Tapi yah, modul sepertinya bukan solusi.
Salam dan terima kasih banyak atas wawasan Anda.

Saya menutup masalah ini. (dipindahkan ke https://github.com/OCA/oca-decorators/issues/7)
salam dan terima kasih atas semua komentar Anda.