rearrange toc, remove some deprecated stuff
bzr revid: al@openerp.com-20121111023903-yus5wxlw06ods46f
This commit is contained in:
parent
4820450aef
commit
d9554b698a
|
@ -155,7 +155,23 @@ You can specify alternate configuration files with ::
|
||||||
|
|
||||||
-c CONFIG, --config=CONFIG specify alternate config file
|
-c CONFIG, --config=CONFIG specify alternate config file
|
||||||
|
|
||||||
An example of server configuration file for
|
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.
|
||||||
|
|
||||||
|
|
||||||
Appendix
|
Appendix
|
||||||
========
|
========
|
||||||
|
|
|
@ -10,3 +10,4 @@ Modules
|
||||||
03_module_dev_03
|
03_module_dev_03
|
||||||
03_module_dev_04
|
03_module_dev_04
|
||||||
03_module_dev_05
|
03_module_dev_05
|
||||||
|
03_module_dev_06
|
||||||
|
|
|
@ -416,43 +416,6 @@ OpenERP uses a flexible and powerful reporting system. Reports are generated eit
|
||||||
|
|
||||||
Reports are described more in details in the `Reporting <http://openobject.com/wiki/index.php/Developers:Developper%27s_Book/Reports>`_ chapter.
|
Reports are described more in details in the `Reporting <http://openobject.com/wiki/index.php/Developers:Developper%27s_Book/Reports>`_ chapter.
|
||||||
|
|
||||||
Wizards
|
|
||||||
"""""""
|
|
||||||
|
|
||||||
Here's an example of a .XML file that declares a wizard.
|
|
||||||
|
|
||||||
.. code-block:: xml
|
|
||||||
|
|
||||||
<?xml version="1.0"?>
|
|
||||||
<openerp>
|
|
||||||
<data>
|
|
||||||
<wizard string="Employee Info"
|
|
||||||
model="hr.employee"
|
|
||||||
name="employee.info.wizard"
|
|
||||||
id="wizard_employee_info"/>
|
|
||||||
</data>
|
|
||||||
</openerp>
|
|
||||||
|
|
||||||
A wizard is declared using a wizard tag. See "Add A New Wizard" for more information about wizard XML.
|
|
||||||
|
|
||||||
also you can add wizard in menu using following xml entry
|
|
||||||
|
|
||||||
.. code-block:: xml
|
|
||||||
|
|
||||||
<?xml version="1.0"?>
|
|
||||||
</openerp>
|
|
||||||
<data>
|
|
||||||
<wizard string="Employee Info"
|
|
||||||
model="hr.employee"
|
|
||||||
name="employee.info.wizard"
|
|
||||||
id="wizard_employee_info"/>
|
|
||||||
<menuitem
|
|
||||||
name="Human Resource/Employee Info"
|
|
||||||
action="wizard_employee_info"
|
|
||||||
type="wizard"
|
|
||||||
id="menu_wizard_employee_info"/>
|
|
||||||
</data>
|
|
||||||
</openerp>
|
|
||||||
|
|
||||||
Workflow
|
Workflow
|
||||||
""""""""
|
""""""""
|
||||||
|
@ -491,63 +454,6 @@ The squared nodes represent other Workflows;
|
||||||
* the shipping
|
* the shipping
|
||||||
|
|
||||||
|
|
||||||
Profile Module
|
|
||||||
++++++++++++++
|
|
||||||
|
|
||||||
The purpose of a profile is to initialize OpenERP with a set of modules directly after the database has been created. A profile is a special kind of module that contains no code, only *dependencies on other modules*.
|
|
||||||
|
|
||||||
In order to create a profile, you only have to create a new directory in server/addons (you *should* call this folder profile_modulename), in which you put an *empty* __init__.py file (as every directory Python imports must contain an __init__.py file), and a __openerp__.py whose structure is as follows :
|
|
||||||
|
|
||||||
.. code-block:: python
|
|
||||||
|
|
||||||
{
|
|
||||||
"name":"''Name of the Profile'',
|
|
||||||
"version":"''Version String''",
|
|
||||||
"author":"''Author Name''",
|
|
||||||
"category":"Profile",
|
|
||||||
"depends":[''List of the modules to install with the profile''],
|
|
||||||
"demo_xml":[],
|
|
||||||
"update_xml":[],
|
|
||||||
"active":False,
|
|
||||||
"installable":True,
|
|
||||||
}
|
|
||||||
|
|
||||||
Here's the code of the file source/addons/profile_tools/__openerp__.py,
|
|
||||||
which corresponds to the tools profile in OpenERP.
|
|
||||||
|
|
||||||
.. code-block:: python
|
|
||||||
|
|
||||||
{
|
|
||||||
"name" : "Miscellaneous Tools",
|
|
||||||
"version" : "1.0",
|
|
||||||
"depends" : ["base", "base_setup"],
|
|
||||||
"author" : "OpenERP SA",
|
|
||||||
"category" : "Hidden/Dependency",
|
|
||||||
'complexity': "easy",
|
|
||||||
"description": """
|
|
||||||
Installer for extra Hidden like lunch, survey, idea, share, etc.
|
|
||||||
================================================================
|
|
||||||
|
|
||||||
Makes the Extra Hidden Configuration available from where you can install
|
|
||||||
modules like share, lunch, pad, idea, survey and subscription.
|
|
||||||
""",
|
|
||||||
'website': 'http://www.openerp.com',
|
|
||||||
'init_xml': [],
|
|
||||||
'update_xml': [
|
|
||||||
],
|
|
||||||
'demo_xml': [],
|
|
||||||
'installable': True,
|
|
||||||
'auto_install': False,
|
|
||||||
'certificate' : '00557100228403879621',
|
|
||||||
'images': ['images/config_extra_Hidden.jpeg'],
|
|
||||||
}
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Appendix
|
Appendix
|
||||||
+++++++++
|
+++++++++
|
||||||
|
|
|
@ -27,8 +27,6 @@ along with icons and other fields.
|
||||||
name="My Menu"
|
name="My Menu"
|
||||||
action="action_xml_id"
|
action="action_xml_id"
|
||||||
icon="NAME_FROM_LIST"
|
icon="NAME_FROM_LIST"
|
||||||
web_icon="static/src/img/icon.png"
|
|
||||||
web_icon_hover="static/src/img/icon-hover.png"
|
|
||||||
groups="groupname"
|
groups="groupname"
|
||||||
sequence="<integer>"
|
sequence="<integer>"
|
||||||
parent="parent_menu_xml_id"
|
parent="parent_menu_xml_id"
|
||||||
|
@ -46,11 +44,6 @@ Where
|
||||||
to them. This is useful when defining custom icons for menu elements
|
to them. This is useful when defining custom icons for menu elements
|
||||||
that will act as folders. This is how custom icons for "Projects" or
|
that will act as folders. This is how custom icons for "Projects" or
|
||||||
"Human Resources" in OpenERP are defined).
|
"Human Resources" in OpenERP are defined).
|
||||||
- ``icon`` specifies which icon will be displayed for the menu item
|
|
||||||
using the menu item. The default icon is STOCK_OPEN.
|
|
||||||
|
|
||||||
- The available icons are : STOCK_ABOUT, STOCK_ADD, STOCK_APPLY, STOCK_BOLD, STOCK_CANCEL, STOCK_CDROM, STOCK_CLEAR, STOCK_CLOSE, STOCK_COLOR_PICKER, STOCK_CONNECT, STOCK_CONVERT, STOCK_COPY, STOCK_CUT, STOCK_DELETE, STOCK_DIALOG_AUTHENTICATION, STOCK_DIALOG_ERROR, STOCK_DIALOG_INFO, STOCK_DIALOG_QUESTION, STOCK_DIALOG_WARNING, STOCK_DIRECTORY, STOCK_DISCONNECT, STOCK_DND, STOCK_DND_MULTIPLE, STOCK_EDIT, STOCK_EXECUTE, STOCK_FILE, STOCK_FIND, STOCK_FIND_AND_REPLACE, STOCK_FLOPPY, STOCK_GOTO_BOTTOM, STOCK_GOTO_FIRST, STOCK_GOTO_LAST, STOCK_GOTO_TOP, STOCK_GO_BACK, STOCK_GO_DOWN, STOCK_GO_FORWARD, STOCK_GO_UP, STOCK_HARDDISK, STOCK_HELP, STOCK_HOME, STOCK_INDENT, STOCK_INDEX, STOCK_ITALIC, STOCK_JUMP_TO, STOCK_JUSTIFY_CENTER, STOCK_JUSTIFY_FILL, STOCK_JUSTIFY_LEFT, STOCK_JUSTIFY_RIGHT, STOCK_MEDIA_FORWARD, STOCK_MEDIA_NEXT, STOCK_MEDIA_PAUSE, STOCK_MEDIA_PLAY, STOCK_MEDIA_PREVIOUS, STOCK_MEDIA_RECORD, STOCK_MEDIA_REWIND, STOCK_MEDIA_STOP, STOCK_MISSING_IMAGE, STOCK_NETWORK, STOCK_NEW, STOCK_NO, STOCK_OK, STOCK_OPEN, STOCK_PASTE, STOCK_PREFERENCES, STOCK_PRINT, STOCK_PRINT_PREVIEW, STOCK_PROPERTIES, STOCK_QUIT,STOCK_REDO, STOCK_REFRESH, STOCK_REMOVE, STOCK_REVERT_TO_SAVED, STOCK_SAVE, STOCK_SAVE_AS, STOCK_SELECT_COLOR, STOCK_SELECT_FONT, STOCK_SORT_ASCENDING, STOCK_SORT_DESCENDING, STOCK_SPELL_CHECK, STOCK_STOP, STOCK_STRIKETHROUGH, STOCK_UNDELETE, STOCK_UNDERLINE, STOCK_UNDO, STOCK_UNINDENT, STOCK_YES, STOCK_ZOOM_100, STOCK_ZOOM_FIT, STOCK_ZOOM_IN, STOCK_ZOOM_OUT, terp-account, terp-crm, terp-mrp, terp-product, terp-purchase, terp-sale, terp-tools, terp-administration, terp-hr, terp-partner, terp-project, terp-report, terp-stock
|
|
||||||
|
|
||||||
- ``groups`` specifies which group of user can see the menu item.
|
- ``groups`` specifies which group of user can see the menu item.
|
||||||
(example : groups="admin"). See section " Management of Access Rights"
|
(example : groups="admin"). See section " Management of Access Rights"
|
||||||
for more information. Multiple groups should be separated by a ','
|
for more information. Multiple groups should be separated by a ','
|
||||||
|
@ -89,7 +82,6 @@ There are different types of simple actions:
|
||||||
* **Report**: The printing of a report
|
* **Report**: The printing of a report
|
||||||
o Custom Report: The personalized reports
|
o Custom Report: The personalized reports
|
||||||
o RML Report: The XSL:RML reports
|
o RML Report: The XSL:RML reports
|
||||||
* **Wizard**: The beginning of a Wizard
|
|
||||||
* **Execute**: The execution of a method on the server side
|
* **Execute**: The execution of a method on the server side
|
||||||
* **Group**: Gather some actions in one group
|
* **Group**: Gather some actions in one group
|
||||||
|
|
||||||
|
@ -248,44 +240,6 @@ This action is declared in server/bin/addons/stock/stock_view.xml.
|
||||||
Url Action
|
Url Action
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
|
|
||||||
Wizard Action
|
|
||||||
-------------
|
|
||||||
|
|
||||||
Here's an example of a .XML file that declares a wizard.
|
|
||||||
::
|
|
||||||
|
|
||||||
<?xml version="1.0"?>
|
|
||||||
<openerp>
|
|
||||||
<data>
|
|
||||||
<wizard string="Employee Info"
|
|
||||||
model="hr.employee"
|
|
||||||
name="employee.info.wizard"
|
|
||||||
id="wizard_employee_info"/>
|
|
||||||
</data>
|
|
||||||
</openerp>
|
|
||||||
|
|
||||||
A wizard is declared using a wizard tag. See "Add A New Wizard" for more information about wizard XML.
|
|
||||||
|
|
||||||
also you can add wizard in menu using following xml entry
|
|
||||||
::
|
|
||||||
|
|
||||||
<?xml version="1.0"?>
|
|
||||||
<openerp>
|
|
||||||
<data>
|
|
||||||
<wizard string="Employee Info"
|
|
||||||
model="hr.employee"
|
|
||||||
name="employee.info.wizard"
|
|
||||||
id="wizard_employee_info"/>
|
|
||||||
<menuitem
|
|
||||||
name="Human Resource/Employee Info"
|
|
||||||
action="wizard_employee_info"
|
|
||||||
type="wizard"
|
|
||||||
id="menu_wizard_employee_info"/>
|
|
||||||
</data>
|
|
||||||
</openerp>
|
|
||||||
|
|
||||||
|
|
||||||
Report Action
|
Report Action
|
||||||
-------------
|
-------------
|
||||||
|
|
||||||
|
@ -365,7 +319,6 @@ The action will be triggered if the user clicks on the account.journal.period n
|
||||||
|
|
||||||
When you declare wizard, report or menus, the ir.values creation is automatically made with these tags:
|
When you declare wizard, report or menus, the ir.values creation is automatically made with these tags:
|
||||||
|
|
||||||
* <wizard... />
|
|
||||||
* <menuitem... />
|
* <menuitem... />
|
||||||
* <report... />
|
* <report... />
|
||||||
|
|
||||||
|
|
|
@ -8,7 +8,7 @@ Getting the skeleton directory
|
||||||
|
|
||||||
Create a ``travel`` directory, that will contain our addon. Create **__init__.py** file and **__openerp__.py** files.
|
Create a ``travel`` directory, that will contain our addon. Create **__init__.py** file and **__openerp__.py** files.
|
||||||
|
|
||||||
Edit the **__openerp__.py** module configuration file:
|
Edit the **__openerp__.py** module manifest file:
|
||||||
|
|
||||||
.. code-block:: python
|
.. code-block:: python
|
||||||
|
|
||||||
|
@ -85,7 +85,8 @@ people call accounting "comptabilité", which explains the compta bit).
|
||||||
Defining a view is defining the interfaces the user will get when accessing
|
Defining a view is defining the interfaces the user will get when accessing
|
||||||
your module. Just defining a bunch of fields here should already get you
|
your module. Just defining a bunch of fields here should already get you
|
||||||
started on a complete interface. However, due to the complexity of doing it
|
started on a complete interface. However, due to the complexity of doing it
|
||||||
right, we recommend, once again, that download the travel agency module example from this link http://www.openerp.com/download/modules/5.0/.
|
right, we recommend, once again, that download the travel agency module example
|
||||||
|
from this link http://apps.openerp.com/
|
||||||
|
|
||||||
Next you should be able to create different views using other files to separate
|
Next you should be able to create different views using other files to separate
|
||||||
them from your basic/admin view.
|
them from your basic/admin view.
|
||||||
|
|
|
@ -1,5 +1,6 @@
|
||||||
.. _module_versioning:
|
.. _module_versioning:
|
||||||
|
|
||||||
|
=================
|
||||||
Module versioning
|
Module versioning
|
||||||
=================
|
=================
|
||||||
|
|
||||||
|
@ -40,7 +41,7 @@ functionalities can be brought together in a better module.
|
||||||
.. _`dependency hell`: http://en.wikipedia.org/wiki/Dependency_hell
|
.. _`dependency hell`: http://en.wikipedia.org/wiki/Dependency_hell
|
||||||
|
|
||||||
Example
|
Example
|
||||||
-------
|
=======
|
||||||
|
|
||||||
Whenever a new module is developed or must evolve, the above versioning policy
|
Whenever a new module is developed or must evolve, the above versioning policy
|
||||||
should be respected.
|
should be respected.
|
|
@ -1,6 +1,6 @@
|
||||||
=================================================
|
==================================
|
||||||
Security in OpenERP: users, groups and user roles
|
Security in OpenERP: users, groups
|
||||||
=================================================
|
==================================
|
||||||
|
|
||||||
Users and user roles are critical points concerning internal security in
|
Users and user roles are critical points concerning internal security in
|
||||||
OpenERP. OpenERP provides several security mechanisms concerning user roles,
|
OpenERP. OpenERP provides several security mechanisms concerning user roles,
|
||||||
|
@ -47,16 +47,15 @@ groups define the user access rights.
|
||||||
|
|
||||||
Figure 3: Example of group membership for a given user
|
Figure 3: Example of group membership for a given user
|
||||||
|
|
||||||
|
Rights
|
||||||
Record rules
|
======
|
||||||
============
|
|
||||||
|
|
||||||
Security rules are attached to groups. You can assign several security
|
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 :
|
rules at the group level, each rule being of one of the following types :
|
||||||
|
|
||||||
- access rights are global rights on an object,
|
- access rights are global rights on an object,
|
||||||
- record rules are records access filters,
|
- record rules are records access filters,
|
||||||
- record field rules are fields access filters,
|
- fields access right,
|
||||||
- workflow transition rules are operations rights.
|
- workflow transition rules are operations rights.
|
||||||
|
|
||||||
You can also define rules that are global, i.e. they are applied to all
|
You can also define rules that are global, i.e. they are applied to all
|
||||||
|
@ -70,7 +69,7 @@ that suit all applications. Therefore, like SAP, OpenERP is by default
|
||||||
pre-configured with best-practices.
|
pre-configured with best-practices.
|
||||||
|
|
||||||
Access rights
|
Access rights
|
||||||
+++++++++++++
|
=============
|
||||||
|
|
||||||
Access rights are rules that define the access a user can have on a particular
|
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
|
object . Those global rights are defined per document type or model. Rights
|
||||||
|
@ -97,13 +96,52 @@ 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
|
flagged as the salesman. The rule can be salesman = connected_user. With
|
||||||
that rule, only records respecting the rule will be displayed.
|
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
|
Field access rights
|
||||||
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.
|
.. 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.
|
||||||
|
|
||||||
Workflow transition rules
|
Workflow transition rules
|
||||||
+++++++++++++++++++++++++
|
+++++++++++++++++++++++++
|
||||||
|
@ -154,3 +192,4 @@ accesses of every users of OpenERP.
|
||||||
There are user groups that are between normal groups and the super user.
|
There are user groups that are between normal groups and the super user.
|
||||||
Those groups are Administration / Configuration and Administration / Access Rights.
|
Those groups are Administration / Configuration and Administration / Access Rights.
|
||||||
It gives to the users of those groups the necessary rights to configure access rights.
|
It gives to the users of those groups the necessary rights to configure access rights.
|
||||||
|
|
||||||
|
|
|
@ -0,0 +1,12 @@
|
||||||
|
=============
|
||||||
|
Miscellanous
|
||||||
|
=============
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:maxdepth: 2
|
||||||
|
|
||||||
|
06_misc_on_change_tips.rst
|
||||||
|
06_misc_list_font_style.rst
|
||||||
|
06_misc_need_action_specs.rst
|
||||||
|
06_misc_user_img_specs.rst
|
||||||
|
06_misc_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
|
spliced into the matrix somehow. This is done by adding lines composed
|
||||||
*only* of o2m record fields below the main record:
|
*only* of o2m record fields below the main record:
|
||||||
|
|
||||||
.. literalinclude:: import_o2m.txt
|
.. literalinclude:: 06_misc_import_o2m.txt
|
||||||
|
|
||||||
the sections in double-lines represent the span of two o2m
|
the sections in double-lines represent the span of two o2m
|
||||||
fields. During parsing, they are extracted into their own ``data``
|
fields. During parsing, they are extracted into their own ``data``
|
|
@ -1,10 +0,0 @@
|
||||||
|
|
||||||
.. _openerp library:
|
|
||||||
|
|
||||||
Server-side library
|
|
||||||
-------------------
|
|
||||||
|
|
||||||
.. automodule:: openerp
|
|
||||||
:members:
|
|
||||||
:undoc-members:
|
|
||||||
|
|
|
@ -1,45 +0,0 @@
|
||||||
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.
|
|
|
@ -15,16 +15,8 @@ OpenERP Server
|
||||||
03_module_dev
|
03_module_dev
|
||||||
04_security
|
04_security
|
||||||
05_test_framework
|
05_test_framework
|
||||||
90_using_gunicorn
|
06_misc
|
||||||
|
09_deployment
|
||||||
field_level_acl
|
|
||||||
import
|
|
||||||
module-versioning
|
|
||||||
on_change_tips
|
|
||||||
test-framework
|
|
||||||
user_img_specs
|
|
||||||
need_action_specs
|
|
||||||
font_style
|
|
||||||
|
|
||||||
OpenERP Server API
|
OpenERP Server API
|
||||||
''''''''''''''''''
|
''''''''''''''''''
|
||||||
|
|
|
@ -1,28 +0,0 @@
|
||||||
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>
|
|
|
@ -1,18 +0,0 @@
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
Loading…
Reference in New Issue