Server-tools: [RFC] 기능을위한 새로운 api.groups 데코레이터

나는 이것이 좋은 생각이라고 생각합니다.-모호한 보안 (버튼 숨기기)이 작동하지 않습니다.

질문은 이것을 어디에 둘 것인가입니다. api.foreach 구현이 포함 된 OCA Python 모듈 을 만들었지 만 OCA 전면으로 가져 오는 데는 별다른 움직임이 없었습니다.

나는 여전히 OCA API 라이브러리를 갖는 것이 좋은 생각이라고 생각합니다. @lasley OCA 인스턴스 작업 ( "프로젝트 만들기")에 넣은 방법에 따라 저장소를 만들고 만하면 됩니다.

이 기능에 대해 : +1 : 추가 용이지만 데코레이터 add_groups 등은 사용하지 않습니다. 이것은 상속으로 처리되어야합니다 : 덮어 쓴 메소드의 데코레이터에 새 그룹을 추가하면 해당 그룹이 목록에 추가됩니다. 그룹 제거에 대해서는 코어에서와 같은 다른 기술을 사용해야합니다 (예 : 원래 메서드를 호출하는 그룹이 더 적은 다른 메서드).

안녕하세요 ! 답변 해 주셔서 감사합니다. OCA API 라이브러리 LGTM. 좋은 생각!

그러나 데코레이터 add_groups 등은 사용하지 않습니다.

당신 말이 맞아요. 정말 단순화 될 수 있습니다.

그룹 제거에 대해서는 코어에서와 같은 다른 기술을 사용해야합니다 (예 : 원래 메서드를 호출하는 그룹이 더 적은 다른 메서드).

모든 요구 사항을 충족 할 수 있을지 확신 할 수 없지만 새 저장소에 대한 특정 PR에서 이에 대해 이야기하겠습니다.

@lasley OCA 인스턴스 작업 ( "프로젝트 만들기")에 넣은 방법에 따라 저장소를 만들고 만하면 됩니다.

@lasley , 보내 주세요. POC를 시작한 다음 다음 Open (/ Closed) Days에 작업을 완료하려고합니다.

나는 여전히 OCA API 라이브러리를 갖는 것이 좋은 생각이라고 생각합니다. @lasley OCA 인스턴스 작업 ( "프로젝트 만들기")에 넣은 방법에 따라 저장소를 만들고 만하면 됩니다.

좋은 점-당시에는이 작업을 수행 할 권한이 없었습니다. 그래도 OCA 인스턴스에서이 프로세스를 찾을 수 없습니다. 조금 더 파고 새 저장소로 다시보고하겠습니다.

흠 괜찮습니다. 그래서 리포지토리 생성 프로세스를 찾을 수 없으므로 계속해서 리포지토리를 생성하려고했지만 권한이없는 것 같습니다. @pedrobaeza PR을 제출할 수 있도록 빈 OCA / python-oca 저장소를 만드시겠습니까?

👍이 작업을 수행하는 데코레이터가 있습니다. 동일한 작업을 수행하고 서버 도구의 새 도구 모듈에서 가져올 수있는 @privileged 데코레이터를 만드는 아이디어가있었습니다.

그러나 데코레이터를 pip 라이브러리의 일부로 사용하는 것도 좋습니다. @ api.groups라는 이름 만 궁금합니다. 이것이 odoo api python 모듈에서 오지 않기 때문에 혼란스럽지 않습니까?

안녕하세요 @ NL66278 ,

음, 이름 공간에 관해서는 이름이 @ api.groups가 아닌 @ oca.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

Omg 감사합니다 Pedro! 어떤 이유로 프로젝트에서 Repo까지 모든 것을 검색했지만 "PSC"를 포함 할 생각은하지 않았습니다. Derp!

그래도 OCA GitHub에 대한 추가 권한이 필요합니다. 새 버튼이 없습니다.

