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
Steps to reproduce the bug:
- Create a user U with manager inventory access rights and no right in sales
- Create a SO and validate it, it will create a picking P
- Lock the SO
- Log with U and try to print the delivery slip of P
Bug:
A access right error was raised.
opw:1878504
If we do:
- one change that will be saved in history
- go back to the document before any change
- do other change
we can easily get in a state were the history is no longer recorded.
The history is kept like this:
- pos: our position in the history
- aUndo: the snapshots of history
- toSnap: the last history snapshop that is to be saved
so for example if we start without change (at originalState):
{pos: 0, aUndo=[], toSnap=null}
Then we do two changes (change1, change2):
{pos: 2, aUndo=[originalState, change1], toSnap=change2}
If we make an undo, we will get to:
{pos: 1, aUndo=[originalState,change1,change2], toSnap=null)
If we make another change (change3):
{pos: 2, aUndo=[originalState, change1], toSnap=change3}
So the history after the position is removed.
But when we get back to the original, the state would forever be:
{pos: 0, aUndo=[originalState], toSnap=change85}
because when doing a change, the code only removed history from the
max(pos, 1) index.
opw-1870119
closes#26701
In the editor in a table cell, when we press UP/DOWN keys:
- we have default editor/browser behavior if there is content before
(UP) or after (DOWN) the element we are currently on
- else we go to the previous (UP) or next (DOWN) row if available
- else we go to the next content if available
- else we have the default editor/browser behavior
But when checking if there is an element before/after the content, we
did not take into account if there was an ancestor node inside the cell
that had content after, so for example with this structure:
```
<table>
<tr><td>
<p>hello <b>world</b></p>
<p>cruel</p>
</td></tr>
<tr><td>
<p>bingo</p>
</td></tr>
</table>
```
if the current range was on 'world' text node, we would just check if
there is content after this text node, not if there is content after its
`<p/>` ancestor.
Before the fix we would get on the next row, after we would have default
editor/browser behavior: ie. if cruel is on another line, going to this
line.
opw-1870119
closes#26701
Be in a grouped kanban view with progressbar with limit 10:
- records 1 to 10 are loaded on a column
- do "Load more..." on a column => records 11 up to 20 are loaded
- do "Load more..." 2nd time => records 11 up to 20 are loaded
- do "Load more..." 3rd time => records 11 up to 20 are loaded
- ...
While in reality it should be:
- do "Load more..." 2nd time => records 21 up to 30 are loaded
- do "Load more..." 3rd time => records 31 up to 40 are loaded
- ...
This was caused by the progressbar reloading the column's group. This
set the loadMoreOffset to 0 thus forgetting the current state.
Without the change, added tests failed with:
records of column are loaded => actual: "1,2,2", expected: "1,2,3"
opw-1878359
closes#26628
Suppose you select a customer for a sale order.
You type the beginning of his name "think", and a name_search is triggered
which finds matching results, with first result "Think Big Systems".
There are three ways to select it: click, enter or tab.
Now there can be a warning set on this customer
("Bad client, only accept cash", or "good client, offer discount").
In that case, clicking on tab would trigger the onchange displaying the warning,
but it would also set floating to true, which means a dialog to create client
"think" would appear.
This happens if the onchange is delayed, and thus the call to reset the floating
state is triggered only after the focusout completed, instead of before.
Coauthored with @aab-odoo
opw 1866619
opw 1874475
With a fixed price delivery method, the error message was not displayed when
the address doesn't match.
Inspired from function base_on_rule_rate_shipment
The error message was not clear enough.
opw:1879204
This commit fixes two bugs:
- a8469c45 was fixing the case where the first line was not 'code' but broke
the usecase where a po started with code line
- Correct the usecase where a pot and po file do not have the same line of code
by matching on res_id=0
This avoids to have a pot expecting a code message at line 42 and a translation
at line 43
Closes#26722
Overwrite vendor reference only if there is a PO linked to the bill.
Otherwise, any addition of product will erase what the user just typed.
Closes#26734
The pivot view didn't take into account the widget set on the fields.
In particular this was a problem for float fields that store time values.
They are now displayed with float_time if declared as such in the view.
opw 1876445
`firstName` and `lastName` should be filled in for Australia, but the
implementation is not correct since:
- it assumes that the name is first name + last name, which is not the
case in all countries (e.g. France)
- it doesn't take into account that the name could be a company name
This reverts commit 26974d4e5f.
Goffin Simon