c2c-oerpscenario team mailing list archive

["Xavier ALT \(Thamini\)" <771700@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Steps to reproduce the problem:

take a object with a view like this:

<group attrs="{'readonly': ['|', ('version','>',1),('state','!=','draft')]}">
  <field name="version"/>
</group>
<field name="state"/>

- state: is a selection field with a default value of "draft"
- version: is an integer field with a default value of 1

When creating this kind of object, the group will appear readonly on the
web client, which is wrong.

After digging into the javascript, following are the operations the
form_evalExpr perform:

1. push "|" to the stack
2. compare version_value > 1
3. compare version_value != 'draft'
4. evaluate the or and return the result

The problem apprea on step 3., the "elem" variable is not reinitialized
on each loop, so is compare with the value of the widget found in
previous step (2.), see patch attached for a one line fix.

** Affects: openobject-client-web
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/771700

Title:
  web 6.0: form_evalExpr fail on complex expression (patch provided)

Status in OpenERP Web Client:
  New

Bug description:
  Steps to reproduce the problem:

  take a object with a view like this:

  <group attrs="{'readonly': ['|', ('version','>',1),('state','!=','draft')]}">
    <field name="version"/>
  </group>
  <field name="state"/>

  - state: is a selection field with a default value of "draft"
  - version: is an integer field with a default value of 1

  When creating this kind of object, the group will appear readonly on
  the web client, which is wrong.

  After digging into the javascript, following are the operations the
  form_evalExpr perform:

  1. push "|" to the stack
  2. compare version_value > 1
  3. compare version_value != 'draft'
  4. evaluate the or and return the result

  The problem apprea on step 3., the "elem" variable is not
  reinitialized on each loop, so is compare with the value of the widget
  found in previous step (2.), see patch attached for a one line fix.