Odoo 中文社区

    • 注册
    • 登录
    • 搜索
    • 版块
    • 标签
    • 热门
    • 用户
    • 群组

    Odoo中文社区可以通过以下两个域名访问:shine-it.net , odoo.net.cn

    由于系统升迁的原因,本论坛部分较早期的内容存在格式和链接损坏失效的问题,并非本论坛系统本身的缺陷,望谅解

    本社区没有维护任何QQ群讨论组,任何与本社区同名的QQ群讨论组的言论与本社区无关!

    开发人员可以登录gitter讨论组: http://gitter.im/odoo-china/Talk, 需要github账号

    如果您登录系统碰到问题,请在微信公众号留言:

    请教一个对象权限设定

    Odoo 开发与实施交流
    6
    15
    8904
    正在加载更多帖子
    • 从旧到新
    • 从新到旧
    • 最多赞同
    回复
    • 在新帖中回复
    登录后回复
    此主题已被删除。只有拥有主题管理权限的用户可以查看。
    • B
      breterniu 最后由 编辑

      对象的访问权限与工作流的状态相关,例如"通过审批"状态下,对象不可修改和删除.
      遗憾的是openerp没有直接的与工作流activity相关的访问控制设定方式。
      变通方式是通过“系统管理”-〉“安全设定”-〉“记录规则”,新建一条规则:
      如设置筛选条件:
        [('state','=','proved')]

      发现“审核通过”的记录仍可修改。
      此规则为何无效?

      1 条回复 最后回复 回复 引用 0
      • mrshelly
        mrshelly 最后由 编辑

        在对象字段 stats 中去设置...

        1 条回复 最后回复 回复 引用 0
        • B
          breterniu 最后由 编辑

          重申一下权限规则:
                状态(state)='proved'的记录可查看,但不可修改和删除。

          对象字段上只能设置domain或用户组,没有权限相关的阿

          逻辑上不对啊,对象的访问权限与字段值相关,怎么会在字段上设置?

          1 条回复 最后回复 回复 引用 0
          • mrshelly
            mrshelly 最后由 编辑

            我没管你重申不重申...

            <br />...<br />&nbsp; &nbsp; &nbsp; &nbsp; &#039;date_order&#039;:fields.date(&#039;Date Ordered&#039;, required=True, states={&#039;confirmed&#039;:[(&#039;readonly&#039;,True)], &#039;approved&#039;:[(&#039;readonly&#039;,True)]}, select=True, help=&quot;Date on which this document has been created.&quot;),<br /><br />...<br />
            



            注意看 字段的 states 属性....

            1 条回复 最后回复 回复 引用 0
            • digitalsatori
              digitalsatori 管理员 最后由 编辑

              @breterniu 根据对象状态来设置访问规则有两种方法。mrshelly很详尽的跟你解释了如何在对象的字段级别根据状态设置访问规则,另一种就是记录级的访问规则,就是你提到的方法。
              之所以你的方法不成功,是因为你只为该对象设置了读的权限规则,对增,删,改并没有设置权限规则,OpenERP对不设定规则的表示默认具有该权限。对于你的需求,你可以再增加一条记录规则应用于(create, write, delete): [('state','!=','approved')]

              【上海先安科技】(tony AT openerp.cn)

              1 条回复 最后回复 回复 引用 0
              • B
                breterniu 最后由 编辑

                感谢@digitalsatori,@mrshelly详细的说明.
                (1)按mrshelly进行字段级定义可以工作,然而有不合理之处,一是逻辑上是对象级权限,按字段设置太繁琐;二是应为通过配置实现,而不是代码。
                (2)按digitalsatori记录级的方法测试了一下仍不成功,[('state','!=','approved')],从逻辑上也有些问题,A-〉B,并不能推导出!A->!B,您说呢


                1 条回复 最后回复 回复 引用 0
                • mrshelly
                  mrshelly 最后由 编辑

                  理论上, 这个 states 可以在 view xml 里配置, 这样,就可以通过配置实现了.
                  但是.... 这个 states 属性的OE处理, 从  5.0.x 开屎 就BUG不断... 至少6.0.3  还是存在有很多问题. 具体的可以搜索BBS里我关于 attrs 的贴子.

                  如果这个BUG解决了. 你就可以从 view xml 中去配置玩这些东西了...(如果你的条件不复杂....)

                  1 条回复 最后回复 回复 引用 0
                  • Joshua
                    Joshua 管理员 最后由 编辑

                    我测试了按照[('state','!=','approved')] 应该是可以的,不知道楼主是用什么账号登陆,如果是admin?还是你的状态名字写错了。你试试用非管理员的用户登陆。而且逻辑上也没问题,你要的是在approve下不能修改换句话那就是在draft下或者done的状态可以修改。因为不知道你实际是想怎么用,不过在定义权限的时候,也是按上面digitalsatori说的那样,如果你没给[b]改,增,删[/b]定义一个domain他就默认你可以在任何状态修改。你一开始定义read没效是因为那样定义的的意思只是state为apprved的时候才能在tree view上看到,对[b] 改,增,删[/b]完全没有约束。

                    【上海先安科技】(joshua AT openerp.cn),欢迎关注公众号:openerp_cn

                    1 条回复 最后回复 回复 引用 0
                    • B
                      breterniu 最后由 编辑

                      再次感谢!
                        用记录规则方式似影响到对象动态权限,然而中间出现很多莫名其妙错误,如图所示,如字符集问题,一些字段仍可更新等等。
                        (1)用记录规则定义与状态相关的对象权限仍不是合理的方案,基于工作流状态的ACL方式(通过配置文件)应是解决办法。目前基于字段级定义更可靠些。
                        (2)OPENERP应偏实施而不是二次开发。

                      [quote author=Joshua link=topic=2753.msg9274#msg9274 date=1328665839]
                      我测试了按照[('state','!=','approved')] 应该是可以的,不知道楼主是用什么账号登陆,如果是admin?还是你的状态名字写错了。你试试用非管理员的用户登陆。而且逻辑上也没问题,你要的是在approve下不能修改换句话那就是在draft下或者done的状态可以修改,因为不知道你实际是想怎么用。不过在定义权限的时候,也是按上面digitalsatori说的那样,如果你没给[b]改,增,删[/b]定义一个domain他就默认你可以在任何状态修改。你一开始定义read没效是因为,那样定义的的意思只是state为apprved的时候才能在tree view上看到,对[b] 改,增,删[/b]完全没有约束。
                      [/quote]

                      1 条回复 最后回复 回复 引用 0
                      • wjfonhand
                        wjfonhand 最后由 编辑

                        “OPENERP应偏实施而不是二次开发”

                        这个说法有什么依据呢?
                        我倒是觉得OpenERP的实施过程以二次开发为主配置为辅。

                        GoodERP -- Odoo China fork

                        1 条回复 最后回复 回复 引用 0
                        • Joshua
                          Joshua 管理员 最后由 编辑

                          @breterniu
                          字符集问题。估计不是因为rule的引入所引起的。

                          【上海先安科技】(joshua AT openerp.cn),欢迎关注公众号:openerp_cn

                          1 条回复 最后回复 回复 引用 0
                          • B
                            breterniu 最后由 编辑

                            (1)看了openerp其他模块代码,基于工作流状态的权限设定定义在字段上是通行的做法:如
                            readonly=True, states={'draft':[('readonly',False)]},
                            (2)由于对openerp开发还不是很了解,做出“以实施为主”的判断可能有误。这个问题可延伸至如何实现openerp的商业价值?
                                看了一下,Openerp主要还是面向生产制造企业,咨询和实施的价值应大于二次开发,若不是基于业务模型及开发技术透彻的掌握,二次开发是否会破坏原有的业务设计?
                                若是基于openerp平台开发框架,开发新的行业应用是否是openerp的方向?

                               
                            [quote author=Jeff link=topic=2753.msg9282#msg9282 date=1328691473]
                            “OPENERP应偏实施而不是二次开发”

                            这个说法有什么依据呢?
                            我倒是觉得OpenERP的实施过程以二次开发为主配置为辅。
                            [/quote]

                            1 条回复 最后回复 回复 引用 0
                            • mrshelly
                              mrshelly 最后由 编辑

                              我猜官方旨在推进 openobject 框架....

                              1 条回复 最后回复 回复 引用 0
                              • J
                                jerry79 最后由 编辑

                                attrs="{'readonly':[('state','!=','draft')]} 这样的设置只能解决字段在流程的某个状态下的通用权限设置,而不能针对该流程状态下的不同用户做设置,比如说proved状态下,某个按钮只能主管看他,其他用户看不到,就必须加上类似attrs="{'invisible': [('user_id', '!=', uid) ] }",即判断当前用户是否与流程设置的用户相符。这样的设置有些过于麻烦,理论上workflow应该允许为每一个流程节点设置权限,不过还没有研究明白。

                                1 条回复 最后回复 回复 引用 0
                                • First post
                                  Last post