역할을 변경 했으니 지금 다시 시도하세요.

@lasley @pedro 왜 python-oca ? 이 이름은 의미가 없습니다. 파이썬 패키지의 이름을 어떻게 지정할 계획입니까?

@lmignon- 나는 제안을 요청했고 이것이 최고의 것이었다. 파이썬 패키지의 이름은 비슷합니다.

무슨 생각이야? 나는 모두 귀입니다.

@lasley 나의 주된 관심사는 모노 리틱 파이썬 패키지의 생성을 피하는 것입니다. 새로운 전문 데코레이터를 제공하는 것이 주요 목표라면 왜 oca-decorator가 아닙니다. 이름은 패키지에 포함 된 기능 범위 또는 원하는 항목에 따라 달라야합니다. 최소한 이름은 의미가 있어야합니다. IMO 'python-oca'가 너무 넓습니다.

나는 oca-decorator 를 잘 알고 있지만, 우리는 모듈을 조금 다르게 구조화 할 필요가 있지만, 데코레이터를 네임 스페이스에서 최상위 레벨로 만들기 위해 생각합니다. 원래 그렇게했다고 확신하지만 LasLabs / python-oca # 1에서 oca.helpers 로 다시 밀어 넣었습니다.

어쨌든 그 변화를 만드는 것은 충분히 쉬우 며, 코드의 맥락에서 논의하는 것이 더 나을 것이라고 생각합니다. 내가 repo를 만들었을 때 PR을 제출하고 제안을 포함 할 것입니다. 그러면이 하이재킹 된 PR 대신 컨텍스트에서 논의 할 수 있습니다.

@lasley oca 네임 스페이스는 비어 있어야합니다. 그렇지 않으면 동일한 네임 스페이스 아래에 다른 파이썬 패키지를 생성 할 수 없습니다.

알겠습니다. 기본적으로 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) 파이썬 lib를 통해.

여러분 모두 솔루션 "B"에 대해 이야기하고있는 것 같습니다. 물론 더 깨끗한 솔루션입니다.
그러나 다른 한편으로는 그러한 기술이 새로운 oca-python lib에 의존하는 모듈을 사용하는 기술이없는 일부 사용자를 차단 할까 봐 걱정됩니다. UI를 통해 모듈을 설치하거나 odoo.sh를 통해 다른 모듈을 설치하는 사람들에게 예를 들어 보겠습니다 (그리고 내일 OCA 앱 스토어에서!). 모든 호스팅 시스템이 사용자 지정 Python lib를 쉽게 설치할 수 있는지 잘 모르겠습니다.
일부 사용자에게는 설치할 수없는 추가 lib에 의존하기 때문에 일부 사용자가 OCA 모듈을 설치할 가능성이 없다면 유감입니다.

당분간 OCA에는 단 하나의 다른 예가 있습니다. openupgradelib. 코드는 처음에 OpenUpgrade 프로젝트에 있었고 외부 python-lib로 이동되었습니다. 나에게는 업그레이드를 만드는 것이 기술적 인 일이기 때문에 openupgradelib의 차단 지점이 아닙니다.

어떻게 생각해 ?

Odoo.sh가 pip 종속성을 처리하는 방법을 알고 있습니까?

IMO 이것은 매니페스트에서 external_depencies 키를 수정하기위한 것입니다-우리는 그것을 사용하는 많은 모듈을 가지고 있습니다. 이 새로운 라이브러리를 사용하는 모듈이 barcodes_generator_abstract 요구하는 barcode barcodes_generator_abstract 와 다를 것이라고 생각하지 않습니다.

Odoo.sh (또는 프랑스 인의 경우 Odoo.hs)는 다음 Runbot입니다. 내기.

😆 그래 우리는 내 베팅 이 어디에 있는지 알고

우리는 그것을 사용하는 많은 모듈을 가지고 있습니다 (@lasley에 의해)

