From 4820450aef943e25aedc7e767e39f08cdadd8f18 Mon Sep 17 00:00:00 2001 From: Antony Lesuisse Date: Sun, 11 Nov 2012 03:10:22 +0100 Subject: [PATCH] merge trunk fixes bzr revid: al@openerp.com-20121111021022-jppw87f7l42shlwn --- doc/01_getting_started.rst | 5 +- doc/{04_user_roles.rst => 04_security.rst} | 0 ...st_framework.rst => 05_test_framework.rst} | 23 +++++++- doc/{api/core.rst => api_core.rst} | 0 doc/{api/models.rst => api_models.rst} | 0 doc/{api => }/field_level_acl.rst | 0 doc/{revisions => }/font_style.rst | 0 doc/import.rst | 2 +- doc/{o2m.txt => import_o2m.txt} | 0 doc/index.rst | 34 +++++++++++- doc/index.rst.inc | 55 ------------------- doc/list_font_style.rst | 28 ++++++++++ doc/{revisions => }/need_action_specs.rst | 0 doc/revisions/user_img_specs.rst | 13 ----- doc/{api => }/startup.rst | 0 doc/user_img_specs.rst | 26 +++++++++ 16 files changed, 109 insertions(+), 77 deletions(-) rename doc/{04_user_roles.rst => 04_security.rst} (100%) rename doc/{99_test_framework.rst => 05_test_framework.rst} (85%) rename doc/{api/core.rst => api_core.rst} (100%) rename doc/{api/models.rst => api_models.rst} (100%) rename doc/{api => }/field_level_acl.rst (100%) rename doc/{revisions => }/font_style.rst (100%) rename doc/{o2m.txt => import_o2m.txt} (100%) delete mode 100644 doc/index.rst.inc create mode 100644 doc/list_font_style.rst rename doc/{revisions => }/need_action_specs.rst (100%) delete mode 100644 doc/revisions/user_img_specs.rst rename doc/{api => }/startup.rst (100%) create mode 100644 doc/user_img_specs.rst diff --git a/doc/01_getting_started.rst b/doc/01_getting_started.rst index d126c4ccb82..79b2bc94298 100644 --- a/doc/01_getting_started.rst +++ b/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:: diff --git a/doc/04_user_roles.rst b/doc/04_security.rst similarity index 100% rename from doc/04_user_roles.rst rename to doc/04_security.rst diff --git a/doc/99_test_framework.rst b/doc/05_test_framework.rst similarity index 85% rename from doc/99_test_framework.rst rename to doc/05_test_framework.rst index 56951b1a8e1..17a7b480640 100644 --- a/doc/99_test_framework.rst +++ b/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. diff --git a/doc/api/core.rst b/doc/api_core.rst similarity index 100% rename from doc/api/core.rst rename to doc/api_core.rst diff --git a/doc/api/models.rst b/doc/api_models.rst similarity index 100% rename from doc/api/models.rst rename to doc/api_models.rst diff --git a/doc/api/field_level_acl.rst b/doc/field_level_acl.rst similarity index 100% rename from doc/api/field_level_acl.rst rename to doc/field_level_acl.rst diff --git a/doc/revisions/font_style.rst b/doc/font_style.rst similarity index 100% rename from doc/revisions/font_style.rst rename to doc/font_style.rst diff --git a/doc/import.rst b/doc/import.rst index bffb1af334b..147907722f2 100644 --- a/doc/import.rst +++ b/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`` diff --git a/doc/o2m.txt b/doc/import_o2m.txt similarity index 100% rename from doc/o2m.txt rename to doc/import_o2m.txt diff --git a/doc/index.rst b/doc/index.rst index 7b8bf5e639b..d62adb2c0bd 100644 --- a/doc/index.rst +++ b/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 + + + diff --git a/doc/index.rst.inc b/doc/index.rst.inc deleted file mode 100644 index 535ecb5809d..00000000000 --- a/doc/index.rst.inc +++ /dev/null @@ -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 diff --git a/doc/list_font_style.rst b/doc/list_font_style.rst new file mode 100644 index 00000000000..f47a654aa34 --- /dev/null +++ b/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 + + + [...] + diff --git a/doc/revisions/need_action_specs.rst b/doc/need_action_specs.rst similarity index 100% rename from doc/revisions/need_action_specs.rst rename to doc/need_action_specs.rst diff --git a/doc/revisions/user_img_specs.rst b/doc/revisions/user_img_specs.rst deleted file mode 100644 index 3be2ee76d17..00000000000 --- a/doc/revisions/user_img_specs.rst +++ /dev/null @@ -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. diff --git a/doc/api/startup.rst b/doc/startup.rst similarity index 100% rename from doc/api/startup.rst rename to doc/startup.rst diff --git a/doc/user_img_specs.rst b/doc/user_img_specs.rst new file mode 100644 index 00000000000..c6729eed920 --- /dev/null +++ b/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.