When using the windows installer in French language, the `Hôte` label
used to configure postgresql server does not display correctly.
The LangString documentation does not specify how to use the special
characters but after some tests, specifying a BOM for the nsi file seems
to be the way to go.
closesodoo/odoo#65370
X-original-commit: 3d0871d1d5895f0f04175f2633344f2f1b05a081
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Increase the distinction between a journal entry linked to a bank
statement line and another one linked to a payment by adding a smart
button linked to them.
Also improve the navigation from the Bank And Cash view to directly
open the linked bank statement line or payment.
Task id #2448618closesodoo/odoo#65316
Signed-off-by: William André (wan) <wan@odoo.com>
2021-02-01 16:58:25 +00:00
Jeremy Kersten"Romain Derie <rde@odoo.com>""Jeremy Kersten <jke@odoo.com>"
Basic tests & tests of the 3 fixes of #64328
Be sure that we have a beautiful error page and not a black/white error
Be sure that slug_matching with 308 redirect works as expected and don't
raise a RequestUID exception.
closesodoo/odoo#64889
X-original-commit: 3af11f0b6db0efb6c912b25bcd04d2cbe9a07d57
Co-authored-by: "Romain Derie <rde@odoo.com>"
Co-authored-by: "Jeremy Kersten <jke@odoo.com>"
Before this commit, a 308 on a route with a modelconverter for a model
that have a seo_name field will crash with an exception:
Cannot iterate on RequestUID
Another simplest solution was to use a with_user(SUPERUSER_ID) but in this case
it bypass the security set and display the name of the record even if not yet
published.
How to reproduce:
Create a 308 from /shop/<product> to /mag/<product>
Unpublish product 10
Try to access /shop/product-10
You have an unmanaged '500 internal error"
because slug_matching -> build -> to_url -> slug with a record with Requestuid
as env._uid.
X-original-commit: 4ac2cab96655a3c5e673b0a04be5599dba507850
Before this commit the Dynamic Products snippet was displaying a message
box instead of its content until its template and product category were
selected.
After this commit the Dynamic Products snippet is automatically
configured on drop with the first available template and the first
available product category. The message box only appears if no product
category exists yet. Also an "All Products" category was added as first
element of the list to make the snippet usable before categories are
defined.
task-2439295
closesodoo/odoo#65342
X-original-commit: db3ced474e44b5a8188f0d77521bfcaee2575060
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When a user on website sends livechat feedbacks:
- Good -> send an average smiley 😐
- Average -> send ?? instead of smiley
This is because in e4a4ffb value of good (😊) was changed from 10 to 5,
and value for average (😐) was changed from 5 to 3, but it was not
reflected in one part of the code.
opw-2447246
closesodoo/odoo#65338
X-original-commit: 45ea88e58d2a834da4c5ad8ff656481ac1f9ab5d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In backend, we may want to use tags for advanced use cases like reporting,
filtering, aggregating in spreadsheet, ... However right now we cannot
define tag categories dedicated for 'internal use only'.
Similar to eLearning, this commit introduces facility to decide whether or
not to show the tag categories on the website. It is based on website.published
mixin. is_published field will be used for taht purpose. ACLs are updated
accordingly. If the category is hidden from the website then it is used for
internal purpose only.
In order to make all the events menu together, this commit moves the
'Event Tags Categories' menu after 'Event Stages'.
COM PR odoo/odoo#63485
UPG PR odoo/upgrade#2088
Task Id-2300230
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This patch complements the previous one by ensuring that any
`cache_invalidated=True` flag inherited from the master process
(pre-fork mode) cannot trigger a cache clear.
This could occur when the first request is served, because the flag was
never clear in the master process, which never server any request.
At the end of `check_signaling()`, the local cache has either been
cleared because a (real) increment of the cache sequence was detected,
or it is considered still valid. The final state of the
`cache_invalidated` flag should reflect this, by being `False`.
closesodoo/odoo#65346
X-original-commit: 3585c2c38955ece4292da77de7173fb31a6992ba
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
During loading, the registry clears all `ormcache` data multiple
times, in order to ensure consistency with the newly loaded module
data.
Since 083c70bbb6, this was done by
calling `self.clear_caches()`, with the side-effect
of signalling to all other worker processes that the cache
*needs* to be invalidated, which is actually untrue.
If the other workers have any reason to reload their own registries,
they will also clear their own cache in the process - there is no
need to forcefully invalidate it globally.
One could think that combining the pre-fork mode with the `-d <db>`
parameter would mitigate this issue, by making all workers inherit from
a fully loaded registry, In reality it doesn't work, because they also
inherit from the `cache_invalidated=True` flag, that was never cleared
in the master process. So despite having a fully loaded registry, the
newly forked workers will signal a cache invalidation upon serving
their first request.
Further, in a multi-tenant setup with large numbers of databases,
registries may be recycled and loaded much more frequently than
new workers are starting, due to the limited registry LRU, amplifying
this effect a bit.
~~
This patch directly clears the cache LRU without going through
`clear_cache()`, avoiding setting the `cache_invalidated` flag of the
registry, and thus not signalling to other workers.
This is similar to what was being done before 083c70bbb6,
where the LRU was dropped like all other lazy properties.
X-original-commit: 87aef4e3a36d92462454f51960abf7215c5ab7f1
- Go to Point of Sale > Configuration > Settings & enable "Cash Rounding"
- Configure POS:
* Enable Invoicing
* Enable "Cash Rounding" and "Only on cash methods"
* Select 0.05 HALF-UP Rounding Method
- Start POS session
- Select a Product and change its Price to a value that should be rounded (i.e. $ 16.51)
- Select a Customer
- Proceed to Payment
- Enable Invoice
- Select Bank Payment method
- Validate
No rounding is applied as expected, but the rounding line still appears on printed Invoice.
opw-2449222
closesodoo/odoo#65345
X-original-commit: d207a0fbe63c40eb879964ae6fb6c742d276fa5e
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
In order to make a wow effect right after DB install we enrich the base
company based on the given email address or company website at install.
In order to achieve that goal we use the partner_autocomplete service from
IAP. It uses free credits that are offered to new clients on saas platform.
Only the fields that are not filled yet are enriched to avoid erasing user
entered data, except logo. Indeed as partner_autocomplete is probably installed
as a core app (mail -> iap -> partner_autocomplete auto install chain) it is
unlikely that people already updated their company logo.
We consider that having a call to IAP consuming a token is ok for a standard
use case, especially that
* if no iap service is configured call to IAP won't add much timing;
* on Odoo SaaS free credits are given and company is enriched;
* on custom SaaS with custom iap service, at db creation probably no
credits are given and call will simply give no results back;
We decided to call IAP asynchronously at client web load. Session combined to
a boolean field on company model allows to do this call only once per company.
Doing this allows to avoid adding yet another post init hook. It also eases
behavior tweak through inheritance.
This call is limited to admin for obvious security reasons as well as
performance reason (limiting calls to external providers). As call will be
done once per company generally admin is the first person to log into the
its newly created Odoo.
In addition to enriching companies on the fly, we also enrich companies
when creating them. It allows to have an enrich on companies existing
before using autocomplete, and have results of enrich directly at create
for companies created after installing this module.
LINKS
Task ID-2322455
PR odoo/odoo#64600
PR odoo/upgrade#2086
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: Thibault Delavallee <tde@odoo.com>
In addition to enriching companies on the fly, we also enrich companies
when creating them. It allows to have an enrich on companies existing
before using autocomplete, and have results of enrich directly at create
for companies created after installing this module.
LINKS
Task ID-2322455
PR #64600
PR odoo/upgrade#2086
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
In order to make a wow effect right after DB install we enrich the base
company based on the given email address or company website at install.
In order to achieve that goal we use the partner_autocomplete service from
IAP. It uses free credits that are offered to new clients on saas platform.
Only the fields that are not filled yet are enriched to avoid erasing user
entered data, except logo. Indeed as partner_autocomplete is probably installed
as a core app (mail -> iap -> partner_autocomplete auto install chain) it is
unlikely that people already updated their company logo.
We consider that having a call to IAP consuming a token is ok for a standard
use case, especially that
* if no iap service is configured call to IAP won't add much timing;
* on Odoo SaaS free credits are given and company is enriched;
* on custom SaaS with custom iap service, at db creation probably no
credits are given and call will simply give no results back;
We decided to call IAP asynchronously at client web load. Session combined to
a boolean field on company model allows to do this call only once per company.
Doing this allows to avoid adding yet another post init hook. It also eases
behavior tweak through inheritance.
This call is limited to admin for obvious security reasons as well as
performance reason (limiting calls to external providers). As call will be
done once per company generally admin is the first person to log into the
its newly created Odoo.
LINKS
Task ID-2322455
PR odoo/odoo#64600
PR odoo/upgrade#2086
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
In this commit we move iap functions onto a small tool model. It allows to
hide some details in a sub model. It also allows to define a mock that will
be used in tests afterwards.
LINKS
Task ID-2322455
PR #64600
PR odoo/upgrade#2086
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Steps:
- As admin, go to Settings > Users & Companies > Users
- Edit Mark Demo (demo)
- In Human Resources > Attendances, select Manual Attendance or blank
- As demo, go to My Profile
- Click the smart button showing the hours worked for the last month
- Remove all filters
Bug:
The demo user, who hasn't the rights to see the other employees
attendances, can see them.
Explanation:
Every user must have the right to read attendances in order to see their
own attendances. Not giving the users the read rights in the security
record rule prevents the record rule from being applied when reading
attendances. This makes the read access rights the only rule and allows
everyone to see the attendances of the others.
This commit also fixes the default selected employee when going to the
attendances tree view on these paths:
- User
- Employee
- User > Employee
In fact, sometime, `active_id` is the ÌD of the user and not of the
employee. This leads to incorrect results since another employee's
attendances are shown.
Finally, this commit prevents users from creating attendances from other
apps since only attendance officers and above can have access to the
creation form within the Attendances app.
opw:2440117
closesodoo/odoo#65334
X-original-commit: b3247c81200200590d669b76a58d06e6adf66d69
Signed-off-by: backspac <backspac@users.noreply.github.com>
Bug
===
Since e598e74648 the action button "Launch"
in the mailing form view was renamed. Therefor, the mass mailing tour is
broken and need to be updated.
Task 2446835
closesodoo/odoo#65300
X-original-commit: ef0f483612316fbf354bd27a4573ec3292b94328
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As Fedora 32 was the current release when Odoo 14.0 was released, this
should be the supported version.
Also, a few old libs were still in mentioned in the packaging files.
They flew under the radar because they never broke the packaging.
This is not the case anymore, those libs disappeared from the Fedora
repos.
It seems that pyparsing is not used anymore since 5a1c06a19 and thus can
be safely removed from `requirements.txt` too.
pychart is not used anymore since 3425752ea.
While at it, remove mix of tabs and spaces in package.dffedora, also add
missing packages to avoid installation at test time.
Now that I started down the slippery slope, also removed some `-dev`
packages in package.dfsrc as wheel's are available.
Finally, the rpm install script now detects the python ABI version in
order to avoid update this file at each ABI change in Fedora.
Fixes#63719closesodoo/odoo#65288
X-original-commit: a8deb1dd433e3a1690d593e83ade6af46326a26b
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
add home/door fields in children form views to allign it
with the full form view so that the user can
edit these fields from the quick child form without having
to leave and open the full form
Task-2423694
closesodoo/odoo#65201
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
with this commit we are updating sequence of onboarding tours
task-2444153
closesodoo/odoo#65244
X-original-commit: a928beccb09f4db4234356e5e4f7bdf090ecc964
Related: odoo/enterprise#16026
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Replace the hardcoded year in the footer by the year dynamicaly
fetch from the current date.
task-2431308
closesodoo/odoo#65243
X-original-commit: f4663c69df03c9219cc613164b03e5860956b837
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Fix recently added lead assignment tests, notably about query counters
and random behavior of lead merge.
SPECIFICATIONS
Split performance tests from unit tests. Performance tests should be
reproducible. Currently there are too much varying query counters.
Fix lead merge process done during assign. As duplicate leads are merged
final opportunity could not fit team domain anymore. This is a side effect
of lead deduplication. In this case this is linked to priority field that is set
to the value of the "final" opportunity, whatever the value of other leads
merged into it. We think that priority is a field that should be managed
more carefully. We choose to set it as the highest value found in leads
merged.
LINKS
Task ID-2446759 (lead merge priority field management)
Task ID-2446883 (query counters fix)
PR odoo/odoo#65016
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When merging leads final priority is currently the one of the lead considered
as the master lead. This is based on ``_sort_by_confidence_level`` who sorts
on confidence but not on priority.
We think final priority should be the highest one from merged leads. Indeed
if a top priority lead is merged into a low priority one we should not loose
the priority information. It is better to keep the final lead with an high
priority and let salesmen move it downwards.
LINKS
Task ID-2446759 (lead merge priority field management)
Task ID-2446883 (query counters fix)
PR odoo/odoo#65016
Purpose of this commit is to make clearer how final opportunity value are
computed or chosen when merging leads. Functionally nothing should change
with this commit.
LINKS
Task ID-2446759 (lead merge priority field management)
Task ID-2446883 (query counters fix)
PR odoo/odoo#65016
Purpose is to test internals of lead merge method, notably about values
of final opportunity. That way we ensure future changes will be reflected
in tests and regressions will be avoided.
LINKS
Task ID-2446759 (lead merge priority field management)
Task ID-2446883 (query counters fix)
PR odoo/odoo#65016
Purpose is to split assign tests related to results (leads being assigned,
with deduplication, compared to team and member domains) from tests related
to performance (query counters).
Assign process is a random process: randomizing teams leads to searching,
assigning and de-duplicating leads in various order. As a lot of search
are implied during assign process query counters may vary from run to run.
"Heavy" performance test included here ranged from 6K to 6.3K queries. Either
we set high counters maximum which makes those tests less useful. Either we
avoid random if possible which is what we decided to do by setting the seed
of random in tests.
SPECIFICATIONS
For results oriented tests remove query counters. Those tests should simply
ensure results of assign process, notably that even with random choice between
team and users we always have leads assigned with right domain and counts.
For performance oriented tests using query counters set random seed to have
a reproducible scenario and have less random in query counters.
LINKS
Task ID-2446759 (lead merge priority field management)
Task ID-2446883 (query counters fix)
PR odoo/odoo#65016
Bug
===
Since 569d35bc2d a fix have been provided
to fix the vertical position of the emoji widget in mobile view.
But the fix have been done in a wrong way and we should use the Odoo CSS
class instead to detect mobile (and not a bootstrap media query).
Task 2253851
closesodoo/odoo#65070
X-original-commit: 72f7acded30cd49c210faefbec195e7b6d13dacb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
We should open the cashdrawer when paying with a non cash payment
method if change should be returned to the customer.
Use case: The customer wants to pay 10€ more with his card to get 10€
in cash in return.
closesodoo/odoo#65331
Taskid: 2449312
X-original-commit: c324c024d4c5e013b2405b509e91337bd3dc4dc7
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
Before this commit, when the user with no access right to Timesheet App
wants to see the tasks in a project and sale_timesheet module is
installed, the user has a traceback saying remaining_hours field is not
find in the parent view of
`sale_timesheet.view_task_form2_inherit_sale_timesheet`.
This traceback is raised because the
`hr_timesheet.view_task_form2_inherited` is not used if the user has no
access right to Timesheet App and then remaining_hours field is not
defined for this user because this field is appeared in the view in
hr_timesheet module.
This commit revises the views inherited from the project.task model to
give the user without access rights in Timesheet the possibility to see
the tasks in any project he can see.
opw-2429662
closesodoo/odoo#65000
X-original-commit: d63614035c84d0c0ab564102c65541d1b2b08277
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit, dropzones were created around invisible elements
(e.g. the snippet popup). So we had 2 dropzones instead of one at some
locations.
After this commit, we avoid creating dropzones around elements that
must not have dropzones.
task-2312878
closesodoo/odoo#65230
X-original-commit: ad56d50e3da000cacdc70d9230cad308d03680bf
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Create a product with variants attributes that NEVER create variants.
Configure Variants to add some extra-prices to some variants.
In POS settings activate "Product Configurator" and
"Advanced Pricelists", add the public pricelist and one that applies 5% to
the product.
Open a session and select the product created (say price = 1$)
Select the attributes, the extra-price is added to the product (say the
total price now is 2$).
Change pricelist from public to 5% and the order line will show our
product = 0.95, not taking the extra-prices into account (so not 1.9,
i.e. 5% of the 2$ that were formerly displayed)
opw-2439445
closesodoo/odoo#65222
X-original-commit: 323d2937f1470a85ba9ee5e46595baef426ee3f3
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Before this commit, the only way to add an event was using a long tap.
After this commit, a short tap will be added.
So to summarize on Mobile there is two methods to add an event using the
calendar: short tap and long tap.
For month/year views when a user tap on a "Free Zone" (no event)
the view is changed in the "day view" for this clicked day.
Task ID: 1891957
closesodoo/odoo#64615
Related: odoo/enterprise#15785
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit add the support to simulate a "TAP" (touch) using coordinate.
This utils will be used in a future commit in web_enterprise to be able
to test some specific case for FullCalendar.
Task ID: 1891957
Since commit odoo/odoo@ebce7719b6
the disableQuickCreate parameter was lost during the process.
Note: there is no steps to reproduce as this feature was never used.
Related Task ID: 1891957
Office Outlook doesn't take into account the [style] attribute, and it
doesn't manage width/height in percent value.
This commit set width/heigth attribute in pixels and also always set the
width/height in style attribute (keeping them in the original unit and
setting them to auto if not present).
This is a reintroduction of 2015 commit bdf58adb46
opw-2447756
closesodoo/odoo#65218
X-original-commit: c51762a790d6fefd97e6c818bfaa9307180dd5b5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
By making this tree non-editable, clicking on the rows opens the
corresponding form, and gives access to more information and better
navigation.
closesodoo/odoo#65214
X-original-commit: 995bcf5a96fc1ae2be1ddccbf3a8eb7ba42c923c
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Currently, Chrome show a scrollbar when the placeholder is multilined.
Overflow hidden will avoid the scrollbar and we place a nowrap on the
placeholder text to avoid the multiline.
task-2416058
closesodoo/odoo#65213
X-original-commit: dfbbb18f39f5e546bb8bea34e395bdf1c1b49dab
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Issue
- Install "Contacts" and "Studio" modules
- Go to "Contacts" and switch to Studio
- Go to "Reports" tab
- Create a new report
- Select "External" layout
Header and footer are missing on report.
Cause
Header is displayed if 'company' has a value.
However, here, we only check if 'company_id' is available
in current record fields, not checking if also set.
Solution
Check that 'company_id' is set on current record, else,
fallback on 'res_company'.
opw-2443234
closesodoo/odoo#65210
X-original-commit: 7c4510042ec35a7da10741595a4da56c3b3c4cdf
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
When Odoo is started in worker mode with Python 3.8.5, and
gevent/greenlet installed from requirements, the following error message
is thrown:
`RuntimeWarning: greenlet.greenlet size changed, may indicate binary
incompatibility`
As a gevent developper stated [1] that gevent 1.5 is not compatible with
Python 3.8, this commit bumps the version to 20.9.0 (current version for
the next Debian and Ubuntu releases [2] [3])
This commit should not impact those who use the Debian/Ubuntu packages
of gevent and greenlet. The error does not appear with those versions.
In Ubuntu Focal, the packaged version is 1.4.0 [4] but the problem was
not reported with this version and python 3.8.
For reference, it was bumped to 1.5.0 for Python 3.7 in [5].
And greenlet was bumped too for issues with Python 3.8 and 3.9 in [6].
As a result, the requirements for greenlet/gevents gains even more
complexity and should be cleaned when python 3.6 support will be
dropped.
[1] https://github.com/gevent/gevent/issues/1260
[2] https://packages.debian.org/bullseye/python3-gevent
[3] https://packages.ubuntu.com/hirsute/python3-gevent
[4] https://packages.ubuntu.com/focal/python3-gevent
[5] odoo/odoo@bb0b32bd1a
[6] odoo/odoo/@648635deca67df09417ae55c6eb181c98524b74d
Fixes#64106closesodoo/odoo#65180
X-original-commit: 1622aa755bb67e2d9e6efd18366be49b8e4783cb
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Prior to this commit:
* All employees were treated the same way regarding the contractual point of vue.
From this commit on:
* Three employee types will be created:
- Employee, which is supposed to be under contract
- Student & Contractor which are both not supposed to have an employee contract (but are still use the employee as working for the company)
* Employee view and Contract History will take this consideration into account.
closesodoo/odoo#64931
Taskid: 2446000
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
As we were introducing changes in web_grid (enterprise) we realized that no documentation
on the grid view was yet available in the community documentation. This commit moves the
the existing documentation from enterprise to the community doc repository and adds the
new attributes introduced in the realte enterprise PR.
task-2271628
Closes#65081
Related: odoo/enterprise#12127
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Follow-up of 13a4544707053295565c33580526f6a8a16f556b
Where we fixed the portal *list* of opportunities but did not notice that the
associated *form* also had the same issue.
To recap the issue:
When you remove the 'company_id' on a crm.lead, you also remove the computed
'company_currency'.
When trying to view this kind of leads in the website_crm_partner_assign portal
form page, it would raise an error while trying to display the planned_revenue
in the missing currency.
Now, we display the number without any currency sign, which is a "best effort"
solution, just the same as on the crm.lead form view.
So it will look like "9000 at 47%" instead of "$9000 at 47%".
Task-2444539
closesodoo/odoo#65199
X-original-commit: c3007ac621d95ee487560a95eeaf925b56c01ab7
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
- Go to Accounting (module)> Accounting (menu) > Journal Entries
- Create a new account move M
- Remove the default journal
Bug:
Impossible to set a journal
opw:2445553
closesodoo/odoo#65200
X-original-commit: cd1823a1066dd9a820afed8427e3a9abc2faade0
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Christophe Monniez