CORS error was firsly fixed with 4bd8e3e2ed in 11.0
Then it was cherry-pick'd and improved in 10.0 with 9f1438d5f1.
But the improvement was lost during forward port from 10.0 to 11.0.
This commit adds the lost fix.
Closes#26812
Commit d25719cd use in website_sale the field sale_delay defined in stock and
so only available with the module bridge website_sale_stock only.
After this commit, website_sale without stock works again.
This commit closes#26855, closes#24671
Before this rev., there was a crash when a FieldDomain was reset
with a new domain (e.g. coming from an onchange). For instance, it
crashed in Email Marketing > create new Mass Mailing > select
mailing lists. Introduced by 68332a01.
opw-1882850
Following CDN expansion (d98b262398)
portal attachment links now go through the CDN, which is an issue for
restricted-access attachments e.g. attachments bound to specific objects
(such as support tickets).
Add an access token to the attachment links in the /my/task template.
Cf OPW-1882014 (fixed ad-hoc by editing the relevant view on odoo.com)
…eduler"
Steps to reproduce the bug:
- Let's consider P a product with routes "buy" and "mto" and with
purchase_requistion = 'Propose a call for tenders'
- Let's consider a BOM B with P as component
- Create a MO for B
- Run the scheduler two times
Bug:
Two purchase agreements have been created for the the same MO.
opw:1882280
- Set up a tax as 'Based on Payment'
- Create an invoice at date D with this tax
- Pay the invoice at date D+1
- Unreconcile
A reversal entry is made at the current date, while it should be at the
payment date D+1.
We make sure to use the payment date only if the payment period has not
been locked.
Fixes#25738
opw-1870467
When bundle contains both, sass and less, the unlink on old_attachments
will be called twice and thus results in MissingError.
This commit closes#26110
Since march 2015, using in a domain "relativedelta(months=X)" with
X being bigger than 11 or lower than -11 would result in an error.
This is because in the refactoring adding modules (e8a00bc50d) the two
functions divmod and utils.divmod with different implementation in
pyeval.js were replaced by one function divmod in web.utils module.
But there was still an usage of the removed implementation.
opw-1880766
closes#26816
Let's consider a product P with a sale_delay = 10
When creating a SO for P in the backend, the customer_lead is correctly
set to 10. But when creating a SO in the shop for P, the customer_lead
was not correctly set.
opw:1880577
Due to this commit: b367625248
The function "_get_payment_type" was not defined in module "sale_payment" but defined in "website_quote"
The bridge module for "website_quote" and "sale_payment" is "sale" so the first definition of "_get_payment_type"
must be in "sale".
opw:1881990
Steps to reproduce the bug:
-Go to Sales > Dashboard > Point of Sale > Settings
-Set nothing as group_by value
-Go back to Dashboard
Bug:
A traceback was raised.
opw:1881444
The resequence mechanism works if the sequence is sorted by its handle field.
Therefore sorting on another field should lock the handle, while sorting on the
handle field should unlock the handle.
opw 1867049
When two transactions conflicts (eg. deleting same data, see [1]) Odoo
will retry the whole transaction several times hoping for the best.
But when rendering template, the error handling would prevent this
feature. For example a recurring issue was:
- loading quickly two times the /web route
- for each recompute the assets
=> this could lead to 2 concurrents transactions that would delete
previous same attachment (ie. DELETE FROM ir_attachment where id=3).
With this changeset, when getting a template fails because of a
transaction rollback, we let the issue bubble up so our retry system is
used.
So instead of a "500 Internal Server Error" page and in log:
bad query: b'DELETE FROM ir_attachment WHERE id IN (3)'
ERROR: could not serialize access due to concurrent update
"GET /web HTTP/1.1" 200 -
"GET /web HTTP/1.1" 500 -
... big traceback ...
load could not load template
we would get the requested page without error and:
bad query: b'DELETE FROM ir_attachment WHERE id IN (3)'
ERROR: could not serialize access due to concurrent update
"GET /web HTTP/1.1" 200 -
SERIALIZATION_FAILURE, retry 1/5 in 0.8920 sec..
"GET /web HTTP/1.1" 200 -
As a side node, the issue was exacerbated in some instances:
- when running a database on another server: assets are recomputed
- when a module was installed/uninstalled: assets may are recomputed
- when updating the source code: assets may be recomputed
- when starting server: requests could be stacked waiting for readiness
- when using google chrome: the "Use a prediction service to load pages
more quickly" option may load a page two times. for example:
-> an URL is entered in address bar
-> a prediction request to it is started URL
-> go to this page (Enter) when that request is not already resolved
-> the prediction request is cancelled and a new request is started
[1] https://www.postgresql.org/docs/9.6/static/transaction-iso.html#XACT-REPEATABLE-READ
note: 10.0 backport of 11.0 #26778
opw-1849167
closes#26785
When two transactions conflicts (eg. deleting same data, see [1]) Odoo
will retry the whole transaction several times hoping for the best.
But when rendering template, the error handling would prevent this
feature. For example a recurring issue was:
- loading quickly two times the /web route
- for each recompute the assets
=> this could lead to 2 concurrents transactions that would delete
previous same attachment (ie. DELETE FROM ir_attachment where id=3).
With this changeset, when getting a template fails because of a
transaction rollback, we let the issue bubble up so our retry system is
used.
So instead of a "500 Internal Server Error" page and in log:
bad query: b'DELETE FROM ir_attachment WHERE id IN (3)'
ERROR: could not serialize access due to concurrent update
"GET /web HTTP/1.1" 200 -
"GET /web HTTP/1.1" 500 -
... big traceback ...
load could not load template
we would get the requested page without error and:
bad query: b'DELETE FROM ir_attachment WHERE id IN (3)'
ERROR: could not serialize access due to concurrent update
"GET /web HTTP/1.1" 200 -
SERIALIZATION_FAILURE, retry 1/5 in 0.8920 sec..
"GET /web HTTP/1.1" 200 -
As a side node, the issue was exacerbated in some instances:
- when running a database on another server: assets are recomputed
- when a module was installed/uninstalled: assets may are recomputed
- when updating the source code: assets may be recomputed
- when starting server: requests could be stacked waiting for readiness
- when using google chrome: the "Use a prediction service to load pages
more quickly" option may load a page two times. for example:
-> an URL is entered in address bar
-> a prediction request to it is started URL
-> go to this page (Enter) when that request is not already resolved
-> the prediction request is cancelled and a new request is started
[1] https://www.postgresql.org/docs/9.6/static/transaction-iso.html#XACT-REPEATABLE-READ
opw-1849167
closes#26778
Steps to reproduce the bug:
- Create a contact without a parent company and set a country on it
- Link this contact to a parent company that has no country defined
- Create an invoice for the contact
- Go to Accounting / Reporting / Management / Invoicing, switch to Pivot view and group by country
=> the invoice for the contact is classified under "Undefined" even though it actually has a
country set when you go see the invoice
opw:1878819
- Create 2 pricelists A and B. Pricelist B relies on A.
- Make B available in the POS, but not A
- Start a POS session
The user faces a black screen without any information on the error.
We add a simple alert so that the user knowns the source of the problem.
opw-1874397
In Employees views, selecting New Hired filters leads to an access error
with a simple user.
With this commit, this filter is limited to the corresponding users
group.
Backport of 804b9b7c5e
The res.users class contains special fields that bypass access rights.
These are designed to allow a user that does not have the possibility to write
on res.users to modify their own fields, such as the mail signature.
Create and write are overriden to make it so, however the check_access_rights
isn't.
Since this method does not work at field level but at model level, there is no
easy way to resolve the incoherence.
Uploadding an image to a signature would add an attachment to the signature;
before being created, an attachment checks if the user has the rights to write
on the target model. The incoherence thus make it fail.
We add a special case when creating an attachment so that a user can write on
itself.
opw 1871243
- Activate lots and SN
- Go to Inventory > Inventory Adjustments
- Export a record
- Select the field 'Inventories > Lot/Serial Number'
The `name_get` of the field is exported, not its XMLID.
This is because the parsing made in order to limit the depth of export
is made on the label, not on the field name.
Actually, it is not clear WHY this limitation exists, but we keep it for
compatibility purpose.
opw-1877092
When a column is created in the kanban view, the context of the window
action is fully given but it may contain default_{field_name} context
keys that are intended for the action model.
eg. on a product.product view we could have {default_type:'product'} in
the context, if we grouped by company_id and created a new company, we
would the context is propagated and we would try to set type='product'
on the company (which causes an error).
Without the change, the added test fails with:
default_* should be removed from context, actual: "true", expected: "false"
opw-1879064
closes#26676
Steps to reproduce the bug:
- Let's consider the today date = D
- Set on your preference a timezone which has another today date = D+1
- Go to CRM > Configuration > Activiy types > Call
- Set 0 as # Days
- Go to CRM > Pipeline > Click on a lead
- Schedule an activity of type = Call
Bug:
The Due Date = D instead of D+1
opw:1877217
When an inline editor is eg. in a form view, the focus is always stolen
by it.
This is because we trigger a mouseup on the editor to update its
toolbars values and informations.
In 10.0 this was not necessary since the default values were sanely set
when the editor was inside the DOM. In 11.0 the editor is not in the DOM
when this is being done and the info was wrong (eg. NaN for text size).
With this commit, we don't steal the focus and get the default like it
was done in 10.0 instead.
fixes#26366
opw-1874880
closes#26582
Romain Derie