From d9554b698a44bbd2fadcdd23ac60c4477be6ace0 Mon Sep 17 00:00:00 2001 From: Antony Lesuisse Date: Sun, 11 Nov 2012 03:39:03 +0100 Subject: [PATCH] rearrange toc, remove some deprecated stuff bzr revid: al@openerp.com-20121111023903-yus5wxlw06ods46f --- doc/01_getting_started.rst | 18 +++- doc/03_module_dev.rst | 1 + doc/03_module_dev_01.rst | 94 ------------------- doc/03_module_dev_04.rst | 47 ---------- doc/03_module_dev_05.rst | 5 +- ...le-versioning.rst => 03_module_dev_06.rst} | 3 +- doc/04_security.rst | 67 ++++++++++--- doc/06_misc.rst | 12 +++ doc/{import.rst => 06_misc_import.rst} | 2 +- ...{import_o2m.txt => 06_misc_import_o2m.txt} | 0 ..._style.rst => 06_misc_list_font_style.rst} | 0 ...pecs.rst => 06_misc_need_action_specs.rst} | 0 ...ge_tips.rst => 06_misc_on_change_tips.rst} | 0 ...g_specs.rst => 06_misc_user_img_specs.rst} | 0 ...0_using_gunicorn.rst => 09_deployment.rst} | 0 doc/api_core.rst | 10 -- doc/field_level_acl.rst | 45 --------- doc/index.rst | 12 +-- doc/list_font_style.rst | 28 ------ doc/startup.rst | 18 ---- 20 files changed, 91 insertions(+), 271 deletions(-) rename doc/{module-versioning.rst => 03_module_dev_06.rst} (99%) create mode 100644 doc/06_misc.rst rename doc/{import.rst => 06_misc_import.rst} (99%) rename doc/{import_o2m.txt => 06_misc_import_o2m.txt} (100%) rename doc/{font_style.rst => 06_misc_list_font_style.rst} (100%) rename doc/{need_action_specs.rst => 06_misc_need_action_specs.rst} (100%) rename doc/{on_change_tips.rst => 06_misc_on_change_tips.rst} (100%) rename doc/{user_img_specs.rst => 06_misc_user_img_specs.rst} (100%) rename doc/{90_using_gunicorn.rst => 09_deployment.rst} (100%) delete mode 100644 doc/api_core.rst delete mode 100644 doc/field_level_acl.rst delete mode 100644 doc/list_font_style.rst delete mode 100644 doc/startup.rst diff --git a/doc/01_getting_started.rst b/doc/01_getting_started.rst index 79b2bc94298..267e2759550 100644 --- a/doc/01_getting_started.rst +++ b/doc/01_getting_started.rst @@ -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 ======== diff --git a/doc/03_module_dev.rst b/doc/03_module_dev.rst index a019af94601..033ba4b9267 100644 --- a/doc/03_module_dev.rst +++ b/doc/03_module_dev.rst @@ -10,3 +10,4 @@ Modules 03_module_dev_03 03_module_dev_04 03_module_dev_05 + 03_module_dev_06 diff --git a/doc/03_module_dev_01.rst b/doc/03_module_dev_01.rst index b704e44fcab..a537f5fe396 100644 --- a/doc/03_module_dev_01.rst +++ b/doc/03_module_dev_01.rst @@ -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 `_ chapter. -Wizards -""""""" - -Here's an example of a .XML file that declares a wizard. - -.. code-block:: xml - - - - - - - - -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 - - - - - - - - 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 +++++++++ diff --git a/doc/03_module_dev_04.rst b/doc/03_module_dev_04.rst index f8ad0e2f554..8ff73cdc7e0 100644 --- a/doc/03_module_dev_04.rst +++ b/doc/03_module_dev_04.rst @@ -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="" 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. -:: - - - - - - - - -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 -:: - - - - - - - - - - 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: - * * * diff --git a/doc/03_module_dev_05.rst b/doc/03_module_dev_05.rst index c5d947fc5e9..686fb6fe099 100644 --- a/doc/03_module_dev_05.rst +++ b/doc/03_module_dev_05.rst @@ -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. diff --git a/doc/module-versioning.rst b/doc/03_module_dev_06.rst similarity index 99% rename from doc/module-versioning.rst rename to doc/03_module_dev_06.rst index 7a4c127d6d8..ebb97ea9010 100644 --- a/doc/module-versioning.rst +++ b/doc/03_module_dev_06.rst @@ -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. diff --git a/doc/04_security.rst b/doc/04_security.rst index 52d56430b3c..b1f9f565384 100644 --- a/doc/04_security.rst +++ b/doc/04_security.rst @@ -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 ```` 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. + diff --git a/doc/06_misc.rst b/doc/06_misc.rst new file mode 100644 index 00000000000..c82022b812e --- /dev/null +++ b/doc/06_misc.rst @@ -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 diff --git a/doc/import.rst b/doc/06_misc_import.rst similarity index 99% rename from doc/import.rst rename to doc/06_misc_import.rst index 147907722f2..79022006957 100644 --- a/doc/import.rst +++ b/doc/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 *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`` diff --git a/doc/import_o2m.txt b/doc/06_misc_import_o2m.txt similarity index 100% rename from doc/import_o2m.txt rename to doc/06_misc_import_o2m.txt diff --git a/doc/font_style.rst b/doc/06_misc_list_font_style.rst similarity index 100% rename from doc/font_style.rst rename to doc/06_misc_list_font_style.rst diff --git a/doc/need_action_specs.rst b/doc/06_misc_need_action_specs.rst similarity index 100% rename from doc/need_action_specs.rst rename to doc/06_misc_need_action_specs.rst diff --git a/doc/on_change_tips.rst b/doc/06_misc_on_change_tips.rst similarity index 100% rename from doc/on_change_tips.rst rename to doc/06_misc_on_change_tips.rst diff --git a/doc/user_img_specs.rst b/doc/06_misc_user_img_specs.rst similarity index 100% rename from doc/user_img_specs.rst rename to doc/06_misc_user_img_specs.rst diff --git a/doc/90_using_gunicorn.rst b/doc/09_deployment.rst similarity index 100% rename from doc/90_using_gunicorn.rst rename to doc/09_deployment.rst diff --git a/doc/api_core.rst b/doc/api_core.rst deleted file mode 100644 index 05ddf177698..00000000000 --- a/doc/api_core.rst +++ /dev/null @@ -1,10 +0,0 @@ - -.. _openerp library: - -Server-side library -------------------- - -.. automodule:: openerp - :members: - :undoc-members: - diff --git a/doc/field_level_acl.rst b/doc/field_level_acl.rst deleted file mode 100644 index 53a304a1faf..00000000000 --- a/doc/field_level_acl.rst +++ /dev/null @@ -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 ```` 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 diff --git a/doc/index.rst b/doc/index.rst index d62adb2c0bd..5842a46ed7f 100644 --- a/doc/index.rst +++ b/doc/index.rst @@ -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 '''''''''''''''''' diff --git a/doc/list_font_style.rst b/doc/list_font_style.rst deleted file mode 100644 index f47a654aa34..00000000000 --- a/doc/list_font_style.rst +++ /dev/null @@ -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 - - - [...] - diff --git a/doc/startup.rst b/doc/startup.rst deleted file mode 100644 index 0cc83cf48be..00000000000 --- a/doc/startup.rst +++ /dev/null @@ -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. -