odoo
/
odoo
2
0
Fork 0
Code Pull Requests Releases Activity

rearrange toc, remove some deprecated stuff 

bzr revid: al@openerp.com-20121111023903-yus5wxlw06ods46f
This commit is contained in:
Antony Lesuisse 2012-11-11 03:39:03 +01:00
parent 4820450aef
commit d9554b698a
20 changed files with 91 additions and 271 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
doc/01_getting_started.rst
View File

@ -155,7 +155,23 @@ You can specify alternate configuration files with ::
-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
========

1
doc/03_module_dev.rst
View File

@ -10,3 +10,4 @@ Modules
03_module_dev_03
03_module_dev_04
03_module_dev_05
03_module_dev_06

94
doc/03_module_dev_01.rst
View File

@ -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.
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
""""""""
@ -491,63 +454,6 @@ The squared nodes represent other Workflows;
* 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
+++++++++

47
doc/03_module_dev_04.rst
View File

@ -27,8 +27,6 @@ along with icons and other fields.
name="My Menu"
action="action_xml_id"
icon="NAME_FROM_LIST"
web_icon="static/src/img/icon.png"
web_icon_hover="static/src/img/icon-hover.png"
groups="groupname"
sequence="<integer>"
parent="parent_menu_xml_id"
@ -46,11 +44,6 @@ Where
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
"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.
(example : groups="admin"). See section " Management of Access Rights"
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
o Custom Report: The personalized reports
o RML Report: The XSL:RML reports
* **Wizard**: The beginning of a Wizard
* **Execute**: The execution of a method on the server side
* **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
-----------
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
-------------
@ -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:
* <wizard... />
* <menuitem... />
* <report... />

5
doc/03_module_dev_05.rst
View File

@ -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.
Edit the **__openerp__.py** module configuration file:
Edit the **__openerp__.py** module manifest file:
.. 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
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
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
them from your basic/admin view.

3
doc/module-versioning.rst → doc/03_module_dev_06.rst
View File

@ -1,5 +1,6 @@
.. _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
Example
-------
=======
Whenever a new module is developed or must evolve, the above versioning policy
should be respected.

67
doc/04_security.rst
View File

@ -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
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
Record rules
============
Rights
======
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,
- fields access right,
- workflow transition rules are operations rights.
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.
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
@ -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
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.
Field access rights
+++++++++++++++++++
.. 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
+++++++++++++++++++++++++
@ -154,3 +192,4 @@ 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.

12
doc/06_misc.rst Normal file
View File

@ -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

2
doc/import.rst → doc/06_misc_import.rst
View File

@ -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:: import_o2m.txt
.. literalinclude:: 06_misc_import_o2m.txt
the sections in double-lines represent the span of two o2m
fields. During parsing, they are extracted into their own ``data``

0
doc/import_o2m.txt → doc/06_misc_import_o2m.txt
View File

0
doc/font_style.rst → doc/06_misc_list_font_style.rst
View File

0
doc/need_action_specs.rst → doc/06_misc_need_action_specs.rst
View File

0
doc/on_change_tips.rst → doc/06_misc_on_change_tips.rst
View File

0
doc/user_img_specs.rst → doc/06_misc_user_img_specs.rst
View File

0
doc/90_using_gunicorn.rst → doc/09_deployment.rst
View File

10
doc/api_core.rst
View File

@ -1,10 +0,0 @@
.. _openerp library:
Server-side library
-------------------
.. automodule:: openerp
:members:
:undoc-members:

45
doc/field_level_acl.rst
View File

@ -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.

12
doc/index.rst
View File

@ -15,16 +15,8 @@ OpenERP Server
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
06_misc
09_deployment
OpenERP Server API
''''''''''''''''''

28
doc/list_font_style.rst
View File

@ -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>

18
doc/startup.rst
View File

@ -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.