It may happen that the response of a json rpc isn't json parsable,
for instance when the connection pool is full (PoolError). In this
case, the response is an internal server error (500) in html.
Trying to json parse it throws an error. Commit [1], backported in
15.0 by [2] aimed at throwing a more readable and meaningful error
when this happened.
However, this error occurs frequently on the saas for the moment
(see task 3193565), and users constantly report those HTTPError
tracebacks introduced by [1].
In 14.0, we were using jQuery ajax, and the legacy rpc and error
system, where those internal server errors were handled as
connection lost errors (error code -32098). So basically, a
notification was briefly displayed instead of an error dialog.
This commit restores the previous behavior in the new rpc service.
[1] https://github.com/odoo/odoo/commit/5c4a54022b320
[2] https://github.com/odoo/odoo/commit/a01122543a79cclosesodoo/odoo#113434
X-original-commit: 278686d8540a194f0af51e1a0b68b26b13eaf544
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
The number property should be formatted like a normal integer / float field,
in the form view (show 2 decimal for the float, thousands separators, etc,
even when editing).
Task-3162402
closesodoo/odoo#113449
X-original-commit: 99c251820dcf4791625fabd3fcd61db84280d408
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
product._get_rules_from_location, orderpoint._compute_lead_days
and orderpoint._compute_rules can all be performances
bottleneck. This is mostly because the rules are retrieve
one by one, i.e lots of 'SELECT ... LIMIT 1' queries
are executed.
Refactoring this in stable is difficult because
there are lots of methods involved and the rules have
some type of hierarchy based on the location_src_id field.
So there are recursive calls that are hard to refactor.
Instead of doing that, the idea of this commit is to speed up
these individual 'SELECt ... LIMIT 1' queries by adding
b-tree indexes on some of the stock.rule fields that are
used as conditions of these select queries.
opw-2773988
closesodoo/odoo#113444
X-original-commit: a76c4944d09be9cacfe8d3bac805841d84fb3f41
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Van Delft Aurélien (avd) <avd@odoo.com>
l10n_gcc_invoice implements invoice template with mixed english arabic labels.
This commit makes some clean up on text/columns direction and alignment with a
focus on RTL readers.
1.
Lines with Invoice Date, Due Date, Delivery Date, etc. are aligned to right
Before
*Invoice Date: 9/11/2001 :etaD eciovnI)* ____________________________
After
____________________________ *Invoice Date: 9/11/2001 :etaD eciovnI)*
2.
Columns of order lines are reversed
Before
*Description - QTY - ... - Total Price*
After
*Total Price - ... - QTY - Description*
3.
English/Arabic titles in the headers are inversed (Arabic is on the top now, English is on the bottom)
4.
Small table with subtotal/taxes/total has reversed columns too, so values are
just below of Total column in the main table
Before:
*Title/eltiT - Value*
After
*Value - Title/eltiT*
5.
This commit also improves Payment Reference section to comply with other
sections, i.e. print single value and two labels.
Before
Payment Reference: INV/2020/00019 INV/2020/00019 :ecnerefeR tnemyaP
After
Payment Reference: INV/2020/00019 :ecnerefeR tnemyaP
STEPS:
* install l10n_sa
* create an invoice with customer that has Arabic language
* use "Send & Print" button to get pdf file
opw-3115673
closesodoo/odoo#113443
X-original-commit: 9f6ed327fe34738740d8cb3584313972c8a0f782
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
This commit removes the default `stage_id` group in the
'All Tasks' list view, as it is causing performance issues
closesodoo/odoo#113435
X-original-commit: 759d7b1a30841535de57c19954eff3507dd61eff
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Larcin Vincent (vila) <vila@odoo.com>
The delay of tooltips opened with the tooltip service can be given
in xml, with attribute data-tooltip-delay. If not specified, there
is a fallback in the service to 400ms. Before this commit, the
fallback wasn't correctly applied, because we parsed the xml delay
into an integer, which was NaN when the delay wasn't specified,
and as NaN isn't undefined, the fallback wasn't applied. As a
consequence, we opened the tooltip in a setTimeout with NaN as
delay, and it thus opened directly.
closesodoo/odoo#113425
X-original-commit: 553b2775a4b31c75d1d246816b749e4521e25726
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Let's say there is one account with code 431 and another with code 4310,
`ODOO.BALANCE("431,4310", 2022)` counts 4310 twice.
The reason is queries are done one code at a time, one by one.
The account 4310 is counted first when using 431 as a prefix (431%) and once
more with 4310 (4310%).
Now, the query uses all codes all at once.
The original idea was to cache queries as much as we could. If you later add the
formula `ODOO.BALANCE("431", 2022)`, the result would have been cached
because queries were done code by code.
Given the issue it brings, we thing this opmitisation is not worth it and is
therefore removed. It also makes the code client-side simpler.
opw-3144473
closesodoo/odoo#113418
X-original-commit: 07bd67f3a389bde4f33e08d97967dbb70ad5a19f
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Since [1] the highlight of the focused element in the search
auto-complete has disappeared. This makes the keyboard navigation barely
usable.
This commit restrains the owl styling of dropdowns to the Owl Dropdown
components. This restores the highlight of the focused element on all
website dropdowns (e.g. also the logged-in user one and the "+" to
display more menu entries).
[1] did move the bootstrap's dropdown specific style customizations to
`webclient.scss`.
Steps to reproduce:
- Drop a "Search" snippet.
- Save.
- Type "a" in the search box.
- Navigate the suggestions with the keyboard up and down arrows.
=> Currently focused element looked the same as the other ones.
[1]: https://github.com/odoo/odoo/commit/84715436d87bb05b421bc9ccaacda67d07571690
task-3148871
closesodoo/odoo#113409
X-original-commit: e21ab2cb4904da9efeb7710a8bf8f6efec67821b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
1. Install [Manufacturing], [Sales], [Purchase] on Apps (ordered)
2. [Settings]>[Manufacturing]>[Subcontracting]: set
3. [Sales]
- [CREATE] product type [Service]
- On the tab 'Purchase' add a vendor, select [Subcontract Service]
- On the same tab add `Purchase description` then save
- [Orders]>[Quotations]
- CREATE, add the subcontract service product and set customer
- CONFIRM
4. [Purchase] - [Requests for Quotation]
- should show on the top of the list if vendor was new. click
- [Description] column does not show `Purchase description`
Desired: show relevant data
Impacted versions: 15 - master
opw-3152072
closesodoo/odoo#113407
X-original-commit: fa33657e5e134a9f412a17da4082467ec847e395
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Steps to reproduce:
- In debug mode
- Go to a cancelled invoice in Accounting
- Click to the "Reset to draft" button in a fast timing (before the
`PopoverContainer` is mounted).
When hovering an element, a tooltip appears. If the target element
disappears before the `onMounted` of the `PopoverContainer`, then the
popover causes a crash because the target element does not exists
anymore.
This fix makes the `tooltip_service` verify that the target still exists
before adding the popover.
closesodoo/odoo#113406
X-original-commit: 589acab37a4c1b68876386b752a91c3412dc4569
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Dardenne Florent (dafl) <dafl@odoo.com>
The delivery should provide the same feature before and after
validation of the picking (however lot/package need a validation)
So the HS code should be available direclty since it's a static value
closesodoo/odoo#113390
X-original-commit: 350015088d3822cde84b5dcf83d053350beafa66
Signed-off-by: Steve Van Essche <svs@odoo.com>
When drag and dropping a grid item and then undoing the operation, it
is not undone correctly, causing the grid items to be broken. This
happens because since `observerUnactive` is called at the start of the
drag, the style (like the `grid-area`) and the grid classes changes are
not recorded and therefore, undoing does not restore them.
This issue was previously fixed in [1] by removing the call to
`observerUnactive` but it should not have been done and this call was
restored in [2].
This commit solves this issue by activating the observer for the
changes that have to be recorded when drag and dropping in grid mode,
in order to undo them properly afterwards.
[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
[2]: https://github.com/odoo/odoo/pull/106029
task-3074139
closesodoo/odoo#113384
X-original-commit: 1dfb127f70832aa9e9022ac337af343b7dc17729
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
1. Install [Manufacturing]
2. Go to [Manufacturing]
- [Configuration] > [Settings], toggle on [Work Orders]
- [Operation] > [Work Orders]
- click on Kanban view
- remove all filters, then click on [Group By] - choose any
Issue: overflowing state tag beyond each kanban card
Resolve by: ordering line by line the information to display
Impacted versions: 16.0 up to master
opw-3162947
closesodoo/odoo#113386
X-original-commit: a72dbedcb00cef76e9a85f59cc875461cf38eafe
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
In the website editor, a traceback error occurs when clicking on the
main element since the commit [1]. This is caused by the function
'_handleSelectionInTable' calling 'selection.getRangeAt(0)' without
checking if there is at least one range in the selection.
Steps to reproduce the bug:
- Open the website editor and drop a text snippet onto the page.
- Click on the snippet to activate it.
- Click on the empty area below the snippet, which corresponds to
the <main> element.
- A traceback error will appear (if it does not appear, repeat the
first three steps multiple times).
[1]: https://github.com/odoo/odoo/commit/d977bd64fe88c059c915f9eb0f8029cde65b216a
task-3196722
closesodoo/odoo#113383
X-original-commit: 6e79728c7e812458709d3a60ba37dc4c578905b2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this PR, messages received on channels with unknown channel
types weren't displayed on discuss. This was due to the fact that
the sidebar computed its items based on the channel type.
Steps to reproduce this issue:
- Open one browser as mitchell admin (on the Discuss app).
- Open one browser as marc demo (on the Discuss app).
- Send a message from admin to demo.
- Unpin the channel on the admin browser.
- Refresh admin browser.
- Send a message from demo to admin.
- The message is not received on the admin browser.
This PR fixes the issue by fetching channel data if the channel type
is missing when receiving a new message.
closesodoo/odoo#113377
X-original-commit: 3398aa8b10a1d9ad75552871e532f57ffcdd4a7f
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
This commit, is part of a series of commits that aim to simplifie
the concrete fields API.
In this commit we will remove type prop from concrete fields. Now each
field could directly use this.props.record.fields[this.props.name].type
if they need to know the type of field.
task-id 3179751
closesodoo/odoo#112792
Related: odoo/enterprise#37118
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit, is part of a series of commits that aim to simplifie
the concrete fields API.
In this commit we will remove update prop from concrete fields. Now each
field will directly use this.props.record.update to make changes, and
handle the save in fields that need to (e.g. priority). As a consequence
of this, the record props need to be mandatory.
task-id 3179751
Part-of: odoo/odoo#112792
The ofxparse module explicitly uses an html parser instead of xml but
since bs4 4.11.0, this triggers a warning.
closesodoo/odoo#113354
X-original-commit: e81ed97c9c54c69c68c54c69b4d3d80ed0515ae8
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Babel 2.10 (provided in Debian Bookworm) changed the `medium` format at
least for fr_FR and zh_CN.
This commit adapts the tests in order to work with both versions of
Babel. A custom format is used as our unit test is made to test that our
formating methods works, not the way the Babel formats.
X-original-commit: b77eb98bbf6bc937efb7941802c0794ae3622094
Part-of: odoo/odoo#113354
Current behavior:
When you have a loyalty program with a free product, and a rule with a
minimum amout. The free product is not added to the order if the free
product is already in the order.
Steps to reproduce:
-Set a loyalty program with the following Conditions:
Minimum Qty: 1
Minimum Spend: $5
Grant: 10 Points/Order
-Reward:
Type: Free Product
Item: Any item (eg: Bacon Burger)
Exchange: 30 Points
1. Open POS that has this loyalty program.
2. Process sales with a Test User until user has 30 points.
3. Attempt to redeem the Free Product under "Reward".
Note: I modified the other test, IMO it makes sense that when triggering
the rewards it adds Product A and Product A * -1. Because if the product
that was already in the order become free, the rule to trigger the
rewards is not met anymore.
opw-3135794
closesodoo/odoo#113313
X-original-commit: 253d308a26f1e6479c1d3c5342e1cede6f635198
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
To reproduce (V16):
1. Force modify a view with an unexisting field
For example `res.users.tree` with:
`<field name="unexisting_field"/>`
( note that odoo won't allow to do so,
you will have to do it in raw PSQL * )
2. Open Settings > User & Companies > Users
=> JS traceback error:
```js
UncaughtPromiseError > TypeError
Uncaught Promise > Cannot read properties of undefined (reading 'string')
TypeError: Cannot read properties of undefined (reading 'string')
at http://localhost:8069/web/assets/debug/web.assets_backend.js:67523:84 (/web/static/src/legacy/legacy_load_views.js:67)
...
```
* : In practice, it happens to Odoo customers after
incorrect installations/removal of apps
After this commit:
The JS traceback is much clearer regarding the error:
```js
UncaughtPromiseError
Uncaught Promise > Missing field string information for the field 'unexisting_field' from the 'res.users' model
```
OPW-3071843
closesodoo/odoo#113345
X-original-commit: 33f82a60cd3bb64e67d939795b774cd332ab0508
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit:
We use the employee's manager's user's idto fetch a partner by id.
This can cause the action to fail in specific cases as well as
potentially using the wrong language for the reminder
closesodoo/odoo#113282
X-original-commit: c26db495c929d60de62a36cf920c88f6f4c855b9
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, no check was made on conditional questions to see if their
condition was valid when taking a survey.
With this commit, if the survey is not in "random mode" (in which case,
conditions do not apply), there is a check to see that a conditional question
has a valid condition. If not, it is not used in the survey.
Task-3083488
closesodoo/odoo#113303
X-original-commit: f14d1f89ee9c78d481ce1f30ef74bdad9ef0cd7e
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
# Steps to reproduce
* install account_accountant, documents and l10n_it_edi
* Switch to an Italian company
* go to Documents > Configuration > Workspaces and create a new
workspace `W` and it's child `W1`
* under Documents > Settings, activate Accounting and set `Workspace`to
`W`
* save and go back to Documents > Settings, and click `Journals` under
'Accounting'
* add a line with Journals = 'Vendor Bills' and Workspace = `W1`
* go to Accounting > Vendor > Bills and upload a Fattura PA XML bill
* now open the newly generated bill
You should see that the chatter does not load.
# Cause
When uploading a Fattura PA XML bill, a PDF attachment is created and
added to the chatter. The issue is happening because the
`ir.attachment` record ends up in an invalid state where its 'res_model'
field is false.
The 'res_model' field is actually defined when the attachment is
initially created. However, that value ends up being overwritten when a
related `documents.document` is created here: https://github.com/odoo/enterprise/blob/3f53e50989fbb9551565429aede7c0a1e4d6e5a4/documents_account/models/account_move.py#L88
Because of the following line, that `documents.document` will be
assigned a default `res_id` (but no `res_model`).
https://github.com/odoo/odoo/blob/26b2cbd4e5c73ea66456a91ea9cb36d6b174cae7/addons/l10n_it_edi/models/account_edi_format.py#L767
However, setting `res_id` (or `res_model`) on a `documents.document`
will also overwrite the related attachments' values (in this case, the
attachment's `res_model` is set to false because the document's
`res_model` is false).
This behavior happens because of this inverse compute: https://github.com/odoo/enterprise/blob/b4201e6b422e5b0bde1f04db37bcda4941d0665f/documents/models/document.py#L97-L104
opw-3119669
closesodoo/odoo#113299
X-original-commit: 6839abc79a947e30750ec535058828c190c18955
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
When the product configurator is opened, the focus is always on the
custom value input, which may scroll down the configurator and make the
user miss attributes
Steps to reproduce:
1. Install Sales
2. Go to Settings > Sales > Product Catalog and enable Product
Configurator and save
3. Go to Sales > Products > Products and open product 'Cabinet with
Doors'
4. Go to the 'Attributes & Variants' tab and create and edit an
attribute 'Custom'
5. Add a value 'Notes' and check 'Is custom value' and save
6. Add the value to the product and save
7. Open product 'Customizable Desk', in the 'Sales' tab, add 'Cabinet
with Doors' to the Optional Products and save
8. Create a new quotation and add product 'Customizable Desk'
9. The product configurator opens up with the focus on the 'Custom'
attribute input, if the window has a small height, it scrolls down to
that input
Solution:
Remove the focus on the custom value input
Problem:
The focus was made on the input of custom values
opw-3057390
closesodoo/odoo#113301
X-original-commit: dd3e5be00cc4e3408d90abb3923b6658fb1d3073
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Currently, the vat label value comes from the company's country instead of
the customer's country.
So in this commit, if customer country and current company country is same then
we set the customer's country vat label in an error message else we set default `VAT`.
closesodoo/odoo#113295
X-original-commit: 27bae2a04fd333dc54429973d396f329d3710a3d
Signed-off-by: Josse Colpaert <jco@odoo.com>
This commit fixes the shared-worker feature detection with using the
browser object alias.
Steps to reproduce:
- Log to Odoo back-end with a device without a shared-worker support
like Chrome on an Android device => traceback
link:
https://caniuse.com/mdn-api_sharedworker
opw-3198778
closesodoo/odoo#113293
X-original-commit: 4aaafd46dbe1188bf2d9c0140a916ef664d99c42
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This PR fix a traceback that occur when pressing spacebar while the confirm
dialog for deleting a link preview is open.
task-3196494
closesodoo/odoo#113274
X-original-commit: d46a5171378497992bd65634f1aded53db27e9ef
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
1. Install [Expenses], [Indian - Accounting], [Accounting] on Apps
2. [Settings] [Users & Companies] [Companies]
- create a company based in India with address there
3. Enter [Expenses], [CREATE]
- create and add an employee w contact info (private address) in India
- set paid by: Company, write an amount, category > [CREATE REPORT]
- [SUBMIT TO MANAGER] [APPROVE] [POST TO JOURNAL ENTRIES]
4. Click on the [Journal Entry] created at the top right corner
Issue: Missing pos field hinders revising it by [reset to draft]
Resolve by: change the requirement in view and enable further revision
Impacted versions: 16.0 up to master
opw-3168426
closesodoo/odoo#113270
X-original-commit: bc08a6e9d0cc42d1586913bf95d01d4547c13b05
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Clicking on draw in the signature dialog should clear whatever is already drawn
on the canvas.
task-3040855
closesodoo/odoo#113248
X-original-commit: f1c3d83f5b4f6ef0e2b5db2b7aa55344c91454f0
Related: odoo/enterprise#37338
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
This method is not used by rpc calls and wrongly allowed users to read the standard_price
field by calling the method through rpc.
Make it private to reduce its uses and avoid this potential leak of information.
closesodoo/odoo#113234
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Clarify the uses and impacts of current_attributes_price_extra and
no_variant_attributes_price_extra context keys.
Group the key specification and usage.
Provide a clear API shared by templates and variants.
Part-of: odoo/odoo#113234
Since 4d2b04a843, invoices
auto-generated on Sales Order payment were not sent to
customers.
Invoices are only marked as 'posted' in the override
of `_reconcile_after_done` in account_payment which means
`_send_invoice` must be called after the super call s.t.
the invoices are correctly posted before being sent.
opw-3158620
closesodoo/odoo#113229
X-original-commit: 82c53dd3404992b14d1db331c37b6d03c9f0ace1
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The X report of a PoS is a resume of the sales/refunds and other information of the session.
It can be printed at any moment of the session.
The Z report is the same as the X report with a bit more information like the starting and
the ending datetime of the session. It can only be printed after the end of a session.
The Z report can only be printed with the Swedish and Belgian localization at the moment
and the goal is to make it available in the standard version. This commit also adds some information to the
reports like the different invoices done during the session and also changes the layout of the reports
to be more readable.
closesodoo/odoo#113228
X-original-commit: b8b9067642fd75c2c02b202d9cffac98a4e150d4
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Since [this commit], it is possible to have a block only displayed on
mobile screens. This feature can break the steps snippet by following
these steps:
- Drop a steps snippet in a page
- Set the third step to be visible only on mobile
=> The connectors are broken.
This commit fixes this issue by only considering steps that are visible
in desktop view for connectors drawing.
[this commit]: https://github.com/odoo/odoo/commit/3103e0553011b5c1f4078972d7a88fa3fd4068b2
task-3116227
Related to opw-3135927
closesodoo/odoo#113184
X-original-commit: d8521d197518e90d63443d1095b2df84487ad4ae
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
From [this commit], it is possible to define the visibility of blocks
according to the device on which the page is displayed (either hide on
mobile, or hide on desktop). This change has brought two problems on the
table of content block:
1. The sub-component s_table_of_content_main (the right part) can be
invisible, which does not make sense.
2. The sub-component of s_table_of_content_main can be invisible but it
did not change the navbar of the TOC.
This commit prevents hiding the main part of the TOC and rebuilds the
navbar of the TOC according to the device visibility of its
sub-components.
[this commit]: https://github.com/odoo/odoo/commit/3103e0553011b5c1f4078972d7a88fa3fd4068b2
task-3116227
Related to opw-3135927
X-original-commit: b7f9c26a93e58f2ace964ab6b05132cc9f8f3366
Part-of: odoo/odoo#113184
By following these steps:
- Drop a block table of content on a page
- Disable the visibility of the block in desktop view
=> A traceback is displayed.
This is because for scrollspy to work properly, the elements that it
handles must be visible (no display: none). Unfortunately, we put a
display none when the block must be invisible for a certain device and
the width of the screen is the one of this device. Since it is quite
complex to prevent all the cases where the block could become invisible,
we patch the scrollspy component of bootstrap so that it has a similar
behavior as in version 4.X. (not cause an error if the navigation
element is no longer in the DOM or is no longer visible).
The error is only visible since [the migration from bootstrap 4 to
bootstrap 5] because to add the class, bootstrap 4 did it with the
JQuery addClass() function which does not cause an error if the element
on which it is called does not exist. Now, bootstrap 5 does the same
thing in pure JS with classList.add() on elements that meet the
requirements (visible) which causes an error if the element on which it
is called is not defined (this is the case before this commit because
the TOC was not visible).
[the migration from bootstrap 4 to bootstrap 5]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
task-3116227
opw-3135927
X-original-commit: f2b86dda77133ed9c4f02394693e771758d18bad
Part-of: odoo/odoo#113184
A/B testing was used in the past to create mutually-exclusive mailings.
Since then a 100% limit for the recipients of an A/B campaign.
As there is no technical reason for this limit and not having it allows
for a special usecase, it is replaced here with a text warning.
The usecase in question being that as the domain of the different
mailings composing a campaign may be different, users may want to
take advantage of the fact that only 1 email will be sent to each
address to avoid sending 2 mailings when only one or the other should
be sent. Consequently users may want to use 100% of the domain on
every mailing in their campaign.
As the ab_testing_total_pc is only used for that purpose the field
is removed. 'total' field is not always accurate and is unused so
it is also cleaned up.
task-3008627
closesodoo/odoo#105639
Related: odoo/upgrade#4257
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Aaron Bohy