사실, 그러나 그것은 아주 다릅니다. 물론 바코드 생성을 처리하는 시스템을 원한다면 barcode lib를 설치해야합니다. 별표 등도 동일합니다.
그러나 이것은 매우 제한적이며 아마도 세계의 일부 사용자는 할 수 없거나 방법을 모르기 때문에 그러한 모듈을 설치하지 않을 것입니다. 그러나 대안이 없습니다. 바코드 생성을 사용하려면 바코드 라이브러리가 필요합니다.

여기는 다릅니다. 방금 OCA 코드 소스 분석을 업데이트했습니다. 오늘날에는 4182 개의 모듈이 있습니다. (두 이정표에있는 모듈은 두 번 계산됩니다). 반면에 모든 4182 모듈에는 274 개의 파이썬 종속성 만 있습니다. 따라서 OCA 모듈의 94 %는 외부 파이썬 라이브러리에 의존하지 않고 매우 쉽게 설치할 수 있습니다. 세부 사항 :

내일 유용한 데코레이터가있는 좋은 추가 oca python lib가 있다면 (보안 문제를 해결하기 위해이 스레드에서 설명하려고하는 것과 같은) 대부분의 OCA 모듈은 단계별로이 lib에 의존합니다.

OCA의 목적은 OCA 회원들의 작업을 촉진하는 것입니다. 따라서 그러한 결정 (설치할 lib 생성)이 사람들이 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자인 가져 오기 경로와 각 가져 오기를 둘러싼 try / except를 계산할 때 API 사용은 거의 불가능했습니다. 이것은 기본적으로 모듈의 채택을 0으로 만들 것입니다-가져 오기는 레코드 루프보다 더 어렵습니다.

흥미롭게도 우리의 try / except 전략은 데코레이터와 함께 비참하게 실패하지만 그것은 완전히 다른 주제입니다. 다시 말하지만 Odoo가 external_dependencies 키를 수정했으면합니다.

@dreispt- 기존 토론을 다른 저장소로 옮기는 좋은 방법이 있습니까? 여기에는 유동적으로 넘어갈 지 확신 할 수없는 많은 점이 노출되어 있습니다.

60-70자인 가져 오기 경로와 각 가져 오기를 둘러싼 try / except를 계산할 때 API 사용이 거의 불가능했습니다.

나는 그 해결책에 필요한 것을 제외하고 시도가 무엇인지 이해하지 못합니다.

oca @ foreach 데코레이터를 사용하려면 oca_api lib 또는 모듈에서 정의합니다. :

Lib 솔루션의 영향
배포 :

• pip 설치 또는 빌드 아웃을 통해. Saas 제한.

매니페스트 파일 :

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

Python 파일 :

from oca_api import oca

모듈 솔루션의 영향
배포 :

• pip 설치 또는 다운로드 및 UI 또는 빌드 아웃을 통해 설치하거나 애드온 파일에 모듈을 추가하십시오. 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:...

하지만 예, 모듈 이름을 지정하면 내 것만 큼 나쁘지 않습니다.

이 중 많은 부분이 모듈이 DB에 설치되지 않고 대부분의 모듈처럼 환경에 캡슐화되지 않는다는 사실과 관련이 있다고 생각합니다. 이는 모듈을 명시 적으로 설치하지 않은 환경에 기능을 제공하고 있으며 문제 (보안 또는 기타)로 간주 될 수 있음을 의미합니다.

@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이 허용되지 않는 것은 유감입니다.
나는 여전히 외부 lib에 따라 많은 OCA 모듈을 만드는 것이 이러한 모듈의 사용을 확실히 제한 할 것이라고 생각합니다. 하지만 모듈은 실제로 해결책이 아닌 것 같습니다.
귀하의 통찰력에 감사드립니다.

이 문제를 닫습니다. (https://github.com/OCA/oca-decorators/issues/7로 이동)
모든 의견에 감사드립니다.