With commit [1] (and the parent commit here which reviews it), we
move the scrollbar to the modal instead of the website content if the
modal has scrollable content even in the case there is no backdrop. An
exemple would be the cookie bar, configured in popup mode, with a tall
content inside.
This was however not enough: the computation which determines if the
modal should be scrollable or not was not re-done after an image was
loaded. So if the popup was around the height of the window, it could be
smaller than the window's height before images loading and taller after
which would result in having the scrollbar on the body instead of the
scrollable popup.
[1]: https://github.com/odoo/odoo/commit/8f1dd6d6087ad8252d6e7b22d13aad2c4a3f19c6closesodoo/odoo#84139
X-original-commit: b83b465dd98345afeca3844a4796e4a83d15f72b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor
Commit [1] was not coded defensively enough: after it, dialogs not using
a proper bootstrap structure triggered a traceback once they were opened
(this was discovered on odoo.com where such unconventional dialogs do
exist). Bad luck: there was actually a check to allow unconventional
dialogs but it was not done at the right location.
However, fixing this, it was found that more than this was not ok. There
is actually no need to consider the modal-content element at all. Just
using our `hasScrollableContent` method is enough and requires no extra
search in the DOM. This actually also properly computes if the modal
overflows or not while it was not the case before as it did not consider
the modal-dialog element's paddings.
Finally, the whole customized behavior of the modal scrollbar here was
only designed to affect our Odoo modals with the s_popup_no_backdrop
class (see original commit [2]). Indeed, only in that case we want to be
able to switch between body scrolling and modal scrolling while the
modal is opened. In custom cases and other Odoo cases, we want the
standard Boostrap behavior of only being able to interact with the modal
while opened. This commit cleans the code to restore that spirit
(hopefully this does not cause stability issues as [1] was introduced
only a week ago). Sorry for any inconvenience.
[1]: https://github.com/odoo/odoo/commit/8f1dd6d6087ad8252d6e7b22d13aad2c4a3f19c6
[2]: https://github.com/odoo/odoo/commit/e5a5f98819b3a70b3e2564fb91722cab415ceea9
X-original-commit: a2363337355ccf4363249657000cd85bfcb3ab4e
Part-of: odoo/odoo#84139
This commit adds the 'consumeVisibleOnly: true' marker on the "+New"
step of the website_event tour, and requires the "new content menu" to
not be opened.
This is a part of [1] but for a tour that did not exist in 14.0.
[1]: https://github.com/odoo/odoo/commit/0fa40e37e596798665a098ee999f49749b6012a2
task-2728994 (was task-2675252)
closesodoo/odoo#84137
X-original-commit: 9c6d5c038a6d3888a329d2140169e52389b3b5c8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Consistency in naming with other models.
Part of task-2694206, split from main PR to ease its diff
closesodoo/odoo#84130
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since [1] when web was migrated to OWL, the cookies bar was considered
as a parent modal of any openend modal that got closed - thus preventing
scrolling the full page.
After this commit the cookies bar in the front end is not considered as
a remaining modal anymore, and therefore does not prevent scrolling on
the currently displayed website page.
[1]: https://github.com/odoo/odoo/commit/29731b404fe624b733d784cd4321113d6b0d27b7
task-2741894
closesodoo/odoo#84128
X-original-commit: c1aab97e6b4e8b916c7d79db5f278c746fd6b119
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Consistency in naming. Remove CSS as a bonus.
Part of task-2694206, split from main PR to ease its diff
closesodoo/odoo#84127
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The field show_update_pricelist, readonly, is not provided
to the server by the webclient, and therefore not updated on
new sale orders.
This fixes this problem and also reduces the recomputation by removing
the useless dependency on 'order_line' field. The compute should
only be triggered on 'pricelist_id' field updates.
closesodoo/odoo#84105
X-original-commit: 365df4b1ed08f553397eab9619d369867162ed89
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The state of sale order lines is strictly related to the order state,
it's unnecessary to read the information line by line (and fetch/compute it)
when we already have it on the current order record.
X-original-commit: 660eaccbb417938bff0ffd8bd6a03aa1c42ce877
Part-of: odoo/odoo#84105
Do not update the commitment_date everytime the expected date is
modified, otherwise there is no meaning to have two fields...
Furthermore, it seems that this onchange causes a performance loss
on SO/SOL updates, forcing the whole SOL data to be returned along
the SO data during the SO onchange.
Therefore removing this onchange improves the performance of SOL updates
and consequently the final save of the record by reducing the data wrongly
considered modified and given to the create/write call.
X-original-commit: 116ca30b2f5f27f8959961c786b88fdcec36338a
Part-of: odoo/odoo#84105
Steps to reproduce:
- Install Website
- Go to Settings -> Website
- Replace favicon with a 'big' image
- Go to Website and edit any page
- Click on Home
Issue:
Favicon preview in popover is too big.
Solution:
Set a max height/width for favicon preview (16x16).
opw-2744522
closesodoo/odoo#84101
X-original-commit: bb90ff7f320f815310ca8e76d19bccadf4204cc2
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
To reproduce the issue:
1. In Settings, enable "Units of Measure"
2. Create a product P:
- Type: Storable
- Unit of Measure: Units
- Purchase UoM: Dozens
3. Create a PO with 1 (Dozens) x P
4. Open the Forecasted Report of P
Error: The value of "Requests for quotation" is 144, it should be 12.
The quantity has been converted twice.
OPW-2744195
closesodoo/odoo#84091
X-original-commit: 524a1c597fd409a488bb6af37aca8248727691c1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
File uploader might be deleted because it is linked to views, but the process of
upload should still happen for the related thread.
closesodoo/odoo#84085
X-original-commit: ddfcee8f35da4bcf16f258d1bdfd0cf08436d001
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
There isn't `ir.model.access` on `event.event.ticket` for public and
portal users, but there is already the `ir.rule` to check the access.
In master, It causes an issue now, since https://github.com/odoo/odoo/pull/82896,
the `description` field of `event.event.ticket` isn't prefetch anymore
by the sudoed `event_registrations_open`
compute (that fill the cache with ticket data in sudo).
It crashes single app build:
https://runbot.odoo.com/runbot/build/12473674
We prefer to backport it in stable, there are maybe some corners where
it will raise an Exception and for sake of correctness.
closesodoo/odoo#84072
X-original-commit: d4f1be276d31215158b164f2f282afa8fa75f2b9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Whenever a record is modified in a demo/data file,
create will still be called, but with an empty list of values.
This flow is correctly managed in the core orm code, but a lot of
custom logic in create overrides is triggered for nothing.
This commit makes sure that create is not called with an empty list
when there is no record to create (i.e. only records to update)
during files imports (including modules demo/data loading).
Part-of: odoo/odoo#84055
write call on product.template.attribute.line with an active value specified
will trigger cache invalidation & flush even if no record is specified in
the call.
_create_variant_ids is called on multiple places, including the unlink
of product.template.attribute.line records. In this flow, self might
be an empty recordset, and there is no need to trigger early flushes and
cache invalidation if self is empty.
Part-of: odoo/odoo#84055
Steps :
Create a Leave Allocation :
Mode : "By Company" (just to give it to every employee).
Duration : 6 days
Create a Leave for 2 Employees A and B for week W.
Approve it.
Create a Leave for another Employee C for week W and next moday.
Issue:
Duration is 1. As a side effect, employee C still has 5 days left.
Cause:
At validation, requests with multpile employee create one leave per employee.
Then, a resource.calendar.leave is created fro eachone, including the firstone.
When creating the next request, _leave_intervals_batch looks for resource.calendar.leaves
with resource_id = C or False (which means several resources), that has been taken.
It finds the leaves taken by A and B, so it considers C is off too.
Fix:
We don't create a resource.calendar.leave for the multiple employee request.
opw:2739324
closesodoo/odoo#84078
X-original-commit: 4e3af83cdd455ae6cb82439d9e260c3f9ff0b564
Signed-off-by: Kevin Baptiste <kba@odoo.com>
With GS1 nomenclature, products and packagins use the same pattern.
Therefore, we need to ensure the uniqueness between products' barcodes
and packagings' ones.
closesodoo/odoo#82883
Related: odoo/enterprise#23550
Related: odoo/upgrade#3180
Signed-off-by: Arnold Moyaux <arm@odoo.com>
The size constraint on the barcode pattern is an old one and is no more
required. Moreover, if someone wants to add new GS1 patterns, he might
need more than 32 characters.
Part-of: odoo/odoo#82883
Open the link dialog from the wysiwyg with the label input.
Task-2704538
closesodoo/odoo#83454
X-original-commit: f7a0c321d94f84ed7daf4f6abff0740ad81024bb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce:
- install ecommerce - sales
- sales > settings > enable coupons/promotion program
- create a promotion program that applies on the first n orders
- make orders with the promo code applied until order no. n-1
- order no. n will fail when you add the promo code without giving an
error message
Bug:
The currently applied promotion program will not be applied if this is
the last order allowed in the program
Fix:
Include currently applied promotion program if it was the last order
allowed in it
opw-2737423
closesodoo/odoo#84031
X-original-commit: c397ed01019fc891d7b6e620c66f06deb2a13c69
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When combining the context for an RPC, the
additional context is being added before the raw
context.
Because of this, a use case such as:
- A o2m field with a context {'field': 'a'}
with a tree editable view below it
- That view defines controls to create lines,
which would change the context key 'field' to
another value.
=> The field context key would take precedence on
the creates key, making it impossible to override
that key in specific circumstances.
closesodoo/odoo#83996
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Current behavior :
"Learn More" link redirects to 404 page
Steps :
- Go to Apps
- Search for Invoicing
- Click on "LEARN MORE"
OPW-2743304
closesodoo/odoo#84030
X-original-commit: 8d6fbe78cc820579f978d883050027eafbcbd259
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>
Step to reproduce:
- Create a website form with its action set to 'create a task'
- Set a project for the task to be created in
- Submit the form while logged in as a portal user
Current Behaviour:
- Task is created but the data from fields is not take into account
This lead to the task not being linked to the project and ending as 'Private'
- Due to the changes of sudo in V15, authorized fields are not fetched
and thus cannot be set properly.
Behaviour after PR:
- The data is fetch via the SUPERUSER instead of sudo to ensure correct data
- The fields are correctly set and the task is created
in the corresponding project.
opw-2743065
closesodoo/odoo#84020
X-original-commit: de03ee2198e039e14d0852d2346cb8aaf3885b5b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Before this commit,
When editing a mass mailing in "wide" mode, the emoji widget
is outside of the subject field, which is not optimum for
several reasons like:
- It makes it harder to understand what it will do
- It is hidden under the tour bubble
After this commit,
Like in "not-wide" mode, emoji widget is now inside the
subject field.
task- 2730477
closesodoo/odoo#83995
X-original-commit: 9195a28dc19b3f0f29aa103e3a1fd62ee32216bd
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Step to reproduce:
Change the validation type of the hr.leave.type with id 1 (hlt1) to no_validation
Create a new time off request with a time off type different from hlt1
Current Behaviour:
Time off state is 'draft'
Behaviour After PR:
Default time off state is correctly computated.
opw-2713600
closesodoo/odoo#84007
X-original-commit: 5a26f3402d5760f7860897f2c64d359c7af7d14b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
For this case is wrong use the company of the user, because you may in other company at this moment and the search is not
working properly.
The way to solve this is use the "env" company as use in the computed method.
closesodoo/odoo#84037
X-original-commit: ee264787841395a95162ae809928ee71fd1b7c84
Signed-off-by: William André (wan) <wan@odoo.com>
Steps :
Create a project and a task.
Share editable with Deco Addict.
Collaborators > Deco Addict > Grant Portal Access.
Users > Deco Addict : change password.
Log in with Deco Addict.
Go to the task.
Issue :
You can assign yourself to the task.
This doesn't make sens as even an internal cannot assign a portal.
Fix :
Make this button available only for base.group_user.
closesodoo/odoo#84036
Opw: 2753908
X-original-commit: d8f83379ceb1f718c7ccbed33d3cd4d8f4d37c6f
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Strikethrough option was missing in the editor toolbar.
* Added the option in the toolbar.
* Added the keyboard shortcut (CTRL+5)
task-2754007
closesodoo/odoo#84029
X-original-commit: 9808073c22eacf9f2bcc55aa96eaec56f55597cc
Signed-off-by: Antoine Guenet <age@odoo.com>
In some cases load_new_partners returns a rejected promise
with an argument of type string, which causes a crash in
the catch which considers that it is an rpc error using
error.message.code and this is an error because error is
a string in the case of a reject on load_new_partners
opw-2679837
closesodoo/odoo#84019
X-original-commit: c1ab58324f22ec51a63e1428072eea293d6ae99d
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
The aim of this commit is to:
- correct the implementation of the restaurationMoms
- add a price_include version of restauraionMoms
- make a better implementation of the energy tax
before this commit:
The implementation of the restaurationMoms is completly false.
The implementation of tax energy is quite complicated and makes
the UI display a "0 tax value".
after this commit:
2 restaurationMoms version and both are correct.
Tax energy implementation is more user-friendly and more correct
regarding information displayed by the UI.
closes odoo/odoo#84004
Task: #2748309
Pr: https://github.com/odoo/odoo/pull/83666
X-original-commit: 7d4dcf7944cf776d74d31c80f2df15c8d44e3c5c
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>
It is currently not possible to update the quantity of a product from
the inventory report
To reproduce the issue:
1. Create a storable product P
2. Update its on hand quantity to 100
3. Inventory > Reporting > Inventory Report
4. On the line for P, update to quantity to 75
Error: The quantity becomes 0 instead of 75
When setting the quantity from the inventory report, the client calls
the `write` method with the context key `inventory_report_mode` defined
and equal to `True`
This `write` leads to `_set_inventory_quantity` which triggers
`action_apply_inventory` (without disabling the context key!):
https://github.com/odoo/odoo/blob/8b155b695823dfa954464ad0d5dd07445ece2471/addons/stock/models/stock_quant.py#L150-L158
At the end of the inventory update, it resets the field
`inventory_quantity` to 0:
https://github.com/odoo/odoo/blob/8b155b695823dfa954464ad0d5dd07445ece2471/addons/stock/models/stock_quant.py#L592
To do so, the `write` method is called again and here is the issue:
https://github.com/odoo/odoo/blob/8b155b695823dfa954464ad0d5dd07445ece2471/addons/stock/models/stock_quant.py#L244-L248
Once `inventory_quantity` is updated, since `inventory_report_mode` is
still in the context and equal to `True`, `action_apply_inventory` is
called again. Then, when applying again the inventory, it will consider
the value of `inventory_quantity` (i.e., `0`) to define the new
quantity.
OPW-2737437
OPW-2746201
closesodoo/odoo#84002
X-original-commit: 6500e99cbfda44ebd1931acd657e86841ac2342a
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
If a user without Administration/Settings rights tries to share a
project in edit mode with a collaborator, an access rights error is
currently raised when creating the portal user. We should not create
any user instead, as there is a signup link sent to the partner anyway.
He can then set up his password without having to click on Reset
password, which was not user-friendly anyway.
closesodoo/odoo#84001
X-original-commit: 8de8c196a137f4ebbf67d7c7c83fee36f873f5c8
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
When creating a new invoice by giving it an invoice_line_ids list for
which the last line is a note, the tax line may be created wrongfully
without partner_id, which is totally wrong.
To reproduce :
Create a SO
Set a customer
Insert a product with tax
Insert a note
Deliver the product
Invoice the SO and confirm the invoice
The partner_id is not set on the created tax line
While the issue only arises in 15.0, it brings to light that the partner
is not in the grouping keys while it should, so it will be changed in 13.0+
opw-2750851
closesodoo/odoo#83999
X-original-commit: 2ce994d279126aa0356b86d3fa38b699e9035e54
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
- Go to Email Marketing and create a new mailing
- Add Masonry snippet in mail body
- Send a test mail
The picture of the Masonry snippet is missing.
The masonry image is displayed with CSS via background-image attribute.
There are 2 causes for this issue:
1) The relative url cannot be converted to an absolute one.
This is due to the " entity used to surround the url that is not detected.
style="background-image: url("/web/image/mass_mailing.s_masonry_block_default_image_1");"
2) html_sanitize is applied to mail body, but html_sanitize doesn't allow
background-image style attribute.
opw-2735636
closesodoo/odoo#83998
X-original-commit: cdcef228aa30d7dd4081fa25a1aab4811acda3ad
Signed-off-by: Antoine Guenet <age@odoo.com>
When there are multiple projects and many tasks the compute of
project.project.doc_count may raise a `MemoryError` on access to the
projects kanban view.
This issue may appear since the addition on 642fb2e6 of docs_count field
to the kanban view `view_project_kanban`.
https://github.com/odoo/odoo/blob/136808203545eb5d7056d941f3fc250f2871f95b/addons/project/views/project_views.xml#L613
This provokes too much information to be prefetched by the ORM, in
particular the `description` fields of the tasks which may be big (e.g.
contain embedded images).
This issue was observed during upg-101057
closesodoo/odoo#83997
X-original-commit: 6c207ed1027d9b39eecd19886932b17f1a79dccd
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
qsm-odoo