If the database name contains one of the tested strings, it can render
the assertion of the test invalid or inconclusive. Ensure we strip it
away during the tests.
opw: 1957055
closesodoo/odoo#31987
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this patch, the ir.logging's write_uid field was a many2one which
could cause a module install/update to hang when the module is changing
the res.users model schema and when this module causes to orm to warn
through the logger. (eg: declaring two res.users fields with the same
string attribute)
In such situation the transaction cursor that is processing the
res_users table alteration will be granted an exclusive postgresql lock
hence causing the ir_logging insertion to block because of the write_uid
foreign key to res_users.
This issue has never been raised by runbot as it is using a remote
database with --log-db
Note: the write_uid conversion from m2o to int was left over in commit e6a5d82closesodoo/odoo#32015
Signed-off-by: Christophe Simonis <chs@odoo.com>
Avoid potential tracebacks from the FSWatcher's thread being killed.
Drawback: Server shut down can have an extra small delay
(only applies when the --dev=reload option is given)
closesodoo/odoo#31855
Signed-off-by: Christophe Simonis <chs@odoo.com>
Add the alternative of inotify instead of watchdog to watch the addons
paths the server was started with.
Reason: watchdog spawns 2 threads per path to watch. When there are a
lot of addons paths, this can become too costly. With inotify we watch
all the repositories in a single thread.
https://github.com/dsoprea/PyInotify
installation:
pip install inotify
We set the default rate to be 1.0 instead of 0.0, since a rate of 0.0
doesn't make sense.
Partial backport of 298491597c
opw-1949866
closesodoo/odoo#31866
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit iteration in a t-foreach containing null or
undefined values crashed because they have no attributes.
closesodoo/odoo#31828
Signed-off-by: Fabien Meghazi <amigrave@users.noreply.github.com>
- When creating a user from the "Grant Portal Access" wizard, the code
checks for duplicate users.
It does so by checking if there is a user with the same login as the
one we want to create.
The check is case sensitive which could lead to issues.
For example a mistyped email (with a uppercase somewhere) could fail
the duplicate user check.
Since emails are not case sensitive, we want the check to be case
insensitive too.
OPW-1932918
closesodoo/odoo#31818
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
This is related to issue #31549, fixing it in 10 since it's already a
minor issue here (importing 500 partners which all have the same parent,
on my system the import time goes from 2:30 to 2:00).
This is mostly a problem for such fields as `property_product_pricelist`
(added do the commercial fields list by `product`): since we're first
getting it then writing a field it depends on (updating the address,
which contains the country), the field gets invalidated for all records
on each record being imported, so if we're importing a bunch of partners
which all have the same parent (e.g. company employees)
`property_product_pricelist` is going to be re-computed for every
partner imported so far as well as the one parent we're interested in,
for every new partner we're creating.
The problem is much more prevalent with 12.0's batched creates as we're
first creating all the new partners then doing the updates, and thus for
each new partner we're computing `property_product_pricelist` for all
new partners and the one parent we're interested in, roughly doubling
the import time of a series of partners which all have the same parent.
closesodoo/odoo#31804
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Sequel of cc54194e13.
The mentioned fix only worked when the user was public.
The problem arises when calling the function `_get_fpos_by_region()`
in `sudo` without specifying the company and this happens, for instance,
in every `onchange_partner_*` function of a sale order.
We propose to add the `force_company` key in the context of the sale
order to ensure the right company when selecting the fiscal position.
closesodoo/odoo#31751
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
- Fixes incorrect user type assignments on some accounts
- Fixes incorrect account assignments on taxes
- Adds a few accounts that Japanese companies would typically need
- Changes some account codes to make the structure more consistent
- Updates descriptions of some taxes to make them appear more natural
on PDF reports
closesodoo/odoo#30780
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When creating a cart on the website, the website company was not
considered which could end up with the selection of a fiscal position
linked to a wrong company since the method is called in sudo.
closesodoo/odoo#31673
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
To avoid exception:
TypeError: Mixing apples and oranges: gamification.badge() - gamification.badge.user(1,)
when rule_auth of a badge is set to `having`.
opw-1945440
closes#31436closes#31595
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Since https://github.com/odoo/odoo/commit/5a030db3eb77b6d80187f8ae1a64303b2f50391d
the HTML editor displayed the translated versions of the templates it
allows to customize. So if the user edited and saved such a template,
the non-translated version was saved with translated-version content.
The behavior before the mentioned commit was:
1) Load all views the HTML editor allows to edit
2) Each time a view is displayed, re-make a RPC to load the view again
The mentioned commit made this simpler by making:
1) Load all views the HTML editor allows to edit
2) Each time a view is displayed, simply show the previously loaded view
... the problem was that the step (2) of the old behavior was
explicitly saying (client-side) to load the view's untranslated content.
This commit makes step (1) always load the untranslated versions of the
views (server-side).
Werkzeug version was being checked to avoid passing quote=True to
werkzeug.utils.escape (as that parameter was changed to `True` *and
deprecated* in 0.9).
However because DeprecationWarning was made silent by default in
Python 3.2 and the way the check is implemented worked for 0.9 it
looks like nobody really noticed it's broken in the usual manner of
half-assed version checks: works for 0.9.0, doesn't work for
0.12.3 (because lexically 0.12.3 < 0.9.0).
Fix by using proper version parsing and comparing the result of that.
See also: odoo/odoo#28116closesodoo/odoo#31553
Signed-off-by: "Xavier Morel (xmo)" <xmo@openerp.com>
The location_id and warehouse_id fields on product.template are just
dummy field intended to add something in the context that will be used
to compute the data being rendered (eg. for location, the quantity
displayed is the quantity of the product in the searched location).
But the feature was broken at a point, and has been solved in 11.0 with
7c7b099273.
This solution was not implemented in 10.0 up to saas-15 since this is
not acceptable for a stable version.
This changeset is only for 10.0 up to saas-15 to implement the fix
differently.
opw-1945417
closes#31475
Improve performance (*3) on _compute_product_availability
`mapped` makes use of orm prefetch, which is inefficient in this use
case when facing high volume.
closesodoo/odoo#30545
On some devices and chromium with printing option "Background graphics",
a printed receipt on the point of sale could have a black bottom below
the receipt content.
This is caused by the point of sale black background and happen rarely
because most frequently browser printing remove backgrounds.
opw-1940434
Co-authored-by: Romeo Fragomeli <rfr@odoo.com>
closes#31472
Before this commit, doing expression.OR() with only FALSE_LEAF would
yield [] which is equivalent to TRUE_LEAF and is therefore not correct.
The same happened (to a lesser extent) with expression.AND() within an
expression.OR(), since the former would return a [] which would be
ignored by expression.OR().
See tests for a clearer view of the use cases.
Fixes#30113, #26540closesodoo/odoo#31202
The admin can decide to publish/unpublish messages in the comments
of a product from the website. The button is also shown for notes
even if they are never published.
opw-1935337
closesodoo/odoo#31420
When importing an invoice without specifying the type, the invoice type
is set to `out_invoice`, but the account set is the supplier account.
At this point, the invoice type is simply undefined (`False`). It will
be set by default at creation to `out_invoice`. Therefore, we reach the
`else` condition which uses the supplier info.
We simply inverse the condition, so it creates a consistent object.
However, it raises a bigger question about how the action context should
be kept at invoice. We won't address it :-)
opw-1925547
closesodoo/odoo#30154closesodoo/odoo#31373
- Switch to French language
- Go to Inventory > Inventory Adjustment
- Launch an adjustment
The field 'Real Quantity' doesn't follow the float formatting.
This is because the widget is set as `field_float_scannable`, which is
not recognized by the formatting function.
Since the widget descriptor has priority over the type descriptor, we
must explicitly take this widget into account, on top of adding the
`format_value` method.
opw-1940884
closesodoo/odoo#31366
In Odoo, create a user John@example.com (the cap is on purpose)
In Google Calendar, create an event and invite john@example.com
Sync your Google calendar.
Before this revision,
the event created in Odoo did not add John@example.com,
but created a new attendee, john@example.com, because
of the sensitive casing.
Besides, give the priority to partners having
users, so if there are two partners with the same email,
one of them having a user,
e.g. John@example.com (with user) & john@example.com (without user),
set the partner having the user as attendee,
as its the one with the user who use the Odoo calendar,
and potentially the Google sync as well.
opw-1925592
closesodoo/odoo#31111
Before this, groups on non-stored inverse fields were not checked upon write.
The impact on existing fields is pretty small, since the inverse methods of
those fields are subject to access rights on the records they use.
closesodoo/odoo#30356
This is the first step to a more comprehensive handling of company-dependent
fields which are ir_properties.
With model-specific access rights, users should be able to read/update a
company-dependent field no matter their access rights on ir_property.
Before this commit, a user having access to res.partner, but not to ir.property
couldn't write on property_account_receivable/payable just because he couldn't
write the corresponding ir.property. After this commit, he can.
OPW 1923345
Christophe Simonis