### [FIX] bus: background slave tabs should not loose notifications
Slave tabs missed some notifications in case the local storage
event's `newValue` did not match actual value in local storage. This
happens when master tab overwrites a value that slave tabs did not
take the time to read. Slave tabs should now always handle all local
storage events.
Task-ID 2044231
### [FIX] bus, mail: correctly synchronize document chat windows
Cross-tab synchronization of document chat windows resulted sometimes
with an infinite loop. This happens due to tabs relying on actual
value in the local storage and all document chat windows state being
set as a single local storage entry. Cross-tab communication of
document chat windows now is relying on event's `newValue`, and each
document chat window has its own local storage entry. Changes from
local storage no longer writes again in the local storage, so that
it no longer makes an echo (= infinite loop).
Task-Id 2034997
closesodoo/odoo#36177
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Steps to reproduce the bug:
- When trying to publish the sips payment acquirer not in debug mode
Bug:
It raised a access rights error because the fields: sips_test_url, sips_prod_url, sips_version
were not readable in function _check_required_if_provider and a default value was set for all
these fields.
opw:2061123
closesodoo/odoo#36346
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit, there could be an infinite loop when changing
the chat window state of a document chat window.
This is caused when mutiple tabs overwrite the chat window state
with a different value everytime, resulting to an infinite loop.
Accross multiple tabs, `setItem` and `onStorage` are not synchronous.
That's why tabs should communicate through local storage events
instead of actual value in the local storage.
To illustrate the issue, suppose there are 2 tabs (T1 and T2) with
one document chat windows (C) and the following user interactions:
- T1 and T2 both have C open
- on T1, user folds C
- on T2, user folds C
Now let's add an example of local storage (LS) logics that could
apply from above example:
- T1 and T2 both have C open
- on T1, user folds C
[1] T1 writes 'C folded' in LS
- on T2, user folds C
[2] T2 writes 'C folded' in LS
[3] T2 detects 'C folded' in LS (from [1])
=> T2 writes 'C folded' in LS
[4] T1 detects 'C folded' in LS (from [2])
=> T1 writes 'C folded' in LS
[5] T1 detects 'C folded' in LS (from [3])
=> T1 writes 'C folded' in LS
[6] T2 detects 'C folded' in LS (from [4])
=> T2 writes 'C folded' in LS
etc...
This scenario could have been easily prevented by not writing on
local storage when the chat window state has not changed. However,
this wouldn't fix this scenario that also introduces an infinite
loop:
- T1 and T2 both have C open
- on T1, user folds C
[1] T1 writes 'C folded' in LS
- on T2, user folds C
[2] T2 writes 'C folded' in LS
- on T2, user unfolds C
[3] T2 writes 'C unfolded' in LS
[4] T2 detects 'C folded' in LS (from [1])
=> T2 writes 'C folded' in LS
[5] T1 detects 'C unfolded' in LS (from [3])
=> T1 writes 'C unfolded' in LS
[6] T2 detects 'C unfolded' in LS (from [5])
=> T2 writes 'C unfolded' in LS
[7] T1 detects 'C folded' in LS (from [4])
=> T1 writes 'C folded' in LS
[8] T2 detects 'C folded' in LS (from [7])
=> T2 writes 'C folded' in LS
[9] T1 detects 'C unfolded' in LS (from [6])
=> T1 writes 'C folded' in LS
etc...
This commit fixes the infinite loop issue:
- by turning local storage read during cross-tab communication into
local storage event read instead. This should prevent race
conditions based on read/write operations in local, since their
order is not guaranteed accros tabs.
- by isolating document chat window state to their own local
storage entry. This should prevent a tab from notifying a chat
window state that it didn't change, which may also result in
an infinite loop.
Some tests were adapted from the changes above. Also, some tests did
pass thanks to local storage being mocked by a ram storage: the
handler `_onStorage` should have been called, but it didn't because
it was registered on the actual local storage instead of the ram
storage. In order to make tests pass again, the following additional
changes were required:
- Cross-tab bus service now exports the unique tab ID with
`getTabId`.
- document thread entries in local storage now track the tab ID, so
that self-tab ignore their own local storage writes.
Task-Id 2034997
Closes#36177
Steps to reproduce the bug:
- Create a MO with a product with a normal bom B
- Save the MO
- Change the type of B to phantom
- Try to produce the MO
Bug:
It was impossible to cancel or confirm the MO.
It's not allowed to produce a MO with phantom bom.
opw:2061958
closesodoo/odoo#36329
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit, some notifications may be lost while forwarding
them between browser tabs by means of the local storage (i.e. from
the master tab to slave tabs).
This happened when some slave tabs are in the background and are
throttled by the browser: the master tab writes twice in the local
storage (to notify slave tabs of new notifications), and slave tabs
drops the 1st notification. This is caused by the mismatch between
the new value in the local storage event and the actual value in the
local storage. For example:
```
t(0) - Master tab receives `message` notification;
t(1) - Master tab writes notifications (= `message`) in local
storage;
t(2) - Master tab receives `message_seen` notification;
t(3) - Master tab writes notifications (= `message_seen`) in
local storage;
t(4) - Slave tab detects new notifications (= `message`)
from local storage event, but drops it since it does not
match actual local storage value (= `message_seen`);
t(5) - Slave tab detects new notifications (= `message_seen`)
from local storage event, and handles it since it
matches actual local storage value (= `message_seen`);
=> Notifications received + handled:
- master tab: `message`, `message_seen`
- slave tab: `message_seen`
=> Slave tab lost "message" notification.
```
This commit fixes the issue by letting all tabs handle any local
storage events, regardless of the actual value in the local storage.
In the example above, this means the slave tab will not drop the
notification `message` at t(4).
Task-ID 2044231
Closes#36177
When editing the followers, the "pencil" icon that leads to the edition
of subtypes should be displayed only when "debug" mode is activated.
This commit restores this behaviour, as it was not the case anymore.
`has_group()` looks for static groups stored in database, whereas
`base.group_no_one` is dynamically added/removed depending on the flag
`debug` of the request.
We thus use `models.user_has_groups()` that adapts on the `debug` flag.
opw-2055848
closesodoo/odoo#36327
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
From calendar create a recursive event and add some guests. Delete one
event of the chain.
Invitations (Mail) will be created for the deleted event, and should not
be the case because the event has been deleted.
This happens because the recursive event is really just a record in the
database representing all the generated events. When the user want to
delete an event in the chain, a new event, copy of the "parent" event
has to be registered and subsequently disabled.
In the process of creating the event the mail is sent as
side effect. Note that the code to prevent this was partially there
because a context flag "dont_notify" is sent by the unlink in
Calendar.Meeting but was ignored from the mail subsystem.
opw-2039576
closesodoo/odoo#36270
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Before this commit, the domain applied to the field
employee_id on hr_expense was wrong, so a simple officer (no other rights)
could not see the relevant people
After this commit, the domain is correct and matches the one on the
officer group's record rule
OPW 2058512
closesodoo/odoo#36292
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, when a message body contains a big image with
inline dimensions, the image was stretched.
For instance:
- `<img width="4096" height="2304">`
- on 1080p screen in the discuss app:
- max-width for image: 1542px
- image ratio: ~ 1,78
- expected height: 867.38px
- actual height: 2304px
This issue had been fixed[1], but was reintroduced[2].
Note that this fix only works when inline dimensions are set as attr
of the `<img>` tag. It won't work with dimensions attached as inline
styles (e.g. `<img style="height: 4096px; width: 2304px;>`), due to
high CSS specificity of inline styles.
[1] https://github.com/odoo/odoo/commit/e7bc4e9703954fa952f24b4f96e75dc4299bbb28
[2] https://github.com/odoo/odoo/pull/15542/commits/46699c5214229ea8aebcc04e08d0786fd2b67f35Closes#36227closesodoo/odoo#36243
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Create a voucher in pay_now mode
set another account that the one of the partner
Validate
Before this commit, the automatic payment and payment entries
were done in the account receivable/payable of the partner
which means that the voucher and the payment were never reconciled
After this commit, the payment and its entries occur in the same
payable/receivable than the voucher's
OPW 2056240
closesodoo/odoo#36232
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
studio
opw2062025
In some cases, when there is no attachment (on an invoice for example)
and reports have been modified with studio, the self.attachement value
is false and an error appears
closesodoo/odoo#36291
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
Fine tuning of https://github.com/odoo/odoo/commit/6236ed1a5b138c5165929aa3f5c1d1f4f6aa061c#diff-2f6cca7f38255368e4a54b0a19406aa4
Steps to reproduce the bug:
- Install Sales and Purchase modules
- Create a user U with access rights to Sales
- Try to open an existing SO or try create one with U
Bug:
An access right error was raised because the non stored field purchase_line_count must be computed
PS: the compute_sudo had no effect on field purchase_line_count because it's a non stored field.
opw:2056746
closesodoo/odoo#36247
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When selling a digital file on the web shop, if the file 'name'
has no extension (e.g. the pdf "Free Booklet"), the buyer
will download "Free Booklet" even when the mimetype is application/pdf).
This causes issues on Mac, as pdf files without extension are renamed
with .dms extensions.
We follow what is done in ir_http's binary_content for the extension management,
using the new one if provided in the name, then the original filename extension
if it exists, and we fallback on guessing it from the mimetype.
OPW 2057302
closesodoo/odoo#36294
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
The fixes that this patch includes are:
- The tag URL for tags printed in short and expanded blog posts had no slug, thus producing a brand new URL. Now they have the slug.
- Any request landed without that slug is slugified with a 301 code, as with the rest of Odoo.
- The `<a>` elements in right column archives have now `rel="nofollow"`.
- The `<a>` elements in right column tag cloud, where more than 1 tag is used, have now `rel="nofollow"`.
closesodoo/odoo#30832
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, when a message contains invalid HTML, it crashed
with error such as: "TypeError: Cannot read property 'childNodes' of
null".
This commit fixes the issue by wrapping the content of messages with
invalid HTML in a `<pre>` tag.
OPW-2048140
closesodoo/odoo#36196
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Fine-tuning 180866fe1e
- Go to Sales > Configuration > Settings
- Enable "Multiple Sales Prices per Product" and select option "Prices
computed from formulas (discounts, margins, roundings)"
- Go to Sales > Catalog / Pricelists
- Select "Public Pricelist" and set "Discount Policy: Show public price
& discount to the customer"
- Add a discount to an event (20 % to "Open Days in Los Angeles" for
example)
- Go to the eCommerce, buy a ticket to "Open Days in Los Angeles" which
as a 20 % discount
Since 180866fe1e the discount is applied
two times.
opw-2058709
closesodoo/odoo#36106
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Fine-tuning of 1da058f8ed, for the same use-case.
The _valid_barcode method is here to bypass the barcode_company_uniq constraint.
The constraint is put on barcode/company couples;
however if checked without a given 'company_id' in the values,
which ends up as False, then the check is actually not the correct one:
the company_id is going to be filled later by the default_get.
Instead we use the value given by the default_get, consistently with the create.
The same error could affect _create_missing_locations,
since it gives an explicit value to company_id that was not passed in values.
We give it to make sure that the company is consistent there to.
opw 2058888
closesodoo/odoo#36102
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Have a product template, assign a dynamic attribute to
(the corresponding variant will be created when used in a SO)
Try to name_search for it
e.g.: in the product configurator modal, type some letters to catch it in theory
Before this commit, the product template was not found by the name search
this is because the template doesn't have any variant yet
After this commit, it is found by the name search
OPW 2060603closesodoo/odoo#36215
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Create a partner with a child *WITH THE SAME NAME*
Create an invoice for the child
Create bank statement and line, with the field partner_name equals
to the child's name (and to its parent)
Open the reconciliation wigdet for that statement
Before this commit, the widget searched lines for the child partner
because partner_name matches the child in priority
Hence the invoice just created was not present
This is because when validating an invoice or a payment
the journal entry's partner will be the commercial_partner_id of the child
By definition the commercial partner_id doesn't have a parent_id set
After this commit, the invoice is visible in the widget
OPW 2039768
closesodoo/odoo#36184
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Fixed backgrounds are disabled when using a mobile/tablet device,
which is not a big deal but, on some of them (iOS...), defining the
background as fixed breaks the background-size/position props.
So we enable this only for >= XL devices.
We may want to find a better alternative for future versions.
opw-2055073
closesodoo/odoo#36187
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit changes the '_get_combination_info' signature according to main
method signature to avoid inheritance problems.
closesodoo/odoo#36125
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
PURPOSE
Test frontend and UI tools of eLearning.
SPECIFICATIONS
Commit fe518f1fea introduced a search on sale order model in checkout
process. However this may fail as access rights are not always granted
* portal users can see orders linked to their company;
* salesman and a lot of specific groups (accounting, ...) can see their own
orders, all orders, or depending on some condition;
* BUT standard users (employee only for example) cannot see any sale order.
Indeed they do not even have right to read, meaning a search fail. Let us
sudo the search as this is contained in a sub method used to fetch some
data.
LINKS
Task ID 1937768
closesodoo/odoo#36166
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
-Create a second blog
-Move one post to this second blog
-Access the post with the url from the first blog
Before this commit:
You will get redirected to the new url with a code 302 (temporary).
After this commit:
You will get redirected to the new url with the code to 301 (permanent).
OPW-2059194
closesodoo/odoo#36161
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When validating a picking from location A to B, location A's quant.quantity
may be updated to a quantity != 0 with _update_available_quantity.
This is because the quant value is written as quantity - float_round(quantity).
As a result, the consistency check would find two existing quants, and raise.
Therefore the picking cannot be validated.
opw 2040091
closesodoo/odoo#35913
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Before this commit, a channel in mobile with option "Send messages
by email" had no composer when opening in mobile.
This issue happened because channel views in mobile are in fact chat
windows. Chat windows with such channels do no display any composer,
which is intended in desktop.
This commit fixes the issue by enabling the extended composer for
chat windows with email channels, just for mobile.
opw-2059468
closesodoo/odoo#36120
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The color picker in snippet options has two way to set a color: have a
data-color attribute => it is used, or have a o_custom_color class and
the background-color is set directly on that color.
In the case where we select no background color (transparent), it would
work in preview, but when applied the opaque color of the transparent
button (since opacity is not copied) is set which is wrong and
unexpected.
opw-2053636
closes#36131
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This reverts 0164c9dfcb
Have exchange rates:
Domestic - Domestic: 1.0
Domestic - Foreign : 1.113900
Make an invoice: 480 Foreign
Make a credit note: 140 Foreign
Make a payment: 287.20 Domestic
Reconcile all this with a writeoff: 18.04 Domestic
Before this commit, the first invoice was not fully paid
this was due to wrong summing of the partial lines that applies to it
account.partial.reconcile are made between only 2 move lines at a time
Whatever the amounts they hold, it has been computed at creation
and it makes no sense to aggregate their rounding error when computing
their impact on a move line (because, the information is already lost)
After this commit, the use case works, all invoices and payments are fully consumed and reconciled
Note that this is a simple use case, no dates or exchange rates involved
OPW 2057845closesodoo/odoo#36087
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Odoo's Mergebot