in the model/view the name of the field is Applicant's Name and in the user error message the warning is shown as Contact Name, improving the message for easy and better understanding for the end user
closesodoo/odoo#107498
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, when using the spellcheck of safari, the selected
word was interpreted as the text "#" by the editor.
task-3093997
closesodoo/odoo#107563
X-original-commit: b8d1ff6bc39530e601baa29971bca720e2dd06cf
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Improve a condition to be more inclusive
and be truthy in some rare cases.
closesodoo/odoo#107545
X-original-commit: 51e37c00c749e6bf033317c612856d15daf6c39d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
in the wizard of sales report in point of sale module, the one2many tree's width is more than the screen size due to given col=4 and scrolling option is shown.
Point Of Sale -> Reporting -> Sales Details
closesodoo/odoo#107241
X-original-commit: b1e1ae315e7ff3e22e7533a602cea0e150eafb75
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
## Steps to reproduce
* Using Firefox, Go to Accounting > Invoices > create a new invoice.
* Add a line to the invoice and remove the label.
You should see that there's no indication that the label field is
required. (It works well in Chrome)
## Cause
This is happening because the table borders (that become red when a
field fails validation) are not displayed in Firefox.
opw-3040299
closesodoo/odoo#107564
X-original-commit: 74726c649fa5bddec30573c18acd11020302d093
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Issue:
1. Install eCommerce + set up "Contact" header (there are probably other
configurations where this bug occurs but this one fails for sure).
2. Go to website in english version (with few menu items on header)
3. Switch language to Arabic
=> The "+" dropdown appears on the header even when there is enough
space for other menu items.
Explanation:
The 'AutoMoreMenu' option is used on website menu to auto adapt the
header layout so that elements are not wrapped on a new line (and sets
a "+" dropdown that contains the overflowing menu items).
When the language is switched to Arabic (or any RTL language), the
current code ('computeFloatOuterWidthWithMargins()' method) won't be
able to compute the reversed margins correctly for "unfoldable" items:
For example, if we want to compute the width (including margins) of the
"user dropdown":
============================================
IW -> Initial width value (without margins)
LR -> Left margin computing
RM -> Right margin computing
============================================
A- On English version (LTR):
1- LM: item has left auto margin class -> left margin won't be added.
2- RM: item has no right auto margin class -> right margin added (=== 0)
3- The final width is the same as the initial value (IW).
B- On Arabic version (RTL):
1- LM: item has left auto margin class -> left margin won't be added.
2- RM: item has no right auto margin class -> right margin added (> 0).
The right margin value added here is just the left auto margin
reversed because of direction. The code will return a final width > IW
and since the item is "unfoldable", its width will reduce the available
space for foldable items.
Solution:
The goal of this commit is to make the code smart enough to avoid adding
wrong right/left margin value caused by left/right auto margin class
on 'RTL' direction.
opw-2963123
closesodoo/odoo#107573
X-original-commit: 8a4a59389338ad1f50c08df3d55c267ca4d830da
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When an employee was their own manager, the org chart would be filled
with their own name.
task-3093917
closesodoo/odoo#107546
X-original-commit: 53f9359d84a6bb500db693298a12608964a0a118
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
With the tables' custom selection in the editor, copy-pasting from a
table became awkward. This ensures that copying (from) a table in the
editor guarantees a valid table on paste.
task-3061274
closesodoo/odoo#107544
X-original-commit: 9730a1f1e0053cc9633faaf0ffb424ae373bbc38
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Small fixup for already merged PR: 103318
stage_display column should have 'Stage' as a header, not 'Stage Display'
added the stage_display field to 'All Tasks' list view
Task-3024152
closesodoo/odoo#107407
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
As multiple tickets can be sold in a single sale order line, we should not
display the line total amount on printed tickets but the unit price instead.
Task-3078743
closesodoo/odoo#107530
X-original-commit: 63d786e67006405140e3198543640edf4b4edb1b
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
- project.task form view - the fields
'planned_date_begin' and 'planned_date_end' are displayed after the
customer field (or after the SOL field if it exists)
Task-3046210
closesodoo/odoo#107502
Related: odoo/enterprise#34782
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
- install Calendar and Appointments apps;
- give "Access Rights" for administration to a user;
- go to calendar app with this user.
Issue:
The user does not have access to the calendar.
Cause:
The user has no access rights for the onboarding model.
Solution:
Check that the user belongs to the "group_system" group in the onboarding model controller.
opw-3083014
closesodoo/odoo#107514
X-original-commit: fa7dc387154c65ef07af1f903fa25ca5d2e890f9
Signed-off-by: Arnaud Joset <arj@odoo.com>
Since [this commit], a new option is available on the steps block to
change the style of the connectors. Unfortunately this was causing
errors in the console. This commit makes sure that we don't have these
errors in the console anymore.
Steps to reproduce the issue:
- Drop a steps block on a page
- Change the type of the connectors
=> Errors are displayed in the developer console.
[this commit]: https://github.com/odoo/odoo/commit/aba31e9f2d8a44ce1586403f2a621a6caeed57b4
task-3069766
closesodoo/odoo#107511
X-original-commit: c1805fc5d3c3eeaa5c2edca69a6b9375f4ea1a39
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Now that dashboard views have been removed, there is no reason
to keep a dedicated module with 2 custom fields that could be
in community.
* Move sale.report fields:
* invoice_status field is simply moved as is
* avg_days_to_confirm is removed, as it was only used and meaningful in the dasbhoard view
* Merge views content inside the parent view
Task-3011195
closesodoo/odoo#104920
Related: odoo/enterprise#33588
Related: odoo/upgrade#4010
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently there is a bug where the Chart of Accounts is not translated if the language is installed after the CoA.
Steps to reproduce:
1. Create a CA company (where both French and English are used)
2. Set the CA Chart of Accounts
3. Go to the general settings
4. Add the French language and switch to it
5. Go back to the CoA
6. The CoA is not translated
This is because the variable `installed` is wrongfully placed in the code. In the current flow, we install the new language, then we check the installed language, therefore the new language is marked as an already installed language. Therfore the `to_install` variable will always be empty.
This commit fixes this by first storing the already installed languages, then installing the new one, and then compute the ones to install making sure that the newly installed one will be used afterwards to translate the Chart of Accounts.
task-id 3091315
closesodoo/odoo#107500
X-original-commit: a3c3c3ccfc8e769ce39dbf38263f92e449b44abb
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
When there is not enough recipients for the A/B testing percentage,
we pick a minimum of one recipients (if there is at least one) to
avoid sending a/b test to no one.
task-2713198
closesodoo/odoo#107488
X-original-commit: e1fa7b10250efc790452f02490ab84d2183698ff
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit
- When we were comparing versions, there was no such filter as
mailing type. Due to this it will display both SMS and mail
type records in it.
With this commit
- We have added '('mailing_type', '=', self.mailing_type)' in domain
of compare version.
TaskId-2713198
X-original-commit: e8542e24597ad25b68104c03d4d4ed41e1efac82
Part-of: odoo/odoo#107488
Before this commit, the A/B testing cron was active by default.
It doesn't matter if A/B testing is true or false in settings.
So, with this commit, we set active equals to false by default
in the A/B testing cron. It will be active when the user sets
`group_mass_mailing_campaign` to True.
TaskId-2713198
X-original-commit: b348f8658f87c15d0fe4ee72888e99da2a529700
Part-of: odoo/odoo#107488
In website, clicking on the snippet option action "Relpace" did
not work for an icon inside s_social_media as s_social_media is
contenteditable false.
The code was simulating a double click on the icon to open the media
dialog but in the double click handler, a check is made to prevent
the media dialog to be shown if the contenteditable is false. This
is important for the knowledge app to prevent changing a button inside
a knowledge view.
task-3086881
closesodoo/odoo#107487
X-original-commit: 3339c50fbebca8a6d419df4ab14ef03952ea6635
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Comment nodes don't have a `closest` method so when passing one to
`closestElement`, the method crashed.
----
Step to reproduce in website:
- Go to debug mode and to website app
- Click on configuration > websites
- Select a website and in the `custom_code_footer` field add an HTML
comment
- Go to the website and try to enter edit mode -> Crash
The same error will be visible if you simply enter edit mode and drag &
drop the "Code" snippet and enter an HTML comment inside it.
-----
Step to reproduce in marketing automation:
- Install marketing automation
- Click on a campaign > Add a new activity
- On the mail template field, type something > Create and edit
- Select plain text -> `element.closest is not a function`
----
task-3083797
opw-3081323
opw-3081278
closesodoo/odoo#107486
X-original-commit: 3a9177dd6a6f12f75d0df8146b692e3486f2467c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce the bug:
- install “mrp_mps”
- Create a storable product “P1”
- routes: Manufacture + MTO
- make sure there is no BoM set
- Go to “Master Production Schedule”:
- Add the product “P1”
- Add a quantity and click on “Replenish”
Problem:
A User Error is triggered with the following message: `The unit of
measure Units defined on the order line doesn't belong to the same
category as the unit of measure False defined on the product. Please
correct the unit of measure defined on the order line or on the product,
they should belong to the same category.`
The `compute_qauntity` function is called to convert the qty into the
UoM of the BoM, but since there is no bom, an empty record is given as
a parameter:
https://github.com/odoo/odoo/blob/8c5fb8b71538462422c8f166b772b5e316ecd6b5/addons/mrp/models/stock_rule.py#L122https://github.com/odoo/odoo/blob/0f91970020af640faa3a06369fa888315f83f98f/addons/uom/models/uom_uom.py#L215
opw-3085227
closesodoo/odoo#107476
X-original-commit: 7d0df9035cf603ed25ef88a3cf99ed89aef6771e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the issue:
- Let's consider two currencies C1, C2
- Let's consider two pricelists P1 in C1 and P2 in C2
- Let's consider that the current company CY has the default currency C1
- Let's consider that the current rate of C1 = 1.0 and C2 = 5.0
- Create a shipping method SM with fixed price = 50 and free shipping is above 100 (expressed in company currency)
- Create a SO with P2 and add a line with a product of 200 C2 (equal to 40 C1)
- Add shipping method SM
Bug:
The shipping was considered as free but the total of the SO was not above 100 in the currency of the company
opw:3010266
closesodoo/odoo#107456
X-original-commit: c93ab6615f0370963b152cc0320478fe4ceed164
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce:
Create a MO without product_id, then add a new line in work orders.
Error raises.
Since cab8d8fe7f744fb4dd0cd61b624f6f4519eb8d8d, we started to show
qty_remaining of WO on MO form. It triggered the compute function of
qty_remaining. Since we don't set product_id, production_id.product_uom_id
is not provided when doing the calculation.
To fix, add production_id.product_uom_id as dependancy of qty_remaining,
and don't do the calculation without it.
opw-3092723
closesodoo/odoo#107434
X-original-commit: 0b10241c0bcbecda73dae04c8a5f1ceb8033a388
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
Steps to reproduce the issue:
- Go to the website shop
- Select a product which allows custom features (eg. Customizable desk)
- Select custom and enter a value
- Add to cart
Issue:
Neither the modal preview nor the cart of the added item doesn't show the custom value, also it
doesn't appear in the created sale order
Cause:
The optional sale_product_configurator module hasn't implemented it
opw-3052987
closesodoo/odoo#107335
X-original-commit: 954653062ad6060babb77a712b269337b479fa65
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce:
- Install modules `l10n_din5008_sale` and `sale_management`
- Activate the language `German/Deutch`
- Create a new quotation
- Set a customer with `German/Deutch` as language
- Add a product then print the quotation
Issue:
Some sentences are not translated.
Cause
Missing translation files.
opw-3052426
closesodoo/odoo#107454
X-original-commit: 6b990318a142fe83009a54cd967f4d23ef939327
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce :
- Create two products
- Create a planned internal transfer with one of each product from Stock
-> Location A
- Hit "Mark as todo"
- Hit "Put in pack"
- Validate the picking
- Create an new planned internal transfer, with the same products and
quantities, but from Location A -> Location B
- Remove the destination package for one product.
- This will remove the destination package for all products in the same
package.
When unlinking a package level, it will unlink all moves and move_lines
at the same time. Problem is that if a single move_line is updated in a
picking where multiple move_lines are in the same package, it will
unlink it for all the move_lines instead.
closesodoo/odoo#107448
X-original-commit: 9dcbc420f50ece3356dff57cbdc467c7893ff2c2
Signed-off-by: Tiffany Chang <tic@odoo.com>
Changing the bank account on the bank journal led
to a traceback (expected singleton on currency_id)
when trying to open the reconciliation widget.
This is because we are trying to open a blank line
as the origin line was linked to the origin Bank account,
therefore there is no currency_id.
It has been decided to filter the statement line that
match the bank account and to adapt the action button.
Steps to reproduce:
- Create a bank statement line
- In Bank journal, change the Bank Account
- From Accounting Dashboard, click on "Reconcile X items" or
just open the Bank Journal
-> Traceback (expected singleton)
opw-3085670
closesodoo/odoo#107441
X-original-commit: c566a48c5bc528a140e6f29399ca1fbcede60490
Related: odoo/enterprise#34762
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
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
niyasraphy