From aaff4459c438bdbb4b2d5f62bbd95a155904136c Mon Sep 17 00:00:00 2001 From: Xavier Morel Date: Fri, 28 Sep 2012 08:56:54 +0200 Subject: [PATCH] [DOC] fixes and cleanups bzr revid: xmo@openerp.com-20120928065654-jj3ot17dz8vd3wum --- .bzrignore | 31 ++++++---- doc/api/user_img_specs.rst | 25 ++++++-- doc/conf.py | 24 +++---- openerp/osv/expression.py | 124 ++++++++++++++++++++----------------- openerp/osv/orm.py | 12 +++- openerp/osv/query.py | 14 ++--- 6 files changed, 135 insertions(+), 95 deletions(-) diff --git a/.bzrignore b/.bzrignore index ba5258506be..8531ad42bbb 100644 --- a/.bzrignore +++ b/.bzrignore @@ -1,14 +1,19 @@ -.* -*.egg-info -*.orig -*.vim +.*.swp +.bzrignore +.idea +.project +.pydevproject +.ropeproject +.settings +.DS_Store +openerp/addons/* +openerp/filestore* +.Python +*.pyc +*.pyo +bin/* build/ -RE:^bin/ -RE:^dist/ -RE:^include/ - -RE:^share/ -RE:^man/ -RE:^lib/ - -RE:^doc/_build/ +include/ +lib/ +share/ +doc/_build/* diff --git a/doc/api/user_img_specs.rst b/doc/api/user_img_specs.rst index a915529accd..c6729eed920 100644 --- a/doc/api/user_img_specs.rst +++ b/doc/api/user_img_specs.rst @@ -3,9 +3,24 @@ 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. +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: -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. +* ``avatar_big``, a binary field holding the image. It is base-64 + encoded, and PIL-supported. Images stored are resized to 540x450 px, + to limitate the binary field size. + +* ``avatar``, a function binary field holding an automatically resized + version of the avatar_big field. It is also base-64 encoded, and + PIL-supported. Dimensions of the resized avatar are 180x150. This + field is used as an inteface to get and set the user avatar. + +When changing the avatar through the avatar function field, the new +image is automatically resized to 540x450, and stored in the +avatar_big field. This triggers the function field, that will compute +a 180x150 resized version of the image. + +An avatar field has been added to the users form view, as well as in +Preferences. When creating a new user, a default avatar is chosen +among 6 possible default images. diff --git a/doc/conf.py b/doc/conf.py index a5ff6bed7e1..ac5b8907e0e 100644 --- a/doc/conf.py +++ b/doc/conf.py @@ -16,9 +16,10 @@ import sys, os # If extensions (or modules to document with autodoc) are in another directory, # add these directories to sys.path here. If the directory is relative to the # documentation root, use os.path.abspath to make it absolute, like shown here. +#sys.path.insert(0, os.path.abspath('.')) sys.path.append(os.path.abspath('_themes')) -sys.path.insert(0, os.path.abspath('../addons')) -sys.path.insert(0, os.path.abspath('..')) +sys.path.append(os.path.abspath('..')) +sys.path.append(os.path.abspath('../openerp')) # -- General configuration ----------------------------------------------------- @@ -42,7 +43,7 @@ source_suffix = '.rst' master_doc = 'index' # General information about the project. -project = u'OpenERP Web Developers Documentation' +project = u'OpenERP Server Developers Documentation' copyright = u'2012, OpenERP s.a.' # The version info for the project you're documenting, acts as replacement for @@ -50,9 +51,9 @@ copyright = u'2012, OpenERP s.a.' # built documents. # # The short X.Y version. -version = '6.1' +version = '7.0' # The full version, including alpha/beta/rc tags. -release = '6.1' +release = '7.0b' # The language for content autogenerated by Sphinx. Refer to documentation # for a list of supported languages. @@ -170,7 +171,7 @@ html_sidebars = { #html_file_suffix = None # Output file base name for HTML help builder. -htmlhelp_basename = 'openerp-web-doc' +htmlhelp_basename = 'openerp-server-doc' # -- Options for LaTeX output -------------------------------------------------- @@ -189,7 +190,7 @@ latex_elements = { # Grouping the document tree into LaTeX files. List of tuples # (source start file, target name, title, author, documentclass [howto/manual]). latex_documents = [ - ('index', 'openerp-web-doc.tex', u'OpenERP Web Developers Documentation', + ('index', 'openerp-server-doc.tex', u'OpenERP Server Developers Documentation', u'OpenERP s.a.', 'manual'), ] @@ -219,7 +220,7 @@ latex_documents = [ # One entry per manual page. List of tuples # (source start file, name, description, authors, manual section). man_pages = [ - ('index', 'openerp-web-doc', u'OpenERP Web Developers Documentation', + ('index', 'openerp-server-doc', u'OpenERP Server Developers Documentation', [u'OpenERP s.a.'], 1) ] @@ -233,8 +234,8 @@ man_pages = [ # (source start file, target name, title, author, # dir menu entry, description, category) texinfo_documents = [ - ('index', 'OpenERPWebDocumentation', u'OpenERP Web Developers Documentation', - u'OpenERP s.a.', 'OpenERPWebDocumentation', 'Developers documentation for the openerp-web project.', + ('index', 'OpenERPServerDocumentation', u'OpenERP Server Developers Documentation', + u'OpenERP s.a.', 'OpenERPServerDocumentation', 'Developers documentation for the openobject-server project.', 'Miscellaneous'), ] @@ -247,11 +248,10 @@ texinfo_documents = [ # How to display URL addresses: 'footnote', 'no', or 'inline'. #texinfo_show_urls = 'footnote' -todo_include_todos = True # Example configuration for intersphinx: refer to the Python standard library. intersphinx_mapping = { 'python': ('http://docs.python.org/', None), - 'openerpserver': ('http://doc.openerp.com/trunk/developers/server', None), + 'openerpweb': ('http://doc.openerp.com/trunk/developers/web', None), 'openerpdev': ('http://doc.openerp.com/trunk/developers', None), } diff --git a/openerp/osv/expression.py b/openerp/osv/expression.py index e2a3391c8a4..5f2c0b915c1 100644 --- a/openerp/osv/expression.py +++ b/openerp/osv/expression.py @@ -22,102 +22,114 @@ """ Domain expression processing -The main duty of this module is to compile a domain expression into a SQL -query. A lot of things should be documented here, but as a first step in the -right direction, some tests in test_osv_expression.yml might give you some -additional information. +The main duty of this module is to compile a domain expression into a +SQL query. A lot of things should be documented here, but as a first +step in the right direction, some tests in test_osv_expression.yml +might give you some additional information. -For legacy reasons, a domain uses an inconsistent two-levels abstract syntax -(domains are regular Python data structures). At the first level, a domain -is an expression made of terms (sometimes called leaves) and (domain) operators -used in prefix notation. The available operators at this level are '!', '&', -and '|'. '!' is a unary 'not', '&' is a binary 'and', and '|' is a binary 'or'. -For instance, here is a possible domain. ( stands for an arbitrary term, -more on this later.) +For legacy reasons, a domain uses an inconsistent two-levels abstract +syntax (domains are regular Python data structures). At the first +level, a domain is an expression made of terms (sometimes called +leaves) and (domain) operators used in prefix notation. The available +operators at this level are '!', '&', and '|'. '!' is a unary 'not', +'&' is a binary 'and', and '|' is a binary 'or'. For instance, here +is a possible domain. ( stands for an arbitrary term, more on +this later.):: ['&', '!', , '|', , ] -It is equivalent to this pseudo code using infix notation: +It is equivalent to this pseudo code using infix notation:: (not ) and ( or ) -The second level of syntax deals with the term representation. A term is -a triple of the form (left, operator, right). That is, a term uses an infix -notation, and the available operators, and possible left and right operands -differ with those of the previous level. Here is a possible term: +The second level of syntax deals with the term representation. A term +is a triple of the form (left, operator, right). That is, a term uses +an infix notation, and the available operators, and possible left and +right operands differ with those of the previous level. Here is a +possible term:: ('company_id.name', '=', 'OpenERP') -The left and right operand don't have the same possible values. The left -operand is field name (related to the model for which the domain applies). -Actually, the field name can use the dot-notation to traverse relationships. -The right operand is a Python value whose type should match the used operator -and field type. In the above example, a string is used because the name field -of a company has type string, and because we use the '=' operator. When -appropriate, a 'in' operator can be used, and thus the right operand should be -a list. +The left and right operand don't have the same possible values. The +left operand is field name (related to the model for which the domain +applies). Actually, the field name can use the dot-notation to +traverse relationships. The right operand is a Python value whose +type should match the used operator and field type. In the above +example, a string is used because the name field of a company has type +string, and because we use the '=' operator. When appropriate, a 'in' +operator can be used, and thus the right operand should be a list. -Note: the non-uniform syntax could have been more uniform, but this would hide -an important limitation of the domain syntax. Say that the term representation -was ['=', 'company_id.name', 'OpenERP']. Used in a complete domain, this would -look like: +Note: the non-uniform syntax could have been more uniform, but this +would hide an important limitation of the domain syntax. Say that the +term representation was ['=', 'company_id.name', 'OpenERP']. Used in a +complete domain, this would look like:: - ['!', ['=', 'company_id.name', 'OpenERP']] + ['!', ['=', 'company_id.name', 'OpenERP']] -and you would be tempted to believe something like this would be possible: +and you would be tempted to believe something like this would be +possible:: - ['!', ['=', 'company_id.name', ['&', ..., ...]]] + ['!', ['=', 'company_id.name', ['&', ..., ...]]] -That is, a domain could be a valid operand. But this is not the case. A domain -is really limited to a two-level nature, and can not take a recursive form: a -domain is not a valid second-level operand. +That is, a domain could be a valid operand. But this is not the +case. A domain is really limited to a two-level nature, and can not +take a recursive form: a domain is not a valid second-level operand. Unaccent - Accent-insensitive search -OpenERP will use the SQL function 'unaccent' when available for the 'ilike' and -'not ilike' operators, and enabled in the configuration. -Normally the 'unaccent' function is obtained from the PostgreSQL 'unaccent' -contrib module[0]. +OpenERP will use the SQL function 'unaccent' when available for the +'ilike' and 'not ilike' operators, and enabled in the configuration. +Normally the 'unaccent' function is obtained from `the PostgreSQL +'unaccent' contrib module +`_. +.. todo: The following explanation should be moved in some external + installation guide -..todo: The following explanation should be moved in some external installation - guide +The steps to install the module might differ on specific PostgreSQL +versions. We give here some instruction for PostgreSQL 9.x on a +Ubuntu system. -The steps to install the module might differ on specific PostgreSQL versions. -We give here some instruction for PostgreSQL 9.x on a Ubuntu system. +Ubuntu doesn't come yet with PostgreSQL 9.x, so an alternative package +source is used. We use Martin Pitt's PPA available at +`ppa:pitti/postgresql +`_. -Ubuntu doesn't come yet with PostgreSQL 9.x, so an alternative package source -is used. We use Martin Pitt's PPA available at ppa:pitti/postgresql[1]. See -[2] for instructions. Basically: +.. code-block:: sh > sudo add-apt-repository ppa:pitti/postgresql > sudo apt-get update -Once the package list is up-to-date, you have to install PostgreSQL 9.0 and -its contrib modules. +Once the package list is up-to-date, you have to install PostgreSQL +9.0 and its contrib modules. + +.. code-block:: sh > sudo apt-get install postgresql-9.0 postgresql-contrib-9.0 When you want to enable unaccent on some database: +.. code-block:: sh + > psql9 -f /usr/share/postgresql/9.0/contrib/unaccent.sql -Here 'psql9' is an alias for the newly installed PostgreSQL 9.0 tool, together -with the correct port if necessary (for instance if PostgreSQL 8.4 is running -on 5432). (Other aliases can be used for createdb and dropdb.) +Here :program:`psql9` is an alias for the newly installed PostgreSQL +9.0 tool, together with the correct port if necessary (for instance if +PostgreSQL 8.4 is running on 5432). (Other aliases can be used for +createdb and dropdb.) + +.. code-block:: sh > alias psql9='/usr/lib/postgresql/9.0/bin/psql -p 5433' You can check unaccent is working: +.. code-block:: sh + > psql9 -c"select unaccent('hélène')" Finally, to instruct OpenERP to really use the unaccent function, you have to -start the server specifying the --unaccent flag. - -[0] http://developer.postgresql.org/pgdocs/postgres/unaccent.html -[1] https://launchpad.net/~pitti/+archive/postgresql -[2] https://launchpad.net/+help/soyuz/ppa-sources-list.html +start the server specifying the ``--unaccent`` flag. """ @@ -232,7 +244,7 @@ def is_leaf(element, internal=False): """ Test whether an object is a valid domain term. :param internal: allow or not the 'inselect' internal operator in the term. - This normally should be always left to False. + This normally should be always left to False. """ INTERNAL_OPS = TERM_OPERATORS + ('inselect',) return (isinstance(element, tuple) or isinstance(element, list)) \ diff --git a/openerp/osv/orm.py b/openerp/osv/orm.py index 934b6eaf2e4..afabda817f4 100644 --- a/openerp/osv/orm.py +++ b/openerp/osv/orm.py @@ -1218,7 +1218,11 @@ class BaseModel(object): return {'datas': datas} def import_data(self, cr, uid, fields, datas, mode='init', current_module='', noupdate=False, context=None, filename=None): - """Import given data in given module + """ + .. deprecated:: 7.0 + Use :meth:`~load` instead + + Import given data in given module This method is used when importing data via client menu. @@ -1302,6 +1306,10 @@ class BaseModel(object): ``False`` if there was an error and no id could be generated) and a list of messages. + The ids are those of the records created and saved (in database), in + the same order they were extracted from the file. They can be passed + directly to :meth:`~read` + Each message is a dictionary with the following keys: ``type`` @@ -5065,7 +5073,7 @@ class BaseModel(object): def is_transient(self): """ Return whether the model is transient. - See TransientModel. + See :class:`TransientModel`. """ return self._transient diff --git a/openerp/osv/query.py b/openerp/osv/query.py index 0b2bf47305a..252b301d531 100644 --- a/openerp/osv/query.py +++ b/openerp/osv/query.py @@ -73,15 +73,15 @@ class Query(object): :param connection: a tuple ``(lhs, table, lhs_col, col)``. The join corresponds to the SQL equivalent of:: - ``(lhs.lhs_col = table.col)`` + (lhs.lhs_col = table.col) :param outer: True if a LEFT OUTER JOIN should be used, if possible (no promotion to OUTER JOIN is supported in case the JOIN - was already present in the query, as for the moment - implicit INNER JOINs are only connected from NON-NULL - columns so it would not be correct (e.g. for - ``_inherits`` or when a domain criterion explicitly - adds filtering) + was already present in the query, as for the moment + implicit INNER JOINs are only connected from NON-NULL + columns so it would not be correct (e.g. for + ``_inherits`` or when a domain criterion explicitly + adds filtering) """ (lhs, table, lhs_col, col) = connection lhs = _quote(lhs) @@ -120,4 +120,4 @@ class Query(object): def __str__(self): return '' % self.get_sql() -# vim:expandtab:smartindent:tabstop=4:softtabstop=4:shiftwidth=4: \ No newline at end of file +# vim:expandtab:smartindent:tabstop=4:softtabstop=4:shiftwidth=4: