Before this commit, the setting search was done exclusively in some
selected texts. These texts needed to be on some specific selectors
(field, label, span.o_form_label and div.text-muted).
Now, all text on a setting are searchable (including the text in
buttons). This commit also re-structure the setting compilers file to
remove the functions outside the class, this is done to standardize the
compilers (setting, form and view).
closesodoo/odoo#107226
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Improved the tooltip description of the 'Detect automatically' field for fiscal positions. The previous tooltip was "Apply automatically this fiscal position" while the new one is "Apply tax & account mappings on invoices automatically if the matching criterias (VAT/Country) are met."
task id : 3088331
PR number : #107092
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Prior to this commit, the layout of the fields of the form for a rule in
a chatbot was broken because of a missing condition in the
'only_if_no_operator' checkbox label.
closesodoo/odoo#107459
X-original-commit: bcd952f358c06017fc33f3e5af74cf3aff17a18a
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
According to the orm documentation, the `digits` attribute of
float fields must be either a tuple (int, int) or a string.
However, people set `digits=0` on a bunch of float fields (some
are there for a while now). Historically, the webclient handled
this as "there's no digits attribute set", so it fallbacked on 2
digits precision.
With the new views, and owl props validation, we assert that the
`digits` props, when given, is an array. In the above situations,
we have a props validation error.
This commit fixes the error by filtering out the `digits` props
when it is not an array, s.t. it keeps working as before (i.e.
fallbacks on 2 digits). In master, we'll remove the fallback.
opw 3083100
closesodoo/odoo#107418
X-original-commit: 36407a9837ba3bf90670ae763751dc631309867b
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Due to a change in Bootstrap, the tablepicker, the toolbar and the q-web
branching selector were hidden by modal dialogs.
In Odoo 15.0, the included Bootstrap version was 4.3.1, in which
.modal's z-index is set at 1050.
In Odoo 16.0, the included Bootstrap version is 5.1.3, in which .modal's
z-index is set at 1055.
Therefore, the previous z-index value of 1051 is now updated to 1056.
task# 3002456
closesodoo/odoo#107431
X-original-commit: 263137bcd38f788ff96d13d0810df4da13b72a19
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Validating an employee's leave with multiple companies selected doesn't
work when the employee isn't part of one of the selected companies
Steps to reproduce:
1. Install Time Off
2. Go to General Settings > Companies and create another company
3. Connect as Marc Demo, open Time Off and create a new time off request
4. Connect as Mitchell Admin and go to Time Off > Managers > Time Off
5. Approve and validate the time off request of Marc Demo
6. An access error is raised: `Access to unauthorized or invalid
companies.`
Solution:
Clear `allowed_company_ids` from the context when we create the
`calendar.event` to avoid raising the error
Problem:
The creation of the `calendar.event` didn't use the correct user's
`allowed_company_ids` in the context
opw-3052973
closesodoo/odoo#107415
X-original-commit: a5ab773378f5ba2241793c536cf141d27d250ae5
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Incorrect variable reference + calculation for unit BoM cost for
byproduct/product (to produce) within in BoM overview report. This
was leading to the displayed value having the cost_share being multipled
into the unit cost twice.
Steps to reproduce:
- create component with cost 100
- create BoM with 1 of this component + 1 byproduct with
qty = 2 and cost_share = 50.00
- click on Overview
result before this commit:
Manufactured Product unit cost = 25.00
Byproduct unit cost = 12.50
actual result should be:
Manufactured Product unit cost = 50.00
Byproduct unit cost = 25.00
closesodoo/odoo#107410
X-original-commit: 2339bed170b5f670b1f5a6cebd533a9cee72d4db
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
current link will return 404 error, updating the website link to correct documentation link
closesodoo/odoo#107399
X-original-commit: 33f94926038bb5cf9a9f7feadd2d6596e331b4e1
Signed-off-by: William André (wan) <wan@odoo.com>
Current behavior:
If the PoS has no cash method configured, and you try to make a
payment with a greater amount than the due amount, you will get an
error message. Because you cannot give money back to the customer as you
have no cash method configured.
Steps to reproduce:
- Remove Cash payment method from the PoS
- Open a PoS session
- Create an order with some products
- Pay the order with a greater amount than the due amount
- Validate the order, you will get an error message
Solution:
If the Pos has no cash method configured, and the user try to make a
payment with a greater amount than the due amount, we will automatically
set the amount to pay to the due amount and show a message to the user.
opw-3061612
closesodoo/odoo#107398
X-original-commit: 6280e5ac921b21d10100cd78a18072120d823aca
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Before this fix, the '.o_form_status_indicator' was in the right
part of the control panel.
But on desktop, we want it next to the last breadcrumb item
to cognitively attach the "save status" to the record name.
closesodoo/odoo#107397
Task-id: 3067691
X-original-commit: 24b098767b03c97ffe108a7f8aa0f77c08aecef5
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The currency_field shouldn't have to be specified in the view if it has
the same value as the field specification in python.
closesodoo/odoo#107396
X-original-commit: 47cf3688baf6aed6f027fc44db7293d9563789f4
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
We don't want the changes related to a country to affect all the other
countries.
closesodoo/odoo#107395
X-original-commit: 5079ace74958d4acd54d24a95579289a2eda92f1
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
If the website domain is wrongly configured (set to a URL that will
actually be redirected through DNS/proxy/cloudflare etc), the website
preview iframe will loop forever.
The wrong configuration this commit is about are:
- Having set the website domain to naked URL while you configured your
naked URL to redirect to your `www` URL.
- The other way around (`www` to naked URL).
- Having set the website domain to `http` while you configured your
`http` domain to redirect to your `https` domain.
- The other way around (`https` to `http`) if it's even possible/done by
someone
While this could just be considered as a misconfiguration, it's a low
effort to support it. Also, the bug it implies is quite critical as the
user can't access his website app anymore (if he is smart enough and
somehow figure it's because of the website domain, he will think about
going to the General Settings to remove the domain).
All in all, it's a low effort to fix a (rare) critical issue.
Step to reproduce (`https`):
- Go to runbot (in `https`, normal way)
eg: https://21544921-16-0-all.runbot172.odoo.com/
- Edit the website domain and set it to the `http` version
eg: http://21544921-16-0-all.runbot172.odoo.com/
- Try to access the website app, it will loop forever, indeed:
1. You are on the `https` URL in your browser tab
2. The website app will try to load the iframe with the website domain
as URL, which is the `http` version.
3. The code in charge of loading the iframe URL (website_preview.js)
will detect that `http` URL as originating from a different domain
than the one of the current tab URL (parent window).
4. In this case, that code will reject that URL and instead load it in
the parent window URL -> It will basically redirect your whole
browser tab to that URL.
This is done as if you are loading the URL of a different website,
we want you to be completely redirect to this other website domain.
5. As `https` to `http` redirection (and naked -> www or www -> naked)
is done at a lower level (through nginx, dns, cloudflare etc), the
browser will not load the `http` requested URL but redirect and
load the `https` one.
6. Now, you are basically back to step 1. and entering an infinite
loop.
The same issue can be reproduced with naked domain and `www` domain but
not on runbot and difficult in local.
You can also reproduce it in local, but it will just do the useless
redirect once and won't loop as nothing is redirecting the naked to www
in local:
- Edit your `/etc/hosts` file and write
```
127.0.0.1 rde.com
127.0.0.1 www.rde.com
```
- Edit your website domain to `http://www.rde.com`
- Now go to `rde.com:8069`
- It will wrongly redirect to `www` version
-------------
On top of that, the domain misconfiguration would also lead to useless
reload when using the website switcher (it would reload the whole page
instead of just the iframe).
Step to reproduce on local (on runbot it will be replicable but it will
then enter the infinite loop described above):
- (Still with the `/etc/hosts` tweak described above)
- Edit the website_1 domain and set it to the `www` version
eg: `http://www.rde.com:8069/`
- Edit the website_2 domain and set it to the `naked` version
eg: `http://rde.com:8069/`
- Open the website app, land on one of the website (and its URL)
- From there, select the other one, it will redirect the whole page to
the other domain (naked vs www) instead of just reloading the iframe.
-------------
opw-3079168
closesodoo/odoo#107394
X-original-commit: 0808659dd29db938bb6f8386ee2027eafecb2f0f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The model terms translations assume the number of terms in each language of a
model_term translated field should be the same.
However, sometimes the assumption cannot be promised for sake of bad
translations
This commit
1. drops illegal model term translations while translating
2. drops mismatched terms at run-time in case the database has been contaminated
closesodoo/odoo#107373
X-original-commit: f9ab5ca3e99b2883ada18a8f6deb12d45608b43f
Signed-off-by: Raphael Collet <rco@odoo.com>
// CASE 1: payment with different rate
1) Setup a company in USD, with EUR activated as well
2) Set a rate of 1 EUR = 2 USD for date A, and 1 EUR = 3 USD for date B
3) Setup a Cash basis tax of 1/3, with a non-reconcilable cash basis transition account
4) At date A, create an invoice with just one line with base amount=99.99 EUR ; and using the tax setup in point 3).
5) Register a full payment for this invoice at date B
===> The exchange move created by the full reconciliation consists of cash basis rounding lines for the CABA base received, transition account and tax account. 99.99 USD for the base, and 33.33 USD for the tax. Those are introduced to bring back the total amount in domestic currency to the domestic amounts computed for the invoice at date A.
Impacting the tax account and base received account is totally wrong. When doing cash basis, we want to use the rate of the payment in the amounts that get reported, as it corresponds to the money that actually came in. So, none of the lines impacting those accounts should be there.
Only the line impacting the cash basis transition account is useful, to bring its value back to 0. But it actually corresponds to an exchange difference, and we need to balance it with an exchange gain/loss account. This account can already be set as reconcilable, and if so, will be auto-reconciled. We now choose to only rely on that behavior. The account will not be brought to 0 in domestic currency if it's not reoncilable. If it is, it will create a regular exchange difference entry to handle this case properly.
// CASE 2: multiple payments in foreign currency, at different rates
1) Setup a company in USD, with EUR activated as well
2) Set a rate of 1 EUR = 3 USD for date A, and 1 EUR = 2 USD for date B and 5 EUR = 1 USD for date C
3) Setup a Cash basis tax of 1/3, with a non-reconcilable cash basis transition account
4) At date A, create an invoice with just one line with base amount=99.99 EUR ; and using the tax setup in point 3).
5) Pay 66.66 EUR at date B
6) Make a second payment of 66.66 EUR at date C
===> The problem in this case is that the tax and base amounts in foreign currency (33.33 and 99.99 EUR) will need to be divided by 2 (because we're making 2 payments, hence 2 cash basis entries), and the currency rounding will round these values to 50.0 for the base (instead of 49.995) and 16.67 (instead of 16,665) for the tax. Summing the cash basis moves will hence give a total base of 100, and tax of 33,34, which is wrong.
To handle this, a cash basis rounding of 0.01 EUR needs to be done in the exchange difference entry. The corresponding amount in domestic currency must be computed using the rate of the most recent payment, so it will be 0.05 USD here.
Before this commit, this case behaved as the first one, and brought back the reported amount to the rate of the invoice. Moreover, since it never adjusted the amount in foreign currency, the transition account could not be fully reconciled.
// FIX
To handle both those cases, we now split the behavior of the CABA adjustment:
- For rounding errors: we now check the foreign currency amount, and adjust it if necessary, reusing the rate of the most recent payment. If there is no foreign currency, the adjustement is still done for domestic currency, of course.
- Exchange rate difference of the transition account is not handled there anymore: to do this, the transition account must be reconcilable. In case of rounding error to compensate for, the adjustment line added in the exchange difference entry will be reconciled with the one on the CABA entries and on the invoice, to reach full reconciliation.
In case a transition account is not reconcilable, we only create rounding adjustments, no exchange difference.
closesodoo/odoo#107334
X-original-commit: 01cb7e960f912c4758d30c04653b599937785799
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Inputs are displayed on a colored background that made the placeholder
invisible -> fixed in PR https://github.com/odoo/odoo/pull/104136
Apply button's placement made it related only to the second input but
it should not be the case -> Space was created between button and
second input
task-2984182
closesodoo/odoo#107089
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit makes use of the spellcheck hook to only enable the spellcheck attribute
on the textarea element when needed (on focused element). Since form view are now
always displaying a textarea, instead of relying on a readonly state, the textarea
used by the HtmlField always displayed red underline on typos.
This means the UI can become difficult to read if there are multiple red lines in
the text. Now, it is only present on focused textarea thanks to the useSpellcheck
hook.
This change can be noticeable in many apps, including notes from records and the
Knowledge editor.
A test has been added to verify that the hook enables/disables the attribute on the
contenteditable element used by the html editor..
task #2861428closesodoo/odoo#106866
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds the ability to enable spellcheck on input/textarea only
if they are in focus. This avoids the UI to be bloated with unwanted
underlined text on unfocused elements. It is especially useful in a context
of form view in always edit mode.
A core hook has been introduced to allow other components to use the same
behavior without reimplementing it. It is currently used by the TextField.
It means it is also used in the HtmlField. Tests have been written, both for
the field component, and the core hook.
task #2861428
Part-of: odoo/odoo#106866
Ideally, we develop in English any localization (then translate to the domestic language, in this case Italian) All the module has been translated in english and then a .po file has been create to translate back in Italian
closesodoo/odoo#106693
Task-id: 3082347
Related: odoo/enterprise#34465
Signed-off-by: John Laterre (jol) <jol@odoo.com>
The main goal of this commit is to reduce the size of the registry by
removing the (almost) useless __last_update field.
Statistics # of fields with all modules installed:
before 30184 fields, 1299x last_update (4.30%)
Before this commit, the computed field __last_update was added on every model.
The idea behind this field was to have a computed field that had either
the write_date or the create_date if the write_date was empty. However,
the write_date is always written, even on creation, making it useless
to have the computed field __last_update
After this update, we completely remove from BaseModel:
* __last_update
* CONCURRENCY_CHECK_FIELD that was always defined as "__last_update"
* _compute_concurrency_field that was the compute function for __last_update
closesodoo/odoo#105739
Task-id: 3062140 (part of 3062137 improve registry load time)
Related: odoo/upgrade#4038
Related: odoo/enterprise#33939
Signed-off-by: Raphael Collet <rco@odoo.com>
When filling a Sales Order applicability rule line, the financial
account prefix is useless, as it will not be used.
Thus we can make it invisible in the case of business_domain corresponding to sales and purchases.
task-3040927
closesodoo/odoo#105014
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
In pricelist form view and product form view, pricelist rules are now invisible if referring to an archived product or an archived pricelist.
task-2920563
closesodoo/odoo#105112
Related: odoo/enterprise#33910
Related: odoo/upgrade#4028
Signed-off-by: Arnaud Joset <arj@odoo.com>
Some commands from the powerBox command bar were not working
properly in the e-shop product "terms and conditions" section.
This was due to the isolation of Odoo fields
inside the odoo editor as a all.
Those fields do not always have an editable block element
to apply the command on.
We disable some commands that should not be apear in this context.
We also remove a redundant command (separator) in website pages.
task-2962067
closesodoo/odoo#107174
X-original-commit: 3776faa178314c4df889f4c04cc3931f8bef225c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the cron related to contract expiration
only created an activity. Now, it also writes a message in order
to warn all concerned user.
task-3081295
closesodoo/odoo#106768
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
1. Create a BG company
2. Install the BG Chart of Accounts
3. Install the BG language
4. Switch to the BG language
5. The CoA is not translated
This is due to a missing field in the CoA xml: `spoken_languages` which is now fixed.
Moreover, the language code of Slovenian has been fixed from `si` (which is the country code) to `sl`.
closesodoo/odoo#107353
X-original-commit: ce8f692256714df57864e991e050734b5e04b1f9
Signed-off-by: Laurent Smet <las@odoo.com>
Currently it is only possible to run the modules
for the IoT Box on Raspios.
The modifications brought by this commit brings the possibility
that the various hw_* modules can be executed whatever the OS
of the hardware (Linux or Windows).
If the modules should be versioned according to the OS,
the file will be renamed so that the end of
the file includes *_L (for linux) or *_W (for windows)
closesodoo/odoo#107350
X-original-commit: b7b8809ea8b7fe4ac8b24f43fe3f3a5e38a66696
Related: odoo/enterprise#34713
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Steps to reproduce
==================
- Create an invoice
- Add a line
- Type storage in the product field
- Ctrl+A then press backspace
- Press escape to close the autocomplete dropdown
- Click elsewhere
-> The first suggestion is now selected
opw-3055185
closesodoo/odoo#107302
X-original-commit: e0613bc06ba9f2653dd0cfc4057ba93abf8513f7
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Usecase to reproduce:
- Set stock valuation as perpetual
- Create a PO with a different currency than the company
- Validate the receipt on create the invoice
- Set a discount on the invoice and validate it
The amount currency is not set on the account.move.line created by the
valuation layer. It could prevent the reconciliation to succeed since
it would be base on invoice currency.
It happens because the amount currency is created from the difference
between layer price converted to invoice currency and the invoice line
`price_unit`. However `price_unit` is missing the discount. So this pr
add extra computation to get the gross price unit discount applied.
closesodoo/odoo#107256
X-original-commit: 493020b9317a439c0a61a34f37cc92b6779ef633
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
The delivery slip of an outgoing picking prints the warehouse address
instead of the delivery address (which should be displayed as it may
be different from the customer address)
Steps to reproduce:
1. Install Contacts and Inventory
2. Open Contacts and add a delivery address named "delivery" to contact
Azure Interior
3. Go to Inventory > Operations > Transfers
4. Create a new transfer with:
- Contact: Azure Interior, delivery
- Operation Type: San Fransisco: Delivery Orders
- Product: Large Cabinet
5. Save the transfer and print the Delivery Slip
6. The warehouse address is displayed and there is no info about the
delivery address
Solution:
Add a method to know if we should print the delivery address. We should
print it if the picking has a delivery address and it is of type
outgoing (or if it's a dropship)
Problem:
Printing the delivery address when the package partner is different from
the picking partner is wrong because the delivery address might be
different from the customer address
opw-3064203
closesodoo/odoo#107355
X-original-commit: ec929f787f629940cd38a4ed25e5012335e2483d
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
A move in draft created with an account that is later deprecated can
still be posted, while it shouldn't be allowed.
Thus, we add a new error blocking this wrong behaviour.
Task id #3087763closesodoo/odoo#107354
X-original-commit: d8c2ad469299349e5184bc8986183cb205beb16a
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
A. UX Improvement:
1. get rid of the `.0%` in the tax names (makes the UI a bit harder to read)
2. For TTC taxes, remove the TTC in the description to prevent it from appearing on the invoice's pdf
B. Tax issue:
Fix some mistakes in the taxes, based on reliable feedback of french partner Didier Six.
1. Fuel purchase taxes: shouldn't imact the P1_base and P1_tax grids because these are for petroleum product to sale.
Instead, put them in grid 20 (normal goods bought)
2. All tax "IMPORT":
- base line shouldn't impact the [{08/09/9B}_{base/tax}] tax grid as these are for sales operation in France and the [I{number}_{base/ tax}] are already there
Currently, the tax is putting up [{08/09/9B} _tax] and [Ix_tax] which induce a double calculation of the due VAT
- tax line should also impact the [24] `24 - Dont TVA déductible sur importations` in addition of the [20]
This tax grid isn't taken into account for the total deductible VAT calculation as it is after the total and label "dont TVA déductible[...]"
4. OSS: add the tax grid E3 on invoice base line and F8 on refund base line
task-3087037
closesodoo/odoo#107351
X-original-commit: 0cea284eec5d3d2bb9aa8d94c0edcb211ba08a50
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
The tax report did not open, because its sequences did not make sense, as some child lines had a lower sequence than their parent. We also reorder the way some child lines were declared, for standardisation.
closesodoo/odoo#107171
Related: odoo/enterprise#34627
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Some formulas had not been properly converted to the new format introduced in 16.0. The report crashed when opening it.
OPW 3064180
X-original-commit: e0cd7020580bc34d5c31bc327361def534d04272
Part-of: odoo/odoo#107171
Currently, adding members in a sales.team without the multi-company group is
not possible, the selection does not show any users.
This is because the domain field for the users search ("member_company_ids") is
not computed as none of its triggers are present in the view.
To fix this, we add the 'name' field as a fake trigger to force the
computation.
Side-note: the tour was added into the CRM module as we require this module to
have entry menus into crm.team form views.
Task-3088861
closesodoo/odoo#107352
X-original-commit: 11d24d8757a74cdf4af433bdc735460e68ba6cd2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Enable the test for payment modules, as we want to test their install/uninstall.
But disable the test for the deprecated payment modules, which can only be installed
through command line since 16.0.
closesodoo/odoo#107349
X-original-commit: ae559ee083723ff16ec78d93ec781202686553e6
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Incorporate Alexis Hernandez (sebasdrk17) as Vauxoo's contributor
I confirm I have signed the CLA and read the PR guidelines at
www.odoo.com/submit-pr
closesodoo/odoo#107341
X-original-commit: d39eb80069c5f8c3c4d89e6e6b714e8cc96bb7e3
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit enables the use of the option "All pages" when using a popup
snippet.
Steps to reproduce the bug:
- Drag & drop a popup snippet.
- On its option in the right panel, there is "Show On" set by default
to "This page".
- Try to modify this option and select "All pages".
Bug observed: The "All pages" option can not be selected and the "Show
On" stays on "This page".
This commit has been done because since the version 16.0, the footer is
on an iframe [1]. Because of that, the program does not have a direct
access to the footer. This is why it is needed to first access the
top-level document before using the querySelector.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2983822
closesodoo/odoo#107236
X-original-commit: f469385dcfcbd9290c3522422f9e10600bb60b76
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit move allow_billable field of task to sale_project from
sale_timesheet module.
task-3018123
closesodoo/odoo#106961
Related: odoo/upgrade#4093
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
**Issue:**
On the first group level, the caret that prefixes the label is
separated from the label by 5px.
But, on the 2nd group level (and deeper levels), the caret and
the label have no space in between. This is not visually pleasing.
**Solution:**
The span containing the caret has a fixed-width which conflicts with
the specified padding to show hierarchy of the groups.
We avoid this conflict by specifying margin to indent nested groups
instead of padding. This indentation (start) margin is calculated in
css to be able to reuse the values from `$spacers`. It is based on the
dynamically assigned css var "--o-list-group-level" that is calculated
based on the group level.
We also specified the end margin using a utility class (.me-1). This
is the space that separates the caret to the group's label.
closesodoo/odoo#107333
X-original-commit: 1d8f6359bbf55983a9582282d12a187c67cdf509
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Co-authored-by: Joseph Caburnay <jcb@odoo.com>
this commit improves the performance of importing translations by
1. groupup udpating data for different languages and different modules
2. read model_terms translations data directly with xmlid to get rid of fetching
data from ir_model_data
for modules:sale_management, point_of_sale, industry_fsm, helpdesk, mrp, mrp_plm
(62 installed modules)
time for test_language_install is 45.14% less
for all modules:
time for test_language_install is 68.03% less
closesodoo/odoo#107332
X-original-commit: 727ef9e0a2ca93089b472eb1313117fee8dc876d
Signed-off-by: Raphael Collet <rco@odoo.com>
The view height of the mail template was too small (30px) when accessing the
mailing view form from the mail campaign menu. This solves the problem.
Note: To get better view and similar to previous version (15.3), font size has
been adjusted.
Technical note: this has been solved by adding a min-height in the css
definition of the class (o_field_mass_mailing_html) used to display the iframe.
This is the same value as the one already used when the template is not yet
chosen.
Task-3067603
closesodoo/odoo#107331
X-original-commit: 38ad5bf080a6948c30b34be57beb073eb377dfd9
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
When clicking on the picking smart button through the `pos.order` and the `pos.session` views,
the displayed name shown was "To do" instead of "Pickings"
closesodoo/odoo#107330
X-original-commit: f39d96d6d9fb0c5f80188504d47523461c1b4ba2
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
While upgrade of a customer database, A P-type image
was being converted to JPEG image. It didn't allow to save
as direct conversion from P-type(palette) to JPEG. So, fix
covers conversion of such corner cases to first convert it
to RGB and then RGB can convert it to desired output format
opw-3043418
closesodoo/odoo#107300
X-original-commit: d0db7a14dec7ee6a983ede3bf7b968675f83979d
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit changes popover widget such that instead of altering the
popover component during app lifecycle to make dynamic
popover templates, use `t-call` to call template passed in props.
closesodoo/odoo#107286
X-original-commit: f1a9de85c19a53c9516cac44de6cbaf53d850842
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Odoo ORM has special optimization for installing module with a stored related
fields, but it requires the final field be not computed [1] (I'm not sure why),
which is not the case for the `group_id` field. Since `account.move.line` table
may have millions of records, we have to optimize the installation and fill
`l10n_pe_group_id` via a single sql query.
[1]: https://github.com/odoo/odoo/blob/0aff8bb9484a23c0d875d3b12259dd4e0d51e716/odoo/fields.py#L818
opw-2762510
closesodoo/odoo#107157
X-original-commit: 63341b5856b4a5cbc6fda17a4cc1d40f84cf7476
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
There are several customizations of the list and form view that consist
in modifying the behavior of a static menu action (archive, unarchive,
export, delete, duplicate). We have seen that this one is very complex.
So we decided to simplify it.
Solution:
Add the getStaticActionMenuItems API point. This allows us to easily
modify the behaviour of static actions.
We also took advantage of this commit to simplify the ActionMenu api.
We have removed the other actions because it was not clear enough.
They are directly added in the action category.
closesodoo/odoo#107086
Taskid: 3089039
Related: odoo/enterprise#34598
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Jorge Pinna Puissant