<feed xmlns='http://www.w3.org/2005/Atom'>
<title>Odoo/odoo/cli/__init__.py, branch 14.0</title>
<subtitle>The current checkout of upstream Odoo</subtitle>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/'/>
<entry>
<title>[ADD] odoo-bin cloc cli subcommand.</title>
<updated>2020-06-09T00:30:55+00:00</updated>
<author>
<name>Antony Lesuisse</name>
<email>al@openerp.com</email>
</author>
<published>2020-05-25T03:23:28+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=1c522ee778b520a215963922f5b17d2790c31907'/>
<id>1c522ee778b520a215963922f5b17d2790c31907</id>
<content type='text'>
Odoo cloc is a tool to count the number of relevant lines written in Python,
Javascript or XML. This can be used as rough metric for pricing maintenance of
customizations.

It has two modes of operation, either by providing a path:

    odoo-bin cloc -p module_path

Or by providing the name of a database:

    odoo-bin cloc --addons-path=dirs -d database

In the latter mode, only the custom code is accounted for.
Both modes can be used simultaneously.

Files that cannot be parsed are shown at the end of the report.
Parsing can fail due to syntax errors or excessive file size.

closes odoo/odoo#52635

X-original-commit: ae858c3ac66267b4726db459032b91a6be1cc1d6
Related: odoo/enterprise#11018
Signed-off-by: Olivier Dony (odo) &lt;odo@openerp.com&gt;
Co-authored-by: Thibault Francois &lt;tfr@odoo.com&gt;
Co-authored-by: Antoine Vandevenne (anv) &lt;anv@odoo.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Odoo cloc is a tool to count the number of relevant lines written in Python,
Javascript or XML. This can be used as rough metric for pricing maintenance of
customizations.

It has two modes of operation, either by providing a path:

    odoo-bin cloc -p module_path

Or by providing the name of a database:

    odoo-bin cloc --addons-path=dirs -d database

In the latter mode, only the custom code is accounted for.
Both modes can be used simultaneously.

Files that cannot be parsed are shown at the end of the report.
Parsing can fail due to syntax errors or excessive file size.

closes odoo/odoo#52635

X-original-commit: ae858c3ac66267b4726db459032b91a6be1cc1d6
Related: odoo/enterprise#11018
Signed-off-by: Olivier Dony (odo) &lt;odo@openerp.com&gt;
Co-authored-by: Thibault Francois &lt;tfr@odoo.com&gt;
Co-authored-by: Antoine Vandevenne (anv) &lt;anv@odoo.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[IMP] core, base: add tooling to populate database</title>
<updated>2020-03-30T21:30:13+00:00</updated>
<author>
<name>Xavier-Do</name>
<email>xdo@odoo.com</email>
</author>
<published>2020-03-27T10:22:37+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=f545fd274d7692a7d206aae50d5a68546bafe2bb'/>
<id>f545fd274d7692a7d206aae50d5a68546bafe2bb</id>
<content type='text'>
Some use case like testing performance or upgrade scripts required a database
with prefilled data, covering basic corner cases. A solution can be to
create data a procedural way.

This commit proposes an API to easily populate a model, usually by giving a
list of possible values for each field or by giving a compute method that will
be based on raw values of other fields.

The basic way to define how to populate a new field is to override `_populate_factories`,
a method that returns a sequence of pairs `(field_name, factory)`.

The definition of a field is a "factory", a function that returns a neverending iterator
combining its value(s) with the values of the iterator given in parameter.
Some factory helpers are given in `tools.populate.py`:
- `iterate(vals, weighs)` ensures that one record is created for each value
by iterating on them, then resumes as `random.choice` on those vals following weights
once the first iteration is finished.
- `cartesian(vals, weights)` makes a cartesian product of its own values with the values
of its input iterator, then resumes as a randomized generator.
- `compute(function)` calls the given function with the current values dict and a random object,
and assigns the current field to the returned value.
- ...

Each iterator yields dictionaries of field values, and the factory should add a
value for the current field(s).  The yielded dictionaries also contain a pseudo_field
`"__complete"`, that indicates whether this step is some randomized data
to reach the expected count of records.  A falsy value indicates that the iterator
is still covering mandatory cases.  This indicates whether a cartesian product is
finished, or an `iterate` has consumed all its values.

The order of the factories is quite important, since some computed fields may need
other fields to be defined, and `cartesian` factories should always be at the beginning
to avoid having too many combination.  That is why the factories are given as a list of
pairs instead of a dictionary; this makes it easier to insert elements at any place.

Example:
field A: cartesian([T, F])
field B: cartesian([0, 1])
field C: iterate([a, b, c, d, e])
field D: compute(1-B)

_c is shortcut for __complete
_ is a random value, or result of a random value

