merge trunk fixes

bzr revid: al@openerp.com-20121111021022-jppw87f7l42shlwn

doc/01_getting_started.rst

@@ -36,9 +36,6 @@ Next step is to initialize the shared repository and download the sources. Get t
 This will create the following structure inside your ``source`` directory, and fetch the latest source code from ``trunk``::
 
   drwxrwxr-x  3 openerp openerp 4096 2012-04-17 11:10 addons
-  drwxrwxr-x  3 openerp openerp 4096 2012-04-17 11:10 client
-  drwxrwxr-x  3 openerp openerp 4096 2012-04-17 11:10 client-web
-  drwxrwxr-x  2 openerp openerp 4096 2012-04-17 11:10 dump
   drwxrwxr-x  3 openerp openerp 4096 2012-04-17 11:10 misc
   drwxrwxr-x  3 openerp openerp 4096 2012-04-17 11:10 server
   drwxrwxr-x  3 openerp openerp 4096 2012-04-17 11:10 web
@@ -52,7 +49,7 @@ Some dependencies are necessary to use OpenERP. Depending on your environment, y
     python-psycopg2 python-pybabel python-pychart python-pydot
     python-pyparsing python-reportlab python-simplejson python-tz
     python-vatnumber python-vobject python-webdav python-werkzeug python-xlwt
-    python-yaml python-zsi python-imaging python-matplotlib 
+    python-yaml python-imaging python-matplotlib 
 
 Next step is to initialize the database. This will create a new openerp role::
 

doc/05_test_framework.rst

@@ -87,9 +87,9 @@ In addition to the above possibilities, when invoked with a non-existing module
 sub-modules.
 
 Depending on the unittest2_ class that is used to write the tests (see
-``openerp.tests.common`` for some helper classes that you can re-use), a database
-may be created before the test is run, and the module providing the test will
-be installed on that database.
+:mod:`openerp.tests.common` for some helper classes that you can re-use), a
+database may be created before the test is run, and the module providing the
+test will be installed on that database.
 
 Because creating a database, installing modules, and then dropping it is
 expensive, it is possible to interleave the run of the ``fast_suite`` tests
@@ -98,3 +98,20 @@ each requested module is installed, its fast_suite tests are run. The database
 is thus created and dropped (and the modules installed) only once.
 
 .. _unittest2: http://pypi.python.org/pypi/unittest2
+
+TestCase subclasses
+-------------------
+
+.. automodule:: openerp.tests.common
+   :members:
+
+.. note::
+
+    The `setUp` and `tearDown` methods are not part of the tests. Uncaught
+    exceptions in those methods are errors, not test failures. In particular,
+    a failing `setUp` will not be followed by a `tearDown` causing any
+    allocated resource in the `setUp` to not be released by the `tearDown`.
+
+    In the :py:class:`openerp.tests.common.TransactionCase` and
+    :py:class:`openerp.tests.common.SingleTransactionCase`, this means the
+    test suite can hang because of unclosed cursors.

doc/import.rst

@@ -46,7 +46,7 @@ no other references to the sub-records in the system), they have to be
 spliced into the matrix somehow. This is done by adding lines composed
 *only* of o2m record fields below the main record:
 
-.. literalinclude:: o2m.txt
+.. literalinclude:: import_o2m.txt
 
 the sections in double-lines represent the span of two o2m
 fields. During parsing, they are extracted into their own ``data``

doc/index.rst

@@ -4,4 +4,36 @@
 OpenERP Server Developers Documentation
 ========================================
 
-.. include:: index.rst.inc
+OpenERP Server
+''''''''''''''
+
+.. toctree::
+   :maxdepth: 2
+
+   01_getting_started
+   02_architecture
+   03_module_dev
+   04_security
+   05_test_framework
+   90_using_gunicorn
+
+   field_level_acl
+   import
+   module-versioning
+   on_change_tips
+   test-framework
+   user_img_specs
+   need_action_specs
+   font_style
+
+OpenERP Server API
+''''''''''''''''''
+
+.. toctree::
+   :maxdepth: 1
+
+   api_core.rst
+   api_models.rst
+
+
+

