Steps to reproduce:
- define a home action for the user
- delete the action in configuration > Window Action
- refresh to the home page
-> id not found
Solution:
- prevent the deletion of a window action if used as a home action
OPW-2728824
closesodoo/odoo#89420
X-original-commit: b868583690d8560d3cc300b9448f0af32f41d81a
Signed-off-by: yosa-odoo <yosa@odoo.com>
Before this commit, Barcode was not displayed on template
when related product variant is archived.
Here we are making sure that even when a product is
archived, its barcode is still visible in template.
closesodoo/odoo#89363
X-original-commit: f0c7cde3938c01df5fc10bb8dcd72fd3bb18afdb
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Issue: when using Amazon's SES SMTP service they rewrite the Message-Id of all
outgoing messages. When someone replies, In-Reply-To contains the SES Message-Id
which we don't know. Threading is therefore broken. Amazon requires to remember
new Message-Id and handle it ourself, which is complicated [1].
Possible solution: copy the Message-Id to References in outgoing message as if
we were pretending that the message is part of a pre-existing thread with
itself. Since Amazon does not alter References it is kept during transport.
Replies will therefore contain both Amazon Message-Id and Odoo Message-Id as
well as original parent Message-Id in case of nested replies.
* ``In-Reply-To``: Amazon Msg-Id
* ``References``: Odoo Parent Msg-Id Odoo Msg-Id
Task-2643114 (Mail: Message-Id in references to ease thread formation)
[1] https://docs.aws.amazon.com/ses/latest/DeveloperGuide/header-fields.htmlclosesodoo/odoo#89328
X-original-commit: bc568747bdf92c6bbca400ce3ba11f6487679f3a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Followup of odoo/odoo@de7c119e66 where the parent finding was incorrectly refactored.
Indeed due to a typo new_parent was not updated. Instead of getting higher in
the parent chain until the first message, only the first parent's parent was
considered.
Moreover ``_mail_flat_thread`` is incorrectly taken into account. Due to the
hereabove issue it was not really impacting discussion channels, as anyway
parent finding was not working.
New parent management, depending on ``_mail_flat_thread`` is now
* ``_mail_flat_thread`` True: no free message. If no parent, find the first
posted message and attach new message to it. If parent, get back to the
first ancestor and attach it. We don't keep hierarchy (one level of
threading);
* ``_mail_flat_thread`` False: free message = new thread (think of mailing
lists). If parent get up one level to try to flatten threads without
completely removing hierarchy;
Tests show that parent is correctly flattened on business documents and left
untouched for channel-like documents.
Task-2822652 (Mail: fix parent message fetch / flattening)
X-original-commit: 86f21c1f384e37a4555b4b1ce4831904c8d40b6f
Part-of: odoo/odoo#89328
Purpose is to test behavior when having multiple references in mail headers.
We have to check that parent_id is correctly taken (as it impacts internal
flag), and that flattening is performance when posting the message (always
attaching to the thread first message being the default behavior).
Note that tests highlighted that flattening is currently a bit broken as it
does not go up until the first ancestor, which is the expected behavior for
business documents having ``_mail_flat_thread``. Next commit will fix that.
Task-2822652 (Mail: fix parent message fetch / flattening)
Task-2643114 (Mail: Message-Id in references to ease thread formation)
X-original-commit: f7d4f1d29213c71e76564c485db2bbecf0bbf37c
Part-of: odoo/odoo#89328
Avoid calling with_user() inside method has_group() when possible, as it
represents a major overhead inside this method which is commonly called. This
sole optimization speeds up the accounting general ledger by about 6%.
closesodoo/odoo#89206
X-original-commit: e858507aaf01c3701bf5642978490d7947acf35d
Signed-off-by: Raphael Collet <rco@odoo.com>
This task will:
- Clean the code (e.g. the production's moves are now created directly)
- Have the same behavior when creating object in the UI or directly in
backend
It's mainly on the `mrp.production` object and most of the computed
stored field are used as default value or act like an onchange on draft
production. Once the production order is validated, it's only modify
by direct write
Task-2709753
closesodoo/odoo#83576
Related: odoo/enterprise#24405
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Fixed the TestPurchaseInvoice.test_double_validation and the setupClass
to use test accounting data in setupClass instead of the demo data.
closesodoo/odoo#89370
X-original-commit: a7546aead36c5d56809fcd9c46b2a552991b5449
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
When having a subview for a 2many field, if an onchange is triggered for
that field, the default values of the parent are still in the request
context.
To reproduce the issue:
(Need helpdesk_repair. Use demo data)
1. Helpdesk > Configuration > Helpdesk Teams, edit "Customer Care":
- Enable "Repairs"
2. Create a storable and tracked-by-usn product P
3. Update the on-hand quantity:
- 1 x P with serial S
4. Helpdesk > Customer Care (Tickets), create a ticket:
- Product: P
- Lot/Serial number: S
5. Click on Repair and save the repair order R
6. Edit R and add a line in "Parts"
Error: on the new line, both Product and Lot/Serial fields are already
filled with values P and S, which does not make sens
On step 5, when clicking on Repair, the form views of a repair order is
loaded with a specific context:
https://github.com/odoo/enterprise/blob/deef3c967d43862edf02dbcfc461fb89b064731e/helpdesk_repair/views/helpdesk_views.xml#L31-L34
Therefore, when editing the form and trying to add a new line in Parts,
an onchange is triggered but the default values are not removed from the
context. As a result, since the model `repair.line` also has two fields
called `product_id` and `lot_id`, the default values of the parent
(`repair.order`) are used.
When computing the context of a subview, the default values of the
parent should be removed.
OPW-2752436
closesodoo/odoo#89366
X-original-commit: db7423a97fd812fe6df95296fd7a6ca18854933b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Create a 15% tax [TaxA] *not* included in price
Create a 15% tax [TaxB] included in price
Create a fiscal position mapping TaxA to TaxB
Create a customer and assign this fiscal position
Create a product :
Price = 100€
Tax = TaxA
Create a SO with this customer and this product
We have this situation
| Price Unit | Tax | Subtotal |
|------------|-----|----------|
| 115 | TaxB| 100 |
While it should be
| Price Unit | Tax | Subtotal |
|------------|-----|----------|
| 100 | TaxB| 86.96 |
after tax mapping, as it was before
https://github.com/odoo/odoo/commit/625486a8382fde9033b73e2a4b4e7713cf4131c1
opw-2811596
closesodoo/odoo#89361
X-original-commit: 1a5b2b44c63afb302a2d6fc1e841e4ef3af46df5
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
before this commit,
in project form view alias_name field label color and padding are
different then other fields.
after this commit,
alias_name field label color and padding will be same as other.
field' label color and padding.
task-2758779
closesodoo/odoo#89329
X-original-commit: d33a839c1047a3abfa681611ae5276e0b929b555
Related: odoo/enterprise#26473
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit:
in task search view quick search on user_ids return active and
non-active tasks of user.
this commit remove active_test false from context of user_ids' quick
search so it should only return active tasks of user.
task-2758779
X-original-commit: 6148736215fe91d1eb1b19fd08809bdfe5a61fe2
Part-of: odoo/odoo#89329
before this commit,
in kanban view of task sub-task count of task is visible when
sub-task feature is disable from setting.
after this commit,
sub-task count of task will not be visible in kanban view of
task when sub-task feature is disable from setting.
task-2758779
X-original-commit: 1e45586c16443c3a19ae16f604882087dea3cc4e
Part-of: odoo/odoo#89329
This PR fix the "This attachment is already a document" Error when clicking on the "Apply Changes" button of a mrp.eco (Engineering Change Orders) in the PLM App.
With the Documents App installed and the "Product: Centralize files attached to products" document setting activated, copying the attachment will also copy the document.
Then when we try to copy the current document and link it to the new attachment, the above mentioned error appear.
The context no_document=True prevent the document copy during the attachment copy.
OPW-2762448
closesodoo/odoo#89324
X-original-commit: ed306afc0e812c1e42984f1b6cb94e61409f0144
Signed-off-by: Simon Goffin <sig@odoo.com>
Signed-off-by: DavidFesquet <dafr@odoo.com>
The putaway strategies are not correctly working with packages
To reproduce the issue:
1. In Settings, enable:
- Multi-Step Routes
- Storage Categories
- Packages
2. Create a Storage Category SC:
- Allow New Product: mixed
- Max Weight: 100 kg
- Capacity by Package:
- 1 x Pallet
3. Create two locations L1, L2:
- Parent: WH/Stock
- Type: Internal
- Storage Category: SC
4. Create a putaway rule:
- When in: WH/Stock
- Package type: Pallet
- Store to: WH/Stock
- Having Category: SC
5. Edit the warehouse:
- Incoming Shipments: 2 steps
6. Create a product P:
- Type: Storable
- Weight: 1 kg
7. Create a planned receipt R:
- To: WH/Input
- Operations:
- 100 x P
8. Mark R as Todo
9. Create two packages:
- 50 x P in PK01 (! PK01 must be a Pallet)
- 50 x P in PK02 (! PK02 must be a Pallet)
10. Validate R
11. Open the related internal transfer T
- Error [1]: Both packages are redirected to L01, but the capacity
by package is 1 x Pallet. PK01 should be redirected to L01 and PK02 to
L02
12. Set the done quantity of PK01
- Note: PK01 is now redirected to L02
13. Set the done quantity of PK02
- Error [2]: PK02 is also redirected to L02. Again, it violates the
package capacity constraint
**Context**
When validating the receipt (step 10), it creates a picking
Input->Stock. The module then tries to assign some quantities, which
leads to `_prepare_move_line_vals` for each package. In this method,
`_get_putaway_strategy` is called to define the best destination of each
stock move line:
https://github.com/odoo/odoo/blob/d55a99ff2d2f7b8d44cde1db3b6d48cdaac1cd3a/addons/stock/models/stock_move.py#L1313
The computation of the best location is in 3 phases:
- Phase 01: `_get_putaway_strategy` finds the relevant putaway rules and
computes the current and forecasted stock related to the current
package/product
- Phase 02: `_get_putaway_location` checks if, considering the putaway
rule and the current package/product, a location can be used
- Phase 03: `_check_can_be_used` checks if a location can receive a
package/product (considering the weight and the capacity constraints)
**Error 01**
During the first phase, in case of a package, the forecasted quantities
are computed by searching all SML that have the same package type:
https://github.com/odoo/odoo/blob/4bae10e0d960e5b80055e0e44056493238e552d3/addons/stock/models/stock_location.py#L258-L263
This can not work. The SML used to move the product in PK01 (from Input
to Stock) is created but its field `result_package_id` is not yet
defined. This operation will be done at the of the assign process,
thanks to:
https://github.com/odoo/odoo/blob/d55a99ff2d2f7b8d44cde1db3b6d48cdaac1cd3a/addons/stock/models/stock_move.py#L1547
So, during the first phase, when searching a location for PK02, the
computations are not aware that PK01 is already sent to L01. This
explains the error [1].
**Error 01 (Other examples)**
Considering how it is currently working, we could imagine another
problematic use case: 2 different products on the same package. Since
there is one SML per product, `_prepare_move_line_vals` will be called
twice (as well as the putaway strategy process). It may lead to two
different locations while the product are on the same package.
**Error 02**
When setting the done quantity, an onchange method is triggered:
https://github.com/odoo/odoo/blob/4202e46a8313fa9f1487d372ef0cb771f769be8d/addons/stock/models/stock_move_line.py#L200-L208
and tries to find the best location, considering the done quantity. As
said before, during the first phase, it looks for the current and
forecasted stock of a location. Since it will find the SML we are
writing on, the parameter `additional_qty` is used to subtract the
quantity of this SML (we need to ignore the current SML's quantity). But
here is a new issue:
https://github.com/odoo/odoo/blob/4202e46a8313fa9f1487d372ef0cb771f769be8d/addons/stock/models/stock_move_line.py#L217-L222
`_get_putaway_additional_qty` returns the quantity of products while the
first phase is looking for the quantity of packages. As a result, we do
some operations between products and packages:
https://github.com/odoo/odoo/blob/4bae10e0d960e5b80055e0e44056493238e552d3/addons/stock/models/stock_location.py#L290-L292
`qty_by_location[location_id]` is 2 (i.e. PK01 and PK02) for L01 while
`qty` is `-50` (i.e. the 50 products of the current SML), so the value
becomes `-48`. This can not work properly because the value doesn't have
sense anymore. Later on, during the third phase:
https://github.com/odoo/odoo/blob/4bae10e0d960e5b80055e0e44056493238e552d3/addons/stock/models/stock_location.py#L340-L346
The forecasted weight is not subtracted by the quantity of the current
SML. So the weight is exceeded, this is the reason why the destination
of PK01 becomes L02 on step 12 (it will be the same on step 13)
**Additional error**
Suppose the user is receiving a tracked product (suppose qty > 1). When
confirming the picking, several SMLs are generated to "reserve" the
quantity from the customer:
https://github.com/odoo/odoo/blob/d55a99ff2d2f7b8d44cde1db3b6d48cdaac1cd3a/addons/stock/models/stock_move.py#L1469-L1471
Later on, thanks to the wizard `stock.assign.serial`, the user generates
all USN. However, because the option `show_reserved` is disabled, the
wizard creates some new SMLs. But here is the issue, the SMLs created
during the assign process are already existing. Therefore, when looking
for the best location (for the new SMLs), the existing SMLs will disturb
the result (`_get_putaway_strategy` will find these SMLs and think that
some products are already incoming in some locations)
**Solutions**
- We should compute the best locations once all SMLs are created (and
linked with their package)
- In case of a package with a type, we should try to find the best
location for the package itself, not for each product of the package
- When calling the putaway strategy process, we should provide the
SML(s) to exclude instead of providing some quantities. This will
prevent subtracting products with packages and allow the correct
calculation of the forecasted weight for each location
- When creating a putaway rule, we ensure that the option
`show_reserved` of the destination location is enabled
OPW-2746169
closesodoo/odoo#89350
X-original-commit: 98169b391f4610545b7f4745b729ad95eac3696a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When selecting a quotation template for a quotation all the template lines are
copied into the quotation. However, the sequence field is omitted when adding
the lines. As a result all quotation lines have, by default, the same sequence
number.
This should not be a problem, since the lines are still shown in order in the
frontend quotation view. Once the lines are shown, the user can freely reorder
the lines, while the frontend takes care of reordering the sequence numbers.
However, there is an interaction with an existing problem in One2Many and
Many2Many fields. When these fields are paginated a sequence update will only
update the sequence numbers on the first page. This means that, before this
commit, when we move around a line on the first page, all the lines on the
second page will be inserted at the second position on the first page (because
of the way _onResequenceRecords is implemented).
This commit does include the sequence number in the copied quotation lines,
resolving the problem described above.
Note: It is still possible to insert new lines in the first page, extending
the sequence numbers at the end of the page. Since the sequence numbers on the
second page still remain the same, there are now lines on the first and second
page having the same sequence numbers, resulting in a similar bug.
opw-2730746
closesodoo/odoo#89344
X-original-commit: 6f11060d6afd9edce904dd34a2d415a2a2461108
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>
These tests fail non-deterministically.
The underlying problem is currently being fixed.
But to fix runbot issues, the tests are skipped in the meantime.
Note that the failure in tests show very rare buggy behaviour,
but the buggy feature is very minor. So it's reasonable to not
obstruct mergebot by just skipping tests while a fix is being
prepared.
closesodoo/odoo#89384
X-original-commit: a51a636bc3acdab3700323a825c77ba4572e942f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Ensure the `onChange()` callback is called
after each history steps in the editor.
Call the `_doAction()` directly, to avoid using the
disabled `_doDebouncedAction()`.
task-2760436
closesodoo/odoo#89339
X-original-commit: 18eaabcb4dab4682e3a94e16dbe66ff3c6f35a77
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
The costs and revenues stat button on the project form view
should not be present since the saas 15.1, so we hide it.
closes odoo/odoo#89359
Related: #75269
X-original-commit: 6a508b351419a7edbc8276a8174ea60859b24dda
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
In case there is an AML with 0 qty, the generation of the FatturaPA e-invoice
tracebacked. Even if it's a functional error on the invoice, this also impeded
the EDI cron to run, and this is solved by avoiding the case in the
computation.
closesodoo/odoo#89348
X-original-commit: 79cbea8b9241c1fa98db1bb575ea430360d630e3
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
This commit moves some business logic from components to models,
as a step to move further to having essentially all business code in models.
Having code in models is desirable to have very maintainable code, thanks to
robust and declarative code with an ORM-like architecture.
Task-2826823
closesodoo/odoo#89323
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
lines
Create test directory for l10n_it_edi_sdcioop, and relevant tests for
the exported xml. These tests are run in l10n_it_edi_sdicoop because
there is different behaviour when l10n_it_edi_sdicoop is
installed (different checks are run on the invoice).This module should
eventually be merged with l10n_it_edi in master.
closesodoo/odoo#89207
X-original-commit: dffb205dad9ce29288c82c4b51011b77ddf33580
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
### Current behavior before PR:
The `product.template` model has a nice function `create_product_variant` that unfortunately expects its input to be in JSON.
### Desired behavior after PR is merged:
JSON decoding is moved into the controller, such that the function can be called as expected.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#88989
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In the mass mailing form, when clicking on the filter save button, the screen
was unexpectedly scrolling down. This fixes this problem.
Task-2793090
closesodoo/odoo#86789
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
- Create a storable product with routes: MTO + Buy
- Create a Portal user “pu1”
- Create a SO > select the “pu1” as customer
- Validate and confirm the created PO
- Connect as “pu1”:
- Go to the sales order view:
Problem:
The client can see outgoing and receipt(PO picking) transfers, this is a problem because then the customer can see information from the vendor
Solution:
A portal user should only see outgoing type transfers in the sale order view
opw-2816719
closesodoo/odoo#89285
X-original-commit: 91cfdf997dd210f2cbc684674745ab0b251088d2
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, when the Project Manager wants to see the burndown
chart report, he cannot see all the tasks if the project visibility is
follower and he do not follow the project. Indeed, he can only see the
ones in which he is assigned or follower. This behaviour is not expected
for a project manager but only expected for a project user.
This commit adds a rule to avoid filtering the records from burndown
chart report when the current user is a Project Manager.
Related PR: #82634closesodoo/odoo#89284
X-original-commit: f045bd78d562ec48762479138bc8388af252d06a
Related: odoo/enterprise#26457
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The accounts Furniture and Equipment, Computer Hardware &
Software and Motor Vehicles had the wrong type (Current assets)
we changed it to match egyptian fiscal law (Fixed assets).
opw-2821715
closesodoo/odoo#89280
X-original-commit: 315b3b13644dcad007ae9efd1a22bb32f64da143
Signed-off-by: Josse Colpaert <jco@odoo.com>
Bug
===
If the user doesn't have access to the project / CRM module, those
menus were visible on the addin side.
Now, the sections are not visible if the user doesn't have access to.
Task-2765323
closesodoo/odoo#89260
X-original-commit: 7b7aa72ecdc7e69e425ae08c28e1e7827e423548
Related: odoo/enterprise#26446
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Allow to re-use the method `mock_auth_method` used to mock the Outlook
authentication, to be able to write tests in other sub-modules.
Task-2782150
X-original-commit: 6932f05bfc4b2beabaf7c6390f1d241fff73bd38
Part-of: odoo/odoo#89260
Finetuning of 970904b06f6872aadf69d64c7bc82072a16f1596
Only update the template (& reset the lines if change done through UX) if
the SO wasn't saved already to make sure existing setup is not reset.
This commit restores even more of the previous behavior when the template
was only defaulted to the current company one. Now the default is only
modified if you change the company before saving the record.
In all other cases, the template can only be modified manually/programmatically,
but won't be reset/updated by the compute method.
Task ID - 2798588
closesodoo/odoo#89255
X-original-commit: 7209e391789be6a807bd4eac22257e888cbaf1a6
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Add test for use case fixed by d43e9cb9ad8d1c0c020209de0e8f6ffdcbc960a1
closesodoo/odoo#89237
X-original-commit: 21be0d8e96b9fb6e9fd6476a664ce89b017a7767
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
This commit aims to fix an error created in task 2658415 which prevent to create a new time off.
taskID 2829472
closesodoo/odoo#89221
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, when the user cancels his validated time off planned
in the future, the timesheets generated for this time off are not
deleted. The problem is since the timesheets are not removed we could
have duplicated timesheets if the user adds a new time off in the same days
for instance, because the newest timesheets are generated and thus we have
duplicated timesheets generated instead of having only timesheets generated
for the newest time off.
This commit removes the timesheets generated for the time off when this
time off is canceled (=archived). Also, It also prevent the user to
manually unarchive the time off since this operation is not really
managed and could introduced eventual problems.
Related PR: #76722
Part of task-2791386
closesodoo/odoo#89246
X-original-commit: a9e63ebe32079e2215acafcd4bca15b371ee9bc2
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
Co-authored-by: William Braeckman <wbr@odoo.com>
This commit moves some handler methods from components to models,
as a step closer to having most of business code in models.
Having business code in models is desirable so that the code is much more maintainable:
easier to change and more robust code.
Task-2579306
closesodoo/odoo#89123
Related: odoo/enterprise#26379
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
before this commit,
in project update right side panel view rating stat button's icon is
static it does not update depending on rating percentage and percentage
not showing properly.
This commit display rating average percentage in project update right
side panel view's rating stat button instead of just displaying
rating_avg_percentange field's value and rating stat button's icon will
update depending on rating percentage.
task-2758779
closesodoo/odoo#89209
X-original-commit: 549e1750cf51f27befe6278a71250cca0c720139
Related: odoo/enterprise#26423
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
SVG images are considered an xml like format, as a consequence restrictions
apply for manipulating svg type attachments. This poses a problem when a
website designer tries to save a page containing images with svg shapes. This
commit allows writing attachments with an xml like mimetype to anyone with
write access rights on views.
opw-2806930
closesodoo/odoo#89185
X-original-commit: d5aa54ca108eb99c7eb855a7d456bfe2f208a8eb
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this PR, chat window scroll position was reset to top when it was
switched to the left.
This PR introduce a component hit that restore the position saved inside the
models when a chatwindow is switched.
task-2746500
closesodoo/odoo#89134
X-original-commit: 0f11abaf09f08fc9643dac5ee8d4df6d1ef5686b
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
we find some bug when backporting to v15 so we fix this in fw-port
value of token_validity is not converted to UTC so fix it,
And groups in the field are wrong like ```account.group_system``` so set right one ```base.group_system```
Also, fix IAP buy credits message where set URL out of the Markup
Task 2179664
closesodoo/odoo#89110
X-original-commit: 1191abca6aa863cbb4a70c0329fd2271547049fa
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Survey invites sent to contacts are in the user's language and they
should be in the partner's language
Steps to reproduce:
1. Install Surveys and Contacts
2. Install another language (eg. fr_FR) but keep English as the
application language
3. Create a contact with the different language (fr_FR)
4. Create a survey and share it with the french contact (the template
used should have translations in both language)
5. Check the mail sent (Settings > Technical > Email > Emails)
6. The email is written in English but it should be in the contact's
language
Solution:
If all the recipients of the invite use the same language, display the
invite in the recipients' language to the sender so he can modify it or
send it directly
If they use different languages, use the template in the sender's
language
opw-2760489
closesodoo/odoo#89214
X-original-commit: 52f37c061015f5425587d46ff54973f18c0223eb
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
* Avoid auto-transforming an valid url inside an existing <a> tag.
* Ensure the current selection range is deleted
before embedding an image or video.
task-2604627
closesodoo/odoo#89210
X-original-commit: 070bceeadd16e0b5643b91ad583449d31c48313d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
We change the way we handle paste of html data :
The basic flow is :
1. if any range => deleteRange and continue from here
2. if the paste data has only one root <p> :
> we unwrap its content in place
2. if the paste data has two root <p> :
> we unwrap the content of the two p in place
> we force a oEnter between the two contents
3. if the paste data has more than two root <p> :
> we unwrap the content of the first and last p
> we force a oEnter between the two contents
> we insert the rest in between, out of focus block element
@see unit tests in `test/spec/copyPaste.test.js`
task-2604627
X-original-commit: 4dde6d37f30c35714c52e7e28f7011414fed7b6a
Part-of: odoo/odoo#89210
whitelist of html element was not designed to keep the style
set by our own editor ( style on <span>).
We add a system to keep the spans when they meet some requirements.
Requirements are basically having one of the few allowed inline styling css rule.
@see tests in `test/spec/copyPaste.test.js` section 'Html Paste cleaning'
task-2604627
X-original-commit: da92c2335a1241ec9f3974d3bac1c4b7227b2d28
Part-of: odoo/odoo#89210
Gitdyr