Before this commit, we waited for 10 seconds before defining the
boot test (checking that all JS modules have been correctly
loaded). However, small test suites (like the mobile one) ended
before this test was defined. So we could end up with a green
branch with tests not being executed (e.g. if a testing module
had missing dependencies, and was part of a small suite).
This commit removes the boot tests and instead does the check
at the end of the suite, before logging that the suite passed.
closesodoo/odoo#50109
X-original-commit: 048557eef32df94715ab464614c9d9d34c4a2689
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since a0f9ef56, a _vendor module was added without `__init__.py` file,
following the PEP 420 specifications.
Unfortunately, as the `setuptools.find_packages()` only recognize
packages if they have such an init file, the _vendor module is not
packaged. This leads to an import error when running Odoo from the
src,deb and rpm packages.
The `setuptools.find_namespace_packages()`, which is compliant with PEP
420, could have been used instead. But this function does not exists in
setuptools 39.0.1 which is the one packaged in Ubuntu Bionic.
Finally, this commit simply adds the missing dunder init file.
closesodoo/odoo#50051
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
With this commit, module operations such as install, upgrades and
uninstalls are henceforth forbidden inside unit tests and instead such
tests must be performed with standalone Odoo scripts.
This is done because module operations during tests are not
transactional, this can leave the registry in an unclean state and
further tests may be affected by this, it also creates a new registry
which complicates registry cleanup if anything crashes,
because the registry to be cleaned up is not the same one that crashed.
Instead, what should be done is a script that imports odoo as a library,
and loads the database necessary then performs whichever operations
necessary. This script should contain a single function with a single
parameter (env) and should be decorated with
@odoo.tests.common.standalone in order to be executed properly, this
decorator accepts any amount of positional parameters as tags that can
be specified when calling the script in order to execute only a select
subset of scripts.
Special tags are: 'all' and <module_name>, these are generated
automatically, the first will execute ALL scripts available whereas
<module_name> will execute all scripts introduced by said module.
When calling the test_module_operations script, only scripts found in
*installed* modules will be executed, script discovery is only possible
if the code is loaded therefore it is only possible if the module is
installed.
closesodoo/odoo#49669
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
- Create 2 companies C1 and C2
- Install any module with access rules, e.g. `account`
- Create an invoice in C1, attach a document
- Switch to C2
- Go to Settings > Technical > Attachments
An `AccessError` is raised.
This happens because the `_search` skips the ACL and record rules for a
system user, while they should only be skipped for the superuser.
opw-2236561
closesodoo/odoo#50067
X-original-commit: 9a71d60c25804bc4bae8c2c680c537f8a7a0900f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The route is no longer used but was still present in the code.
Processing email should be the job of the fetchmail server and they
should not be injected directly from outside (even if emails are
unauthenticated by design, mail servers may still have some say in the
process).
Courtesy of Alexandre Díaz
closesodoo/odoo#50084
X-original-commit: ab70afb3963b0952e938ab39ef3dcb47ecc01f61
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The buttons created in the reconciliation widget by the reconciliation models did not apply the percentage of their lines correctly.
Example of the behavior before the fix :
1) Create a 'writeoff_button' reconcile model, with two lines of 50% on distinct accounts
2) Create a statement line of 100€
3) Open the reconciliation widget and apply the model created in 1) to the line made in 2)
=> Two lines are created, 50€ and 25€. They should both be 50€.
closesodoo/odoo#49963
X-original-commit: d3bd67fa12d85515fa6683f7b5d9ae114056bb62
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
When the newsletter popup was introduced, the modal was for some reason
marked with the o_editable class, which is normally used to let the
editor know which elements in the page can be edited and saved in the
database. Because of this, upon saving with the modal in the page (ie,
if the modal is open when saving) it would try to destroy the editor
associated with the modal, which doesn't exist, resulting in a
traceback.
This commit fixes that by removing the o_editable class from the modal,
this doesn't actually prevent edition, because the modal is already
inside of an editable segment of the page.
task-2092593
closesodoo/odoo#50080
X-original-commit: 856d21cef530a9393bcebbf314a9316934ffb7c7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
On an instance with 4 million messages, opening Settings > Technical >
Messages could increase residual memory usage in a given situation usage
by:
- 1.5 GB for odoo
- 3 GB for postgresql (a part might just be cache depending on config)
With this change breaking the request in several ones, increase is:
- 0.5 GB for odoo (for the millions of ids in dictionaries and list)
- 0.1 GB for postgresql
opw-2232065
closes#49689closesodoo/odoo#50079
X-original-commit: 04e5b9f397e7fc752e9910c58eea589420b83a63
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Previously, if you opened the cropper on an already cropped image, it
would load the crop data for that image. If you then changed the image
and cropped that new image, it would keep most of the metadata of the
previous image when saving, causing any subsequent crop to show the
previous original image instead of the current one.
This commit fixes that by removing all crop-related jQuery data from the
image, so it's considered a fresh crop and a new attachment is created.
closesodoo/odoo#50066
X-original-commit: 46c08050998d0c94d8955cd23ac783f38ecb5af1
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, some elements in the control panel were not properly encapsulated
in layout-related parent elements and this caused some inconsistencies if some of
the control panel components were not displayed. For example: if the breadrumbs
were missing, the search bar went to the left side instead of the right.
Now, all components are in a grid-like structure (in desktop mode) and should not
overstep their given boundaries. The layout in mobile remains unchanged since the
top part behaves quite differently.
closesodoo/odoo#50057
X-original-commit: 533db5991a5bb871198485cd71a63f75a8c6becf
Related: odoo/enterprise#10148
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Steps to reproduce:
- install website, crm
- go to crm > settings > activate leads
- add a contact form to your website and submit
- go to the created lead
Previous behavior:
state_id is shown as false when geoip data is empty
Current behavior:
state_id is not shown if geoip is if the state found in geoip
does not not exist on the Odoo instance
opw-2218498
closesodoo/odoo#50055
X-original-commit: eba0eafac78adb498f8062f3490cea0847ed7927
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
- Go to Accounting
- On Customer Invoices kanban card, click on the 3 dots > Credit Notes
Invoices, credit notes and receipts are shown.
This happens because the action domain is overridden, while it shouldn't
be in this case.
We only set the action domain if the action name was not explicitly
requested.
opw-2242195
closesodoo/odoo#50052
X-original-commit: 5dab4d56055cc197fb0f3a6cd20e60cd0f638fa9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Restore the position of the icons in the top options so that they are
aligned horizontally and no longer vertically.
task-2162952
closesodoo/odoo#50021
X-original-commit: e4fcba353804d2be079b16aaad7dbe94b884e156
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Hide the button used to display the input and show the input
directly. Add a search icon into the input. Deactivate the browser
autocomplete. Improve and fix the layout. Keep the field selected
after choosing a result from the list.
This commit was only about making it work in the 13.0 left panel. It
will be improved further in master with our new left panel.
task-2187712
closesodoo/odoo#50024
X-original-commit: 6660ee960a3c643ae92448d7bdc37f6c780605b6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Do not set a default `account_id` for section and note lines. Indeed,
when set the constraint `check_non_accountable_fields_null` will raise.
opw-2241575
closesodoo/odoo#50040
X-original-commit: 997a98d2d3d12caf554040922876164040de9efa
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Issue
- Have 2 company
- Install Timesheet, Accounting, Project
- Enable analytic accounting
- Accounting > Settings > Analytic accounts
- Remove the company_id of one of them
which is linked to a project
- Timesheet > add a line for this project
Error
Cause
Timesheets lines are linked to a company and a project
Removing the company_id of the project's analytic
account create an inconsistency
Solution
Prevent changing the company_id of an analytic account
which is linked to a project.
OPW-2233266
closesodoo/odoo#50039
X-original-commit: 4895fb5029f492faf31b28b648e56ded8b3a83fb
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Follow-up of f1e79c74a5c07d6be3154629f6f381ebaf907fb1
The issue still arises with:
8 % 1.6 = 1.5999999999999996
The modulo operator on float doesn't seem reliable for our use case,
therefore we use a combination of `float_round` and `float_compare` to
verify the quantity sold is a multiple of the quantity per package.
The rounding threshold is 0.01, meaning that the warning might not be
raised for some specific configurations. For example, 8.005 units with
a package of 1.6 won't return a warning. Since this is a non-blocking
warning, this should be enough for most cases.
opw-2241985
closesodoo/odoo#49983
X-original-commit: 3d48e2b49023eaf1b1dd0c8cb2b7723e41924a38
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Import an italian E-invoice of type TD04 (Nota di Credito).
The invoice type is marked as 'in_refund', but the bank information will
still be parsed from the contact info instead of taking the currenct
company info.
This will fail the check 'validate_partner_bank_id' and
the user will see the error 'The account selected for payment does not
belong to the same company as this invoice.'
Skipping the bank info when we have a credit note
opw-2239652
closesodoo/odoo#49949
X-original-commit: 6b5400b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Let's consider a company C in €
- Let's consider two selectable pricelists P1 in € and P2 in $
- The € rate is 1.0 and the $ rate is 0.5
- Configure a shipping method SM with a fixed price of 100€ and free if the price is
above 1000€.
- Configure a free delivery product P with sales price = 100€
- Go to the shop with P2 as pricelist and add in the cart any product which price is less
than 1000€ (in this case 500$)
- Process your order until the check out
Bug:
The price of SM was 25$ instead of 50$ because the function rate_shipment already computed
the price in the right currency
opw:2239117
closesodoo/odoo#49987
X-original-commit: 68b08164e5de353ea0c48de92d0c0e028b49bc52
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When a user is linked to a contact, the type should not be
modified. Otherwise, the res.partner type may become incompatible with
the res.user record (e.g. is set as a private address and a user no
longer has access to its own user)
Fixesodoo/odoo#48177closesodoo/odoo#48590
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Set the transaction to the state 'error' when Authorize.net responds
with that status, as it will display a message to the customer to detail
the problem.
opw-2231276
X-original-commit: 005607fce4a22394a9f67cc4eaa52f8bf89780f0
Before this commit, when re-activating a previously active notebook tab, the form
renderer would assume that a tab was actually active. However this does not happen
if no tab is visible or defined and it results in a crash instead.
Now, if no active tab is found, a default active tab (0 = first) is set. This only
helps to prevent the crash and does not affect the current behaviour.
closesodoo/odoo#50006
X-original-commit: 73e0c0a1395ebd0e2b4ac7f857c863a0358c5e17
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Adapt gengo to change on translator editor classes and assets.
opw-2234713
closes#49978closesodoo/odoo#50004
X-original-commit: 4dba09388a3ba57f345c2634d7d37e268c6f1198
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In 13.0 66ef641f33 the source field was removed.
This would cause an error when gengo is updating a existing
ir.translation record (eg. if we do two times gengo auto-translations).
opw-2234713
closes#49884closesodoo/odoo#50001
X-original-commit: 527b3bfb2b17a821d6051a9010ec717a62c7c748
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Such a change breaks XML-RPC calls. Moreover, it allows the creation of
partners without the accounts set, which will cause inconsistencies
later on.
This reverts commit 29c362b7c3353c2be11ab117f454d04ed9853f75.
opw-2241875
closesodoo/odoo#49982
X-original-commit: f720602ac24246d29de4919f18ae7c32cce2ffc2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, deleting a stage with tasks, the user received an
error.
With this commit, when deleting a stage containing tasks, a wizard
offers the choice to move the tasks to another stage.
closesodoo/odoo#46410
Taskid: 1869030
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Small bug introduced by [1]: now the website menu is loaded on demand
to avoid useless page loading. This was done when hovering the toggle
which induced two problems: not loaded if the user was already over the
button when the JS is fully loaded and not loaded if the dropdown was
opened via the keyboard.
Also, the 'mouseover' event was used instead of the 'mouseenter' and the
RPC was not checked for already pending ones. Both issues could lead to
have the RPC performed multiple times for no reason.
[1]: https://github.com/odoo/odoo/commit/4206c1f225f5b1c54a0cdd4913e1d8224a2e7889closesodoo/odoo#49986
X-original-commit: 7aebd7d88d1d0a0f81351b8a0e12a03964c8431a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When sale_product_configurator is installed, products created/chosen on
sales order lines are product template and not product.product.
When creating a product on the fly, the context on the product_template_id
field is wrong because applied to the product.template AND the product.product.
Contrary to the automatic creation of a template when a product.product is created (orm-side),
we have custom code in product ensuring that when a template is created, product.product(s)
are created. But this step doesn't clear the context like the orm does.
This means that the default_lst_price=0 in the context won't be applied for the
product.template creation, but will be for the product.product creation:
1) product.template created
2) product.product creation, based on product.template vals
* in the create, the call to _add_missing_default_values will give a
default value for lst_price.
* this will trigger the inverse_related for the field, resetting the
template price.
To avoid this problem, we modify the view to specify list_price instead of lst_price in the context,
because this field will be protected by the orm because it is inherited from the product.template.
closesodoo/odoo#49959
X-original-commit: 42fe38015796b1973245103c877357c14889bacc
Related: odoo/enterprise#10108
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
2 record rules have the same id, which is typo.
opw-2242566
closesodoo/odoo#49938
X-original-commit: cdd0d02a160b10e90c8fc7569ff2ca99ea879f89
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Some more leftover deprecation warnings I missed in odoo/odoo#44164, which turned into errors when Werkzeug 1.0 was released, as well as a few other issues.
closesodoo/odoo#45931
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Werkzeug 1.0 adds a `merge_slashes` feature which calls rule.build()
*during match*[0] (= during dispatch).
However at this point our environment still contains an invalid /
placeholder UID, so `display_name` / `name_get()` fails dramatically.
One possibility would be to update the slugifying to not access the
record (outside of the id) if the environment is not "proper", an
other alternative is to just disable the feature since it seems to not
have been necessary so far.
The latter seems less hacky so do that for now, we can always swap the
solution later if we need to.
[0] https://github.com/pallets/werkzeug/blame/048cdfd9b969c0c3a133d7ff43b8ad1ad6a673ec/src/werkzeug/routing.py#L904
Those were deprecations implemented in 0.15
* all middlewares have been moved from `werkzeug.wsgi` to
`werkzeug.middleware`, including the `SharedDataMiddleware` we use
* ProxyFix was moved to werkzeug.middleware.proxy_fix, this had
already been fixed but I forgot the import
* sessions support was moved to a separate package
(`pallets/secure-cookies`), however while distros are starting to
update werkzeug to 1.0 (e.g. done on Arch, and in Debian
Experimental) they're not bundling secure-cookies so using a
vendored version seems like the least bad thing we can do, even more
so as conditional dependencies are not really a thing (e.g. even
with just pip we can't depend on secure-cookie iff werkzeug >= 1.0)
Steps to reproduce the bug:
- Login with demo user (no accounting app access)
- Go to any product with Update Cost button and try to update it
Bug:
Error message "You don't have the access rights to post an invoice" even if
the inventory valuation was manual.
opw:2240513
closesodoo/odoo#49950
X-original-commit: edc54cdf6d39d7689902903fa637df2a709b4396
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
* remove SessionMiddleware we don't need as it's responsible for most
imports
* fix relative imports to absolute imports from werkzeug
* remove py2/py3 compatibility imports, shims and conditions as we're
P3 only
* remove deprecation warning (duh)
In Werkzeug 1.0, sessions support was moved out and into a separate
package (secure-cookies). Issue is distros are already starting to
update werkzeug to 1.0, without necessarily adding
secure-cookies (e.g. arch, debian experimental). Plus secure-cookies
has some changes e.g. different filename & al. So just vendor the
"continuity" version which is the last werkzeug before removal.
This commit copies the original file as-is so we can track eventual
changes if necessary.
DeprecationWarning was configured as `once` which might be why I
missed some previously: `once` means the *filter* will only signal
once, meaning only one DeprecationWarning gets shown per run. Even if
there are 5 *completely different* warnings getting generated by the
codebase.
`default` should be more suitable, I think I'd originally
misunderstood it as "whatever the default is for this warning" but
what it *actually* means is "print once for each (module, lineno)".
An alternative could be `module` which would show the warning once per
module but wouldn't trigger from different warnings in the same module.
Usecase to reproduce:
- Install stock with demo data
- Go on drawer form view.
- The quantity forecasted and the report for forecasted quantity do not
indicate the same quantity
It happens because the quantity on forecast is wrong. It's due to the
part that select the quants. The condition wh IS NOT NULL remove all
the quants. Also using a not null on a table is probably not a good
practice.
Also complete the request is order to take quants in transit
closesodoo/odoo#49941
X-original-commit: 405522de1f97cfb7571d6096f727a4a2d03561d6
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Aaron Bohy