doc/index.rst.inc

@@ -1,55 +0,0 @@
-OpenERP Server
-''''''''''''''
-
-.. toctree::
-   :maxdepth: 2
-
-   01_getting_started
-   02_architecture
-   03_module_dev
-   04_user_roles
-   90_using_gunicorn
-   99_test_framework
-
-OpenERP Server API
-''''''''''''''''''
-
-.. toctree::
-   :maxdepth: 1
-
-   api/core
-   api/models
-   api/startup
-
-Main revisions and new features
-'''''''''''''''''''''''''''''''
-
-.. toctree::
-   :maxdepth: 1
-
-   revisions/user_img_specs
-   revisions/need_action_specs
-   revisions/font_style
-
-
-OpenERP Server
-''''''''''''''
-
-.. toctree::
-   :maxdepth: 1
-
-   import
-   module-versioning
-   on_change_tips
-   test-framework
-
-Changed in 7.0
-++++++++++++++
-
-.. toctree::
-   :maxdepth: 1
-
-   api/user_img_specs
-   api/need_action_specs
-   api/font_style
-   api/field_level_acl

doc/list_font_style.rst

@@ -0,0 +1,28 @@
+Font style in list views
+========================
+
+.. versionadded:: 7.0
+
+This revision adds font styles in list views. Before this revision it was
+possible to define some colors in list view. This revision allows to define 
+the a font style, based on an evaluated Python expression. The definition syntax is 
+the same than the colors feature. Supported styles are bold, italic and 
+underline.
+
+Rng modification
++++++++++++++++++
+
+This revision adds the ``fonts`` optional attribute in ``view.rng``.
+
+Addon implementation example
+++++++++++++++++++++++++++++
+
+In your ``foo`` module, you want to specify that when any record is in ``pending`` 
+state then it should be displayed in bold in the list view. Edit your foo_view.xml
+file that define the views, and add the fonts attribute to the tree tag.
+
+.. code-block:: xml
+
+  <tree string="Foo List View" fonts="bold:state=='pending'">
+    [...]
+  </tree>

doc/revisions/user_img_specs.rst

@@ -1,13 +0,0 @@
-User avatar
-===========
-
-.. versionadded:: 7.0
-
-This revision adds an avatar for users. This replaces the use of gravatar to emulate avatars, used in views like the tasks kanban view. Two fields have been added to the res.users model:
-
- - avatar_big, a binary field holding the image. It is base-64 encoded, and PIL-supported. Images stored are resized to 540x450 px, to limitate the binary field size.
- - avatar, a function binary field holding an automatically resized version of the avatar_big field. It is also base-64 encoded, and PIL-supported. Dimensions of the resized avatar are 180x150. This field is used as an inteface to get and set the user avatar.
-
-When changing the avatar through the avatar function field, the new image is automatically resized to 540x450, and stored in the avatar_big field. This triggers the function field, that will compute a 180x150 resized version of the image.
-
-An avatar field has been added to the users form view, as well as in Preferences. When creating a new user, a default avatar is chosen among 6 possible default images.

doc/user_img_specs.rst

@@ -0,0 +1,26 @@
+User avatar
+===========
+
+.. versionadded:: 7.0
+
+This revision adds an avatar for users. This replaces the use of
+gravatar to emulate avatars, used in views like the tasks kanban
+view. Two fields have been added to the res.users model:
+
+* ``avatar_big``, a binary field holding the image. It is base-64
+  encoded, and PIL-supported. Images stored are resized to 540x450 px,
+  to limitate the binary field size.
+
+* ``avatar``, a function binary field holding an automatically resized
+  version of the avatar_big field. It is also base-64 encoded, and
+  PIL-supported. Dimensions of the resized avatar are 180x150. This
+  field is used as an inteface to get and set the user avatar.
+
+When changing the avatar through the avatar function field, the new
+image is automatically resized to 540x450, and stored in the
+avatar_big field. This triggers the function field, that will compute
+a 180x150 resized version of the image.
+
+An avatar field has been added to the users form view, as well as in
+Preferences. When creating a new user, a default avatar is chosen
+among 6 possible default images.