```
iter | root  | field A  | field B | field C     | field D   | result
0     {_c:F}  {... A:T}  {... B:0} {...C:a}      {...D:1}    T,0,a,1 complete:False
                         {... B:1} {...C:b}      {...D:0}    T,1,b,0 complete:False
              {... A:F}  {... B:0} {...C:c}      {...D:1}    F,0,c,1 complete:False
                         {... B:1} {...C:d}      {...D:0}    F,1,d,0 complete:False
1     {_c:T}  {... A:_}  {... B:_} {...C:e,_c:F} {...D:_}    _,_,e,_ complete:False
2     {_c:T}  {... A:_}  {... B:_} {...C:_}      {...D:_}    _,_,_,_ complete:True
```

X-original-commit: 4c0182dafa584853ed83a166096f45c33c06a245</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some use case like testing performance or upgrade scripts required a database
with prefilled data, covering basic corner cases. A solution can be to
create data a procedural way.

This commit proposes an API to easily populate a model, usually by giving a
list of possible values for each field or by giving a compute method that will
be based on raw values of other fields.

The basic way to define how to populate a new field is to override `_populate_factories`,
a method that returns a sequence of pairs `(field_name, factory)`.

The definition of a field is a "factory", a function that returns a neverending iterator
combining its value(s) with the values of the iterator given in parameter.
Some factory helpers are given in `tools.populate.py`:
- `iterate(vals, weighs)` ensures that one record is created for each value
by iterating on them, then resumes as `random.choice` on those vals following weights
once the first iteration is finished.
- `cartesian(vals, weights)` makes a cartesian product of its own values with the values
of its input iterator, then resumes as a randomized generator.
- `compute(function)` calls the given function with the current values dict and a random object,
and assigns the current field to the returned value.
- ...

Each iterator yields dictionaries of field values, and the factory should add a
value for the current field(s).  The yielded dictionaries also contain a pseudo_field
`"__complete"`, that indicates whether this step is some randomized data
to reach the expected count of records.  A falsy value indicates that the iterator
is still covering mandatory cases.  This indicates whether a cartesian product is
finished, or an `iterate` has consumed all its values.

The order of the factories is quite important, since some computed fields may need
other fields to be defined, and `cartesian` factories should always be at the beginning
to avoid having too many combination.  That is why the factories are given as a list of
pairs instead of a dictionary; this makes it easier to insert elements at any place.

Example:
field A: cartesian([T, F])
field B: cartesian([0, 1])
field C: iterate([a, b, c, d, e])
field D: compute(1-B)

_c is shortcut for __complete
_ is a random value, or result of a random value

```
iter | root  | field A  | field B | field C     | field D   | result
0     {_c:F}  {... A:T}  {... B:0} {...C:a}      {...D:1}    T,0,a,1 complete:False
                         {... B:1} {...C:b}      {...D:0}    T,1,b,0 complete:False
              {... A:F}  {... B:0} {...C:c}      {...D:1}    F,0,c,1 complete:False
                         {... B:1} {...C:d}      {...D:0}    F,1,d,0 complete:False
1     {_c:T}  {... A:_}  {... B:_} {...C:e,_c:F} {...D:_}    _,_,e,_ complete:False
2     {_c:T}  {... A:_}  {... B:_} {...C:_}      {...D:_}    _,_,_,_ complete:True
```

X-original-commit: 4c0182dafa584853ed83a166096f45c33c06a245</pre>
</div>
</content>
</entry>
<entry>
<title>[FIX] Various P3-related import changes</title>
<updated>2017-04-28T07:06:53+00:00</updated>
<author>
<name>xmo-odoo</name>
<email>xmo@odoo.com</email>
</author>
<published>2017-04-28T07:06:53+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=b4429c2a91889bf60b56e0c7909c844d357363f7'/>
<id>b4429c2a91889bf60b56e0c7909c844d357363f7</id>
<content type='text'>
* LDAP import: python-ldap is not python3-compatible, pyldap is

  Warning: only supported from debian Stretch (current testing)?
  https://packages.debian.org/search?searchon=names&amp;keywords=pyldap

* implicitly relative imports
* imports of moved or removed stdlib modules

issue #8530
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* LDAP import: python-ldap is not python3-compatible, pyldap is

  Warning: only supported from debian Stretch (current testing)?
  https://packages.debian.org/search?searchon=names&amp;keywords=pyldap

* implicitly relative imports
* imports of moved or removed stdlib modules

issue #8530
</pre>
</div>
</content>
</entry>
<entry>
<title>[FIX] odoo: rename imports and adapt import hooks</title>
<updated>2016-09-02T15:28:12+00:00</updated>
<author>
<name>Raphael Collet</name>
<email>rco@openerp.com</email>
</author>
<published>2016-09-02T14:16:50+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=4a700d0ad9eecb00233f734042a96c3959aa7e83'/>
<id>4a700d0ad9eecb00233f734042a96c3959aa7e83</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[REF] openerp: move `openerp` to `odoo`</title>
<updated>2016-09-02T15:28:12+00:00</updated>
<author>
<name>Raphael Collet</name>
<email>rco@openerp.com</email>
</author>
<published>2016-09-02T13:58:39+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=9e64f9f9514194d74e166b032add8511182f2677'/>
<id>9e64f9f9514194d74e166b032add8511182f2677</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
</feed>
