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
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::
--- /dev/null
+=================================================
+Security in OpenERP: users, groups and user roles
+=================================================
+
+Users and user roles are critical points concerning internal security in
+OpenERP. OpenERP provides several security mechanisms concerning user roles,
+all implemented in the OpenERP Server. They are implemented in the lowest
+server level, which is the ORM engine. OpenERP distinguishes three different
+concepts:
+
+ - user: a person identified by its login and password. Note that all employees
+ of a company are not necessarily OpenERP users; an user is somebody who
+ accesses the application.
+ - group: a group of users that has some access rights. A group gives its
+ access rights to the users that belong to the group. Ex: Sales Manager,
+ Accountant, etc.
+ - security rule: a rule that defines the access rights a given group grants
+ to its users. Security rules are attached to a given resource, for example
+ the Invoice model.
+
+Security rules are attached to groups. Users are assigned to several groups.
+This gives users the rights that are attached to their groups. Therefore
+controlling user roles is done by managing user groups and adding or modifying
+security rules attached to those groups.
+
+Users
+======
+
+Users represent physical persons using OpenERP. They are identified with
+a login and a password,they use OpenERP, they can edit their own preferences, ...
+By default, a user has no access right. The more we assign groups to the user,
+the more he or she gets rights to perform some actions. A user may belong
+to several groups.
+
+User groups
+===========
+
+The groups determine the access rights to the different resources. A user
+may belong to several groups. If he belongs to several groups, we always
+use the group with the highest rights for a selected resource. A group
+can inherit all the rights from another group
+
+Figure 3 shows how group membership is displayed in the web client. The user
+belongs to Sales / Manager, Accounting / Manager, Administration / Access Rights,
+Administration / Configuration and Human Resources / Employee groups. Those
+groups define the user access rights.
+
+Figure 3: Example of group membership for a given user
+
+
+Record rules
+============
+
+Security rules are attached to groups. You can assign several security
+rules at the group level, each rule being of one of the following types :
+
+ - access rights are global rights on an object,
+ - record rules are records access filters,
+ - record field rules are fields access filters,
+ - workflow transition rules are operations rights.
+
+You can also define rules that are global, i.e. they are applied to all
+users, indiscriminately of the groups they belong to. For example, the
+multi-company rules are global; a user can only see invoices of the companies
+he or she belongs to.
+
+
+Concerning configuration, it is difficult to have default generic configurations
+that suit all applications. Therefore, like SAP, OpenERP is by default
+pre-configured with best-practices.
+
+Access rights
++++++++++++++
+
+Access rights are rules that define the access a user can have on a particular
+object . Those global rights are defined per document type or model. Rights
+follow the CRUD model: create, read (search), update (write), delete. For
+example, you can define rules on invoice creation. By default, adding a
+right to an object gives the right to all records of that specific object.
+
+Figure 4 shows some of the access rights of the Accounting / Accountant group.
+The user has some read access rights on some objects.
+
+Figure 4: Access rights for some objects.
+
+Record rules
+++++++++++++
+
+When accessing an object, records are filtered based on record rules. Record
+rules or access filters are therefore filters that limits records of an
+object a group can access. A record rule is a condition that each record
+must satisfy to be created, read, updated (written) or deleted. Records
+that do not meet the constraints are filtered.
+
+For example, you can create a rule to limit a group in such a way that
+users of that group will see business opportunities in which he or she is
+flagged as the salesman. The rule can be salesman = connected_user. With
+that rule, only records respecting the rule will be displayed.
+
+Record field rules
+++++++++++++++++++
+
+Every field of an OpenERP object can be access-controlled. Record field is
+a right to see or write a particular field on an object. For example, you
+can limit the right to have access to the margin of a sale order to the
+sales managers group only.
+
+Workflow transition rules
++++++++++++++++++++++++++
+
+Workflow transition rules are rules that restrict some operations to certain
+groups. Those rules handle rights to go from one step to another one in the
+workflow. For example, you can limit the right to validate an invoice, i.e.
+going from a draft action to a validated action.
+
+Menu accesses
+=============
+
+In OpenERP, granting access to menus can be done using user groups. A menu
+that is not granted to any group is accessible to every user. It is possible
+in the administration panel to define the groups that can access a given menu.
+
+However, one should note that using groups to hide or give access to menus
+is more within the filed of ergonomics or usability than within the field
+of security. It is a best practice putting rules on documents instead of
+putting groups on menu. For example, hiding invoices can be done by modifying
+the record rule on the invoice object, and it is more efficient and safer
+than hiding menus related to invoices.
+
+Views customization
+===================
+
+Customizing views based on groups is possible in OpenERP. You can put rules
+to display some fields based on group rules. However, as with menu accesses
+customization, this option should not be considered for security concerns.
+This way of customizing views belongs more to usability.
+
+Administration
+==============
+
+When installing your particular instance of OpenERP, a specific first user
+is installed by default. This first user is the Super User or administrator.
+The administrator is by default added access rights to every existing groups,
+as well as to every groups created during a new module installation. He also
+has access to a specific administration interface accessible via the administration
+menu, allowing the administration of OpenERP.
+
+The administrator has rights to manage groups; he can add, create, modify
+or remove groups. He may also modify links between users and groups, such
+as adding or removing users. He also manages access rights. With those
+privileges, the administrator can therefore precisely define security
+accesses of every users of OpenERP.
+
+There are user groups that are between normal groups and the super user.
+Those groups are Administration / Configuration and Administration / Access Rights.
+It gives to the users of those groups the necessary rights to configure access rights.
+++ /dev/null
-=================================================
-Security in OpenERP: users, groups and user roles
-=================================================
-
-Users and user roles are critical points concerning internal security in
-OpenERP. OpenERP provides several security mechanisms concerning user roles,
-all implemented in the OpenERP Server. They are implemented in the lowest
-server level, which is the ORM engine. OpenERP distinguishes three different
-concepts:
-
- - user: a person identified by its login and password. Note that all employees
- of a company are not necessarily OpenERP users; an user is somebody who
- accesses the application.
- - group: a group of users that has some access rights. A group gives its
- access rights to the users that belong to the group. Ex: Sales Manager,
- Accountant, etc.
- - security rule: a rule that defines the access rights a given group grants
- to its users. Security rules are attached to a given resource, for example
- the Invoice model.
-
-Security rules are attached to groups. Users are assigned to several groups.
-This gives users the rights that are attached to their groups. Therefore
-controlling user roles is done by managing user groups and adding or modifying
-security rules attached to those groups.
-
-Users
-======
-
-Users represent physical persons using OpenERP. They are identified with
-a login and a password,they use OpenERP, they can edit their own preferences, ...
-By default, a user has no access right. The more we assign groups to the user,
-the more he or she gets rights to perform some actions. A user may belong
-to several groups.
-
-User groups
-===========
-
-The groups determine the access rights to the different resources. A user
-may belong to several groups. If he belongs to several groups, we always
-use the group with the highest rights for a selected resource. A group
-can inherit all the rights from another group
-
-Figure 3 shows how group membership is displayed in the web client. The user
-belongs to Sales / Manager, Accounting / Manager, Administration / Access Rights,
-Administration / Configuration and Human Resources / Employee groups. Those
-groups define the user access rights.
-
-Figure 3: Example of group membership for a given user
-
-
-Record rules
-============
-
-Security rules are attached to groups. You can assign several security
-rules at the group level, each rule being of one of the following types :
-
- - access rights are global rights on an object,
- - record rules are records access filters,
- - record field rules are fields access filters,
- - workflow transition rules are operations rights.
-
-You can also define rules that are global, i.e. they are applied to all
-users, indiscriminately of the groups they belong to. For example, the
-multi-company rules are global; a user can only see invoices of the companies
-he or she belongs to.
-
-
-Concerning configuration, it is difficult to have default generic configurations
-that suit all applications. Therefore, like SAP, OpenERP is by default
-pre-configured with best-practices.
-
-Access rights
-+++++++++++++
-
-Access rights are rules that define the access a user can have on a particular
-object . Those global rights are defined per document type or model. Rights
-follow the CRUD model: create, read (search), update (write), delete. For
-example, you can define rules on invoice creation. By default, adding a
-right to an object gives the right to all records of that specific object.
-
-Figure 4 shows some of the access rights of the Accounting / Accountant group.
-The user has some read access rights on some objects.
-
-Figure 4: Access rights for some objects.
-
-Record rules
-++++++++++++
-
-When accessing an object, records are filtered based on record rules. Record
-rules or access filters are therefore filters that limits records of an
-object a group can access. A record rule is a condition that each record
-must satisfy to be created, read, updated (written) or deleted. Records
-that do not meet the constraints are filtered.
-
-For example, you can create a rule to limit a group in such a way that
-users of that group will see business opportunities in which he or she is
-flagged as the salesman. The rule can be salesman = connected_user. With
-that rule, only records respecting the rule will be displayed.
-
-Record field rules
-++++++++++++++++++
-
-Every field of an OpenERP object can be access-controlled. Record field is
-a right to see or write a particular field on an object. For example, you
-can limit the right to have access to the margin of a sale order to the
-sales managers group only.
-
-Workflow transition rules
-+++++++++++++++++++++++++
-
-Workflow transition rules are rules that restrict some operations to certain
-groups. Those rules handle rights to go from one step to another one in the
-workflow. For example, you can limit the right to validate an invoice, i.e.
-going from a draft action to a validated action.
-
-Menu accesses
-=============
-
-In OpenERP, granting access to menus can be done using user groups. A menu
-that is not granted to any group is accessible to every user. It is possible
-in the administration panel to define the groups that can access a given menu.
-
-However, one should note that using groups to hide or give access to menus
-is more within the filed of ergonomics or usability than within the field
-of security. It is a best practice putting rules on documents instead of
-putting groups on menu. For example, hiding invoices can be done by modifying
-the record rule on the invoice object, and it is more efficient and safer
-than hiding menus related to invoices.
-
-Views customization
-===================
-
-Customizing views based on groups is possible in OpenERP. You can put rules
-to display some fields based on group rules. However, as with menu accesses
-customization, this option should not be considered for security concerns.
-This way of customizing views belongs more to usability.
-
-Administration
-==============
-
-When installing your particular instance of OpenERP, a specific first user
-is installed by default. This first user is the Super User or administrator.
-The administrator is by default added access rights to every existing groups,
-as well as to every groups created during a new module installation. He also
-has access to a specific administration interface accessible via the administration
-menu, allowing the administration of OpenERP.
-
-The administrator has rights to manage groups; he can add, create, modify
-or remove groups. He may also modify links between users and groups, such
-as adding or removing users. He also manages access rights. With those
-privileges, the administrator can therefore precisely define security
-accesses of every users of OpenERP.
-
-There are user groups that are between normal groups and the super user.
-Those groups are Administration / Configuration and Administration / Access Rights.
-It gives to the users of those groups the necessary rights to configure access rights.
--- /dev/null
+.. _test-framework:
+
+Test framework
+==============
+
+In addition to the YAML-based tests, OpenERP uses the unittest2_ testing
+framework to test both the core ``openerp`` package and its addons. For the
+core and each addons, tests are divided between three (overlapping) sets:
+
+1. A test suite that comprises all the tests that can be run right after the
+ addons is installed (or, for the core, right after a database is created).
+ That suite is called ``fast_suite`` and must contain only tests that can be run
+ frequently. Actually most of the tests should be considered fast enough to be
+ included in that ``fast_suite`` list and only tests that take a long time to run
+ (e.g. more than a minute) should not be listed. Those long tests should come up
+ pretty rarely.
+
+2. A test suite called ``checks`` provides sanity checks. These tests are
+ invariants that must be full-filled at any time. They are expected to always
+ pass: obviously they must pass right after the module is installed (i.e. just
+ like the ``fast_suite`` tests), but they must also pass after any other module is
+ installed, after a migration, or even after the database was put in production
+ for a few months.
+
+3. The third suite is made of all the tests: those provided by the two above
+ suites, but also tests that are not explicitely listed in ``fast_suite`` or
+ ``checks``. They are not explicitely listed anywhere and are discovered
+ automatically.
+
+As the sanity checks provide stronger guarantees about the code and database
+structure, new tests must be added to the ``checks`` suite whenever it is
+possible. Said with other words: one should try to avoid writing tests that
+assume a freshly installed/unaltered module or database.
+
+It is possible to have tests that are not listed in ``fast_suite`` or
+``checks``. This is useful if a test takes a lot of time. By default, when
+using the testing infrastructure, tests should run fast enough so that people
+can use them frequently. One can also use that possiblity for tests that
+require some complex setup before they can be successfuly run.
+
+As a rule of thumb when writing a new test, try to add it to the ``checks``
+suite. If it really needs that the module it belongs to is freshly installed,
+add it to ``fast_suite``. Finally, if it can not be run in an acceptable time
+frame, don't add it to any explicit list.
+
+Writing tests
+-------------
+
+The tests must be developed under ``<addons-name>.tests`` (or ``openerp.tests``
+for the core). For instance, with respect to the tests, a module ``foo``
+should be organized as follow::
+
+ foo/
+ __init__.py # does not import .tests
+ tests/
+ __init__.py # import some of the tests sub-modules, and
+ # list them in fast_suite or checks
+ test_bar.py # contains unittest2 classes
+ test_baz.py # idem
+ ... and so on ...
+
+The two explicit lists of tests are thus the variables ``foo.tests.fast_suite``
+and ``foo.tests.checks``. As an example, you can take a look at the
+``openerp.tests`` module (which follows exactly the same conventions even if it
+is not an addons).
+
+Note that the ``fast_suite`` and ``checks`` variables are really lists of
+module objects. They could be directly unittest2 suite objects if necessary in
+the future.
+
+Running the tests
+-----------------
+
+To run the tests (see :ref:`above <test-framework>` to learn how tests are
+organized), the simplest way is to use the ``oe`` command (provided by the
+``openerp-command`` project).
+
+::
+
+ > oe run-tests # will run all the fast_suite tests
+ > oe run-tests -m openerp # will run all the fast_suite tests defined in `openerp.tests`
+ > oe run-tests -m sale # will run all the fast_suite tests defined in `openerp.addons.sale.tests`
+ > oe run-tests -m foo.test_bar # will run the tests defined in `openerp.addons.foo.tests.test_bar`
+
+In addition to the above possibilities, when invoked with a non-existing module
+(or module.sub-module) name, oe will reply with a list of available test
+sub-modules.
+
+Depending on the unittest2_ class that is used to write the tests (see
+: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
+with the initialization of a new database: the dabase is created, and after
+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.
+++ /dev/null
-.. _test-framework:
-
-Test framework
-==============
-
-In addition to the YAML-based tests, OpenERP uses the unittest2_ testing
-framework to test both the core ``openerp`` package and its addons. For the
-core and each addons, tests are divided between three (overlapping) sets:
-
-1. A test suite that comprises all the tests that can be run right after the
- addons is installed (or, for the core, right after a database is created).
- That suite is called ``fast_suite`` and must contain only tests that can be run
- frequently. Actually most of the tests should be considered fast enough to be
- included in that ``fast_suite`` list and only tests that take a long time to run
- (e.g. more than a minute) should not be listed. Those long tests should come up
- pretty rarely.
-
-2. A test suite called ``checks`` provides sanity checks. These tests are
- invariants that must be full-filled at any time. They are expected to always
- pass: obviously they must pass right after the module is installed (i.e. just
- like the ``fast_suite`` tests), but they must also pass after any other module is
- installed, after a migration, or even after the database was put in production
- for a few months.
-
-3. The third suite is made of all the tests: those provided by the two above
- suites, but also tests that are not explicitely listed in ``fast_suite`` or
- ``checks``. They are not explicitely listed anywhere and are discovered
- automatically.
-
-As the sanity checks provide stronger guarantees about the code and database
-structure, new tests must be added to the ``checks`` suite whenever it is
-possible. Said with other words: one should try to avoid writing tests that
-assume a freshly installed/unaltered module or database.
-
-It is possible to have tests that are not listed in ``fast_suite`` or
-``checks``. This is useful if a test takes a lot of time. By default, when
-using the testing infrastructure, tests should run fast enough so that people
-can use them frequently. One can also use that possiblity for tests that
-require some complex setup before they can be successfuly run.
-
-As a rule of thumb when writing a new test, try to add it to the ``checks``
-suite. If it really needs that the module it belongs to is freshly installed,
-add it to ``fast_suite``. Finally, if it can not be run in an acceptable time
-frame, don't add it to any explicit list.
-
-Writing tests
--------------
-
-The tests must be developed under ``<addons-name>.tests`` (or ``openerp.tests``
-for the core). For instance, with respect to the tests, a module ``foo``
-should be organized as follow::
-
- foo/
- __init__.py # does not import .tests
- tests/
- __init__.py # import some of the tests sub-modules, and
- # list them in fast_suite or checks
- test_bar.py # contains unittest2 classes
- test_baz.py # idem
- ... and so on ...
-
-The two explicit lists of tests are thus the variables ``foo.tests.fast_suite``
-and ``foo.tests.checks``. As an example, you can take a look at the
-``openerp.tests`` module (which follows exactly the same conventions even if it
-is not an addons).
-
-Note that the ``fast_suite`` and ``checks`` variables are really lists of
-module objects. They could be directly unittest2 suite objects if necessary in
-the future.
-
-Running the tests
------------------
-
-To run the tests (see :ref:`above <test-framework>` to learn how tests are
-organized), the simplest way is to use the ``oe`` command (provided by the
-``openerp-command`` project).
-
-::
-
- > oe run-tests # will run all the fast_suite tests
- > oe run-tests -m openerp # will run all the fast_suite tests defined in `openerp.tests`
- > oe run-tests -m sale # will run all the fast_suite tests defined in `openerp.addons.sale.tests`
- > oe run-tests -m foo.test_bar # will run the tests defined in `openerp.addons.foo.tests.test_bar`
-
-In addition to the above possibilities, when invoked with a non-existing module
-(or module.sub-module) name, oe will reply with a list of available test
-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.
-
-Because creating a database, installing modules, and then dropping it is
-expensive, it is possible to interleave the run of the ``fast_suite`` tests
-with the initialization of a new database: the dabase is created, and after
-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
+++ /dev/null
-
-.. _openerp library:
-
-Server-side library
--------------------
-
-.. automodule:: openerp
- :members:
- :undoc-members:
-
+++ /dev/null
-Field-level access control
-==========================
-
-.. versionadded:: 7.0
-
-OpenERP now supports real access control at the field level, not just on the view side.
-Previously it was already possible to set a ``groups`` attribute on a ``<field>`` element
-(or in fact most view elements), but with cosmetics effects only: the element was made
-invisible on the client side, while still perfectly available for read/write access at
-the RPC level.
-
-As of OpenERP 7.0 the existing behavior is preserved on the view level, but a new ``groups``
-attribute is available on all model fields, introducing a model-level access control on
-each field. The syntax is the same as for the view-level attribute::
-
- _columns = {
- 'secret_key': fields.char('Secret Key', groups="base.group_erp_manager,base.group_system")
- }
-
-There is a major difference with the view-level ``groups`` attribute: restricting
-the access at the model level really means that the field will be completely unavailable
-for users who do not belong to the authorized groups:
-
-* Restricted fields will be **completely removed** from all related views, not just
- hidden. This is important to keep in mind because it means the field value will not be
- available at all on the client side, and thus unavailable e.g. for ``on_change`` calls.
-* Restricted fields will not be returned as part of a call to
- :meth:`~openerp.osv.orm.fields_get` or :meth:`~openerp.osv.orm.fields_view_get`
- This is in order to avoid them appearing in the list of fields available for
- advanced search filters, for example. This does not prevent getting the list of
- a model's fields by querying ``ir.model.fields`` directly, which is fine.
-* Any attempt to read or write directly the value of the restricted fields will result
- in an ``AccessError`` exception.
-* As a consequence of the previous item, restricted fields will not be available for
- use within search filters (domains) or anything that would require read or write access.
-* It is quite possible to set ``groups`` attributes for the same field both at the model
- and view level, even with different values. Both will carry their effect, with the
- model-level restriction taking precedence and removing the field completely in case of
- restriction.
-
-.. note:: The tests related to this feature are in ``openerp/tests/test_acl.py``.
-
-.. warning:: At the time of writing the implementation of this feature is partial
- and does not yet restrict read/write RPC access to the field.
- The corresponding test is written already but currently disabled.
\ No newline at end of file
+++ /dev/null
-
-ORM and models
---------------
-
-.. automodule:: openerp.osv.orm
- :members:
- :undoc-members:
+++ /dev/null
-
-Start-up script
----------------
-
-.. versionadded:: 6.1
-
-To run the OpenERP server, the conventional approach is to use the
-`openerp-server` script. It loads the :ref:`openerp library`, sets a few
-configuration variables corresponding to command-line arguments, and starts to
-listen to incoming connections from clients.
-
-Depending on your deployment needs, you can write such a start-up script very
-easily. We also recommend you take a look at an alternative tool called
-`openerp-command` that can, among other things, launch the server.
-
-Yet another alternative is to use a WSGI-compatible HTTP server and let it call
-into one of the WSGI entry points of the server.
-
--- /dev/null
+
+.. _openerp library:
+
+Server-side library
+-------------------
+
+.. automodule:: openerp
+ :members:
+ :undoc-members:
+
--- /dev/null
+
+ORM and models
+--------------
+
+.. automodule:: openerp.osv.orm
+ :members:
+ :undoc-members:
--- /dev/null
+Field-level access control
+==========================
+
+.. versionadded:: 7.0
+
+OpenERP now supports real access control at the field level, not just on the view side.
+Previously it was already possible to set a ``groups`` attribute on a ``<field>`` element
+(or in fact most view elements), but with cosmetics effects only: the element was made
+invisible on the client side, while still perfectly available for read/write access at
+the RPC level.
+
+As of OpenERP 7.0 the existing behavior is preserved on the view level, but a new ``groups``
+attribute is available on all model fields, introducing a model-level access control on
+each field. The syntax is the same as for the view-level attribute::
+
+ _columns = {
+ 'secret_key': fields.char('Secret Key', groups="base.group_erp_manager,base.group_system")
+ }
+
+There is a major difference with the view-level ``groups`` attribute: restricting
+the access at the model level really means that the field will be completely unavailable
+for users who do not belong to the authorized groups:
+
+* Restricted fields will be **completely removed** from all related views, not just
+ hidden. This is important to keep in mind because it means the field value will not be
+ available at all on the client side, and thus unavailable e.g. for ``on_change`` calls.
+* Restricted fields will not be returned as part of a call to
+ :meth:`~openerp.osv.orm.fields_get` or :meth:`~openerp.osv.orm.fields_view_get`
+ This is in order to avoid them appearing in the list of fields available for
+ advanced search filters, for example. This does not prevent getting the list of
+ a model's fields by querying ``ir.model.fields`` directly, which is fine.
+* Any attempt to read or write directly the value of the restricted fields will result
+ in an ``AccessError`` exception.
+* As a consequence of the previous item, restricted fields will not be available for
+ use within search filters (domains) or anything that would require read or write access.
+* It is quite possible to set ``groups`` attributes for the same field both at the model
+ and view level, even with different values. Both will carry their effect, with the
+ model-level restriction taking precedence and removing the field completely in case of
+ restriction.
+
+.. note:: The tests related to this feature are in ``openerp/tests/test_acl.py``.
+
+.. warning:: At the time of writing the implementation of this feature is partial
+ and does not yet restrict read/write RPC access to the field.
+ The corresponding test is written already but currently disabled.
\ No newline at end of file
--- /dev/null
+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>
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``
--- /dev/null
++-------+-------+===========+===========+-------+-------+
+|value01|value02‖o2m/value01|o2m/value02‖value03|value04|
++-------+-------+-----------+-----------+-------+-------+
+| | ‖o2m/value11|o2m/value12‖ | |
++-------+-------+-----------+-----------+-------+-------+
+| | ‖o2m/value21|o2m/value22‖ | |
++-------+-------+===========+===========+-------+-------+
+|value11|value12‖o2m/value01|o2m/value02‖value13|value14|
++-------+-------+-----------+-----------+-------+-------+
+| | ‖o2m/value11|o2m/value12‖ | |
++-------+-------+===========+===========+-------+-------+
+|value21|value22| | |value23|value24|
++-------+-------+-----------+-----------+-------+-------+
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
+
+
+
+++ /dev/null
-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
--- /dev/null
+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>
--- /dev/null
+Need action mechanism
+=====================
+
+.. versionadded:: 7.0
+
+ir.needaction_mixin class
++++++++++++++++++++++++++
+
+.. versionadded:: openobject-server.4124
+
+This revision adds a mixin class for objects using the need action feature.
+
+Need action feature can be used by objects willing to be able to signal that an action is required on a particular record. If in the business logic an action must be performed by somebody, for instance validation by a manager, this mechanism allows to set a list of users asked to perform an action.
+
+This class wraps a class (ir.ir_needaction_users_rel) that behaves like a many2many field. However, no field is added to the model inheriting from ir.needaction_mixin. The mixin class manages the low-level considerations of updating relationships. Every change made on the record calls a method that updates the relationships.
+
+Objects using the need_action feature should override the ``get_needaction_user_ids`` method. This methods returns a dictionary whose keys are record ids, and values a list of user ids, like in a many2many relationship. Therefore by defining only one method, you can specify if an action is required by defining the users that have to do it, in every possible situation.
+
+This class also offers several global services,:
+ - ``needaction_get_record_ids``: for the current model and uid, get all record ids that ask this user to perform an action. This mechanism is used for instance to display the number of pending actions in menus, such as Leads (12)
+ - ``needaction_get_action_count``: as ``needaction_get_record_ids`` but returns only the number of action, not the ids (performs a search with count=True)
+ - ``needaction_get_user_record_references``: for a given uid, get all the records that ask this user to perform an action. Records are given as references, a list of tuples (model_name, record_id).
+
+.. versionadded:: openobject-server.4137
+
+This revision of the needaction_mixin mechanism slighty modifies the class behavior. The ``ir_needaction_mixin`` class now adds a function field on models inheriting from the class. This field allows to state whether a given record has a needaction for the current user. This is usefull if you want to customize views according to the needaction feature. For example, you may want to set records in bold in a list view if the current user has an action to perform on the record. This makes the class not a pure abstract class, but allows to easily use the action information. The field definition is::
+
+
+ def get_needaction_pending(self, cr, uid, ids, name, arg, context=None):
+ res = {}
+ needaction_user_ids = self.get_needaction_user_ids(cr, uid, ids, context=context)
+ for id in ids:
+ res[id] = uid in needaction_user_ids[id]
+ return res
+
+ _columns = {
+ 'needaction_pending': fields.function(get_needaction_pending, type='boolean',
+ string='Need action pending',
+ help='If True, this field states that users have to perform an action. \
+ This field comes from the needaction mechanism. Please refer \
+ to the ir.needaction_mixin class.'),
+ }
+
+ir.needaction_users_rel class
++++++++++++++++++++++++++++++
+
+.. versionadded:: openobject-server.4124
+
+This class essentially wraps a database table that behaves like a many2many.
+It holds data related to the needaction mechanism inside OpenERP. A row
+in this model is characterized by:
+
+ - ``res_model``: model of the record requiring an action
+ - ``res_id``: ID of the record requiring an action
+ - ``user_id``: foreign key to the res.users table, to the user that
+ has to perform the action
+
+This model can be seen as a many2many, linking (res_model, res_id) to
+users (those whose attention is required on the record)
+
+Menu modification
++++++++++++++++++
+
+.. versionchanged:: openobject-server.4137
+
+This revision adds three functional fields to ``ir.ui.menu`` model :
+ - ``uses_needaction``: boolean field. If the menu entry action is an act_window action, and if this action is related to a model that uses the need_action mechanism, this field is set to true. Otherwise, it is false.
+ - ``needaction_uid_ctr``: integer field. If the target model uses the need action mechanism, this field gives the number of actions the current user has to perform.
+ - **REMOVED** ``needaction_record_ids``: many2many field. If the target model uses the need action mechanism, this field holds the ids of the record requesting the user to perform an action. **This field has been removed on version XXXX**.
+
+Those fields are functional, because they depend on the user and must therefore be computed at every refresh, each time menus are displayed. The use of the need action mechanism is done by taking into account the action domain in order to display accurate results. When computing the value of the functional fields, the ids of records asking the user to perform an action is concatenated to the action domain. A counting search is then performed on the model, giving back the number of action the users has to perform, limited to the domain of the action.
+
+Addon implementation example
+++++++++++++++++++++++++++++
+
+In your ``foo`` module, you want to specify that when it is in state ``confirmed``, it has to be validated by a manager, given by the field ``manager_id``. After making ``foo`` inheriting from ``ir.needaction_mixin``, you override the ``get_needaction_user_ids`` method:
+
+::
+
+ [...]
+ _inherit = [`ir.needaction_mixin]
+ [...]
+ def get_needaction_user_ids(self, cr, uid, ids, context=None):
+ result = dict.fromkeys(ids)
+ for foo_obj in self.browse(cr, uid, ids, context=context):
+ # set the list void by default
+ result[foo_obj.id] = []
+ # if foo_obj is confirmed: manager is required to perform an action
+ if foo_obj.state == 'confirmed':
+ result[foo_obj.id] = [foo_obj.manager_id]
+ return result
+++ /dev/null
-+-------+-------+===========+===========+-------+-------+
-|value01|value02‖o2m/value01|o2m/value02‖value03|value04|
-+-------+-------+-----------+-----------+-------+-------+
-| | ‖o2m/value11|o2m/value12‖ | |
-+-------+-------+-----------+-----------+-------+-------+
-| | ‖o2m/value21|o2m/value22‖ | |
-+-------+-------+===========+===========+-------+-------+
-|value11|value12‖o2m/value01|o2m/value02‖value13|value14|
-+-------+-------+-----------+-----------+-------+-------+
-| | ‖o2m/value11|o2m/value12‖ | |
-+-------+-------+===========+===========+-------+-------+
-|value21|value22| | |value23|value24|
-+-------+-------+-----------+-----------+-------+-------+
+++ /dev/null
-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>
+++ /dev/null
-Need action mechanism
-=====================
-
-.. versionadded:: 7.0
-
-ir.needaction_mixin class
-+++++++++++++++++++++++++
-
-.. versionadded:: openobject-server.4124
-
-This revision adds a mixin class for objects using the need action feature.
-
-Need action feature can be used by objects willing to be able to signal that an action is required on a particular record. If in the business logic an action must be performed by somebody, for instance validation by a manager, this mechanism allows to set a list of users asked to perform an action.
-
-This class wraps a class (ir.ir_needaction_users_rel) that behaves like a many2many field. However, no field is added to the model inheriting from ir.needaction_mixin. The mixin class manages the low-level considerations of updating relationships. Every change made on the record calls a method that updates the relationships.
-
-Objects using the need_action feature should override the ``get_needaction_user_ids`` method. This methods returns a dictionary whose keys are record ids, and values a list of user ids, like in a many2many relationship. Therefore by defining only one method, you can specify if an action is required by defining the users that have to do it, in every possible situation.
-
-This class also offers several global services,:
- - ``needaction_get_record_ids``: for the current model and uid, get all record ids that ask this user to perform an action. This mechanism is used for instance to display the number of pending actions in menus, such as Leads (12)
- - ``needaction_get_action_count``: as ``needaction_get_record_ids`` but returns only the number of action, not the ids (performs a search with count=True)
- - ``needaction_get_user_record_references``: for a given uid, get all the records that ask this user to perform an action. Records are given as references, a list of tuples (model_name, record_id).
-
-.. versionadded:: openobject-server.4137
-
-This revision of the needaction_mixin mechanism slighty modifies the class behavior. The ``ir_needaction_mixin`` class now adds a function field on models inheriting from the class. This field allows to state whether a given record has a needaction for the current user. This is usefull if you want to customize views according to the needaction feature. For example, you may want to set records in bold in a list view if the current user has an action to perform on the record. This makes the class not a pure abstract class, but allows to easily use the action information. The field definition is::
-
-
- def get_needaction_pending(self, cr, uid, ids, name, arg, context=None):
- res = {}
- needaction_user_ids = self.get_needaction_user_ids(cr, uid, ids, context=context)
- for id in ids:
- res[id] = uid in needaction_user_ids[id]
- return res
-
- _columns = {
- 'needaction_pending': fields.function(get_needaction_pending, type='boolean',
- string='Need action pending',
- help='If True, this field states that users have to perform an action. \
- This field comes from the needaction mechanism. Please refer \
- to the ir.needaction_mixin class.'),
- }
-
-ir.needaction_users_rel class
-+++++++++++++++++++++++++++++
-
-.. versionadded:: openobject-server.4124
-
-This class essentially wraps a database table that behaves like a many2many.
-It holds data related to the needaction mechanism inside OpenERP. A row
-in this model is characterized by:
-
- - ``res_model``: model of the record requiring an action
- - ``res_id``: ID of the record requiring an action
- - ``user_id``: foreign key to the res.users table, to the user that
- has to perform the action
-
-This model can be seen as a many2many, linking (res_model, res_id) to
-users (those whose attention is required on the record)
-
-Menu modification
-+++++++++++++++++
-
-.. versionchanged:: openobject-server.4137
-
-This revision adds three functional fields to ``ir.ui.menu`` model :
- - ``uses_needaction``: boolean field. If the menu entry action is an act_window action, and if this action is related to a model that uses the need_action mechanism, this field is set to true. Otherwise, it is false.
- - ``needaction_uid_ctr``: integer field. If the target model uses the need action mechanism, this field gives the number of actions the current user has to perform.
- - **REMOVED** ``needaction_record_ids``: many2many field. If the target model uses the need action mechanism, this field holds the ids of the record requesting the user to perform an action. **This field has been removed on version XXXX**.
-
-Those fields are functional, because they depend on the user and must therefore be computed at every refresh, each time menus are displayed. The use of the need action mechanism is done by taking into account the action domain in order to display accurate results. When computing the value of the functional fields, the ids of records asking the user to perform an action is concatenated to the action domain. A counting search is then performed on the model, giving back the number of action the users has to perform, limited to the domain of the action.
-
-Addon implementation example
-++++++++++++++++++++++++++++
-
-In your ``foo`` module, you want to specify that when it is in state ``confirmed``, it has to be validated by a manager, given by the field ``manager_id``. After making ``foo`` inheriting from ``ir.needaction_mixin``, you override the ``get_needaction_user_ids`` method:
-
-::
-
- [...]
- _inherit = [`ir.needaction_mixin]
- [...]
- def get_needaction_user_ids(self, cr, uid, ids, context=None):
- result = dict.fromkeys(ids)
- for foo_obj in self.browse(cr, uid, ids, context=context):
- # set the list void by default
- result[foo_obj.id] = []
- # if foo_obj is confirmed: manager is required to perform an action
- if foo_obj.state == 'confirmed':
- result[foo_obj.id] = [foo_obj.manager_id]
- return result
+++ /dev/null
-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.
--- /dev/null
+
+Start-up script
+---------------
+
+.. versionadded:: 6.1
+
+To run the OpenERP server, the conventional approach is to use the
+`openerp-server` script. It loads the :ref:`openerp library`, sets a few
+configuration variables corresponding to command-line arguments, and starts to
+listen to incoming connections from clients.
+
+Depending on your deployment needs, you can write such a start-up script very
+easily. We also recommend you take a look at an alternative tool called
+`openerp-command` that can, among other things, launch the server.
+
+Yet another alternative is to use a WSGI-compatible HTTP server and let it call
+into one of the WSGI entry points of the server.
+
--- /dev/null
+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.
projects / odoo / odoo.git / commitdiff