**Before this commit**
Since [1], the signature field only display placeholder
signatures when it has a value.
**Explanation**
The commit [1] removes the props "value" from the standard field props.
The signature field missed an adaptation.
**After this commit**
The issue is fixed and a test has been written.
[1] 688986f888
opw-3335655
closesodoo/odoo#123463
X-original-commit: 4edc5e3326cc92e9adf4f2512af1e85382108bb3
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before this commit, 4 different usecases where considered when
computing the value of an x2many field to put in the evalContext:
1) evalContext to evaluate a context used client-side
2) evalContext to evaluate a context used server-side
3) evalContext to evaluate a domain used client-side
4) evalContext to evaluate a domain used server-side
For 1, 3 and 4, the value of the x2many was the list of ids in the
relation (in the case of one2manys, new, virtual, ids were filtered
out). For 2, the value was a list of commands. This doesn't make
much sense, and doesn't appear to be used. This has likely been
encoded when we developped the new views in v11, when we kind of
reverse engineered the specs.
As we are currently rewritting the BasicModel with a new version of
onchange, where the semantics of x2many commands change, this old
spec makes even less sense. Indeed, the new command semantics only
encode what has changed, whereas currently the commands encode the
whole value of an x2many, like if it was recreated from scratch.
We thus decided to simplify the evalContext logic by always
evaluating x2manys to the list of (existing) ids in the relation.
Part of task 3179751
closesodoo/odoo#123439
Signed-off-by: Géry Debongnie <ged@odoo.com>
When all accounting features are enabled manually (it should only be
enabled through the installation of the Accounting app), trying to
display the settings of Invoicing will raise an error.
This is because the `block` with `id` `accounting_reports` should be
displayed but has no content.
opw-3257708
closesodoo/odoo#123431
X-original-commit: 74fa5d5418e14e35dec68caa3c5de875c12bd4ce
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Adding a new view with Client Actions in settings
available by the technical menu
taskId : 3339472
closesodoo/odoo#123419
Signed-off-by: Géry Debongnie <ged@odoo.com>
before this commit, if the translation import is failed,
in the log it shows "unsuccessfully imported"
after this commit, the logger message is improved and
show file import failed
closesodoo/odoo#123364
X-original-commit: a7680426edfe7a8980a997c2947e05331254897b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
AssertionError: convert amount from unknown date
The problem occurred when removing the default value of 'Order Deadline' and
selecting a product before saving the record.
After applying this commit will fix this issue.
sentry-4175826548
closesodoo/odoo#123224
X-original-commit: 0314edf028acf7365804028f0f3ef6123b6ae321
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This PR refactors the public livechat in order for it to use
owl and to rely on the discuss components as much as possible.
task-2212347
closesodoo/odoo#122834
Related: odoo/enterprise#41636
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit updates the tour service so that triggers/actions can
be run in a shadow DOM.
In order to configure the tour to use the shadow DOM, the following
configurations options are added:
- `shadow_dom` on the tour configuration. This key must be
a valid selector matching the target shadow host element. All triggers/
actions of the tour will then be performed in its `ShadowRoot`.
- `shadow_dom` on any step of the tour. This value could either be
a valid selector matching the target shadow host element or false.
The behavior is the following:
- undefined: the step inherit the `shadowDOM` configuration from its
tour.
- string: the step triggers/actions will be performed in the
`ShadowRoot`related to the host matching the given selector.
- false: the step triggers/actions will be performed in the light
DOM.
part of task-2212347
Part-of: odoo/odoo#122834
Issue:
Html fields cannot add company_dependent
Cause:
Neven have html type for company property
Solution:
Add html type inside ir.property
closesodoo/odoo#121243
Signed-off-by: Rémy Voet <ryv@odoo.com>
Currently, when using a promotion with a reward available only on specific products and having a
maximum amount allowed, when adding another product with a negative amount, the discount could go
above the maximum discount allowed.
This was caused by the calculated discount amount that was overridden by the total amount of the
order. This new amount was then used to calculate the discounted factor. So, instead of having:
discount_amount = product_price * min(1, (max_discount / discountable))
When the total_amount of the order was under this discountable, we had:
discount_amount = product_price * min(1, (max_discount / total_amount))
Instead, we should calculate the discount amount normally but limit it to the amount_total.
opw-3217369
closesodoo/odoo#123361
X-original-commit: 977f726b67f48d4b858b1a5fe1d558a64186d332
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
When you create a new website, the contactus page have default action
("Send an Email"). For each action, there are mandatory fields that
cannot be deleted by the user. Unfortunately, the template for the
`/contactus` form didn't have the right fields marked as mandatory.
This led to the following bug:
- Go to `/contactus`
- Edit the page
=> The Email and Subject fields can be deleted. However, when you drop a
form and set the action to "Send an Email", these fields are mandatory
and cannot be deleted. This commit fixes this bug by ensuring that these
fields are marked as mandatory on `/contactus`.
task-3302433
closesodoo/odoo#123360
X-original-commit: 09a9cff6af44157c760c4f3d95d478f10d5c2411
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
1.
Infinite loop may happen on using `parent_of`\`child_of` when there is a
recursion in the tree (e.g. a record is marked as a parent of itself). Fix it by
excluding seen records from the next iteration.
2.
Another problem with `child_of` is `parent_id` that references to another model.
For example, the `parent_id` may come from inherited model. It's the case with
`res.users` and `res.partner` models. It may lead to a random search results.
Avoid that by raising exception in case of wrong usage of the `child_of`
operator.
STEPS:
In demo data, there is a partner called "Wood Corner" that is `res.partner(9,)`
that has 3 sub-contacts. If we give Portal access to two of them, we end up with
a database, where we have a `res.users(9,)` record that has a partner, which has a
`parent_id` to "Wood corner". So this way, the user id is the same as the user's
partner's parent contact id.
After that open a shell and type:
```
env['res.partner'].search([["user_ids", "child_of", 9]])
```
BEFORE: infinite loop (without change n.1) or random search results (when change
n.1 is applied)
AFTER: ValueError exception
---
opw-2729740
closesodoo/odoo#123353
X-original-commit: 2e1adc0c3e33fcf7989d27bb4d1c2e3c019faf2b
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
This prevents from having files floating in the root folder and making
the navigation between subfolders more complex.
Part of task-3265211
closesodoo/odoo#123344
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Typing a valid URL and pressing Space creates a clickable link with that
URL. Users expect the same to happen when pressing Enter instead (with
or without holding Shift), but that was not the case previously.
This commit enables link creation with both Enter and Shift+Enter. It
factorises the code that creates the link into a function
`_handleAutomaticLinkInsertion`.
While this feature is part of the `keydown` event for Space and
Shift+Enter, it is part of the later `input` event for Enter (without
Shift). This is due to a required call to historyRollback(), which would
undo the just-created link, forcing its creation to be delayed.
Two tests have been added for these new use cases. For the Space use
case, an existing test has been adapted to account for the change of
handling (from `input` to `keydown` event). That test is also simplified
to avoid modifying the DOM content (which was meant to replicate the
exact behavior of the browser for regular users, deemed not necessary
for tests).
Task-3094666
closesodoo/odoo#122001
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit's purpose is to take into account the down payments for the
project profitability of the project update window.
Currently, if an SO has a total of 300$, and a down payment is created for 100$, the project
profitability will not compute the 100$ into the 'amount_invoiced'
column. After this commit, it will. A negative value of -100 is also
added in the 'amount_to_invoice' column in order to keep the total of
that column, and the total of the 'expected' column of the project
update consistent with the total of the SO.
task-3204827
closesodoo/odoo#116293
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
*: website_event_booth, website_event_exhibitor, website_event_track
Before this commit, when no events (or exhibitors, tracks,..) were
displayed for the user, only a title (eg. "No events found.") was shown
to them.
Now, it will display an illustration (color adapts to theme's color)
alongside more information:
- title
- call-out
- call-to-action for editors (add event, tracks, exhibitors..)
task-2489681
closesodoo/odoo#107638
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When we enter an integer in a field and the value cannot be encoded in
32 bits, an error is thrown but the field is not marked as invalid
Steps to reproduce:
1. Install Employee Referral
2. Go to Referrals > Configuration > Levels and create a new level
3. Add a name and an image and set the requirements to 9,999,999,999
points
4. Try to save the level, an error is thrown (in v15, a notification
would inform the user the field is invalid)
Solution:
Throw an error in parseInteger when the value exceeds the 32 bits
encoding limit
Problem:
PostgreSQL uses 32 bits for integers
opw-3300851
closesodoo/odoo#123401
X-original-commit: c662a54606799cf3348aed84584e75d2ab6f20e5
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Go to Email Marketing, open a record with status "draft". Directly
when the record opens, and before the html field is loaded, click
on another menu or on the breadcrumb to leave the view. Before this
commit, it crashed because the HtmlField tried to perform an RPC
after being destroyed.
opw~3297859
closesodoo/odoo#123381
X-original-commit: 3e8d2c7006b16738cdab7442a7135ae7f1c60da9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#123372
X-original-commit: 031cd0e37a156dc776c858fa9e868fd4dda74416
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce
==================
- Open a product form view
- Enter .5 in the Cost field
It is parsed as 5 but it should be 0.5
Cause of the issue
==================
When trying to strip the currency symbol from the input, the leading
decimal separator was also removed
Solution
========
The decimalPoint can have multiple characters.
This means that we can't simply add the decimal separator inside the negated
character class.
Instead, what we can do is skip everything until we find a interesting
substring. (more details in the comment)
We then remove everything that is not a digit at the end.
Finally, we can pass that to `parseFloat`
closesodoo/odoo#123358
X-original-commit: fa466d75da3b30ac1e512a95436075ef1461a95c
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
When invoicing the first time to a customer, the user can choose a style layout for the invoice.
The 'Striped' laoyout is a little bit different when we configure it and preview the pdf than when using it in an actual invoice.
This commit make the layout preview more accurate in relation to the real invoices.
Comment that led to the task : https://www.odoo.com/web#id=3232301&menu_id=4720&cids=1&action=333&active_id=809&model=project.task&view_type=formclosesodoo/odoo#123354
Task: 3236310
X-original-commit: 1852143a9cc56ec1ac9b8cfec5835fdc010fe7ab
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: hupo-odoo <hupo@odoo.com>
While creating redirects/rewrite if the user does not enter any url in the
'Url to' field of the website module under 'Configuartion/Redirects' then during
redirection, the error 'NotFound: 404 Not Found: The requested URL was not
found on the server' will be produced.
Applying this commit will solve the issue.
sentry-4206504892
closesodoo/odoo#123391
X-original-commit: 14a850976711431f36b7f889ea9cf31b1114513d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Saurabh Mishra (sami) <sami@odoo.com>
Issue:
------
Since commit 3f145af00307383e2d0a0891d05b8db59b13662a
Some events that belong to a recurrence and
have been modified are not detected as existing.
The `full_recurring_event_id` method blocks these events.
Solution:
---------
Test regex expressions before using them.
opw-3344408
closesodoo/odoo#123333
X-original-commit: f34fa6e905b9426be8040d4e021f1849b3373184
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
A float division by zero error is generated on the log, and nothing
is imported from the file when the user uploads an XML file like
https://drive.google.com/file/d/1_eZYfqMk2kLtPsEjv-13DRHnmoXkWYeE.
This is because here in LineID 1, there is a value billed quantity is 0.0,
a charge amount is 0.0, and a total amount is 100.0. This is wrong;
the total amount is always 0.0 when the billed quantity is 0.0
(billed quantity * charge amount).
This commit solves the above issue by dividing a price subtotal
by one when the billed quantity is zero.
sentry-4157357719
closesodoo/odoo#122142
X-original-commit: 3a6e84d6733145f38184c473de4a1aa41464b1fa
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Ansari Mahamadasif (maan) <maan@odoo.com>
When the route to your file contains more than one argument, the
arguments following the first one are not taken into account. The
arguments that are after '&' symbol are considered as a arguments of the
route 'viewer.html' and not of the 'file' route.
To avoid this issue, we are encod the file route in URI, as documented
in https://github.com/mozilla/pdf.js/wiki/Viewer-optionsclosesodoo/odoo#123355
X-original-commit: 86a4fcf4647c9c6006b69c35d76bf80d87204114
Related: odoo/enterprise#41815
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Masereel Pierre <pim@odoo.com>
Due to an unexpected positional parameter given in the
function call, no document could be generated
closesodoo/odoo#123376
X-original-commit: 2c5a2ca48d855ddbe89da770d97c52416818040d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Currenlyt, when using dark theme, spreadsheet is a mess. It's mostly
light theme, with some dark theme elements (mostly coming from odoo
components). There's even inputs where the text is white on a white
background.
o-spreadsheet code isn't prepared to handle dark theme. At all.
There are hardcoded colors everywhere.
Until we have a proper way to handle dark theme (use overridable scss
variables, rely on bootstrap), we force light theme for all elements
inside o-spreadsheet, including odoo components.
The css rules aren't pretty, but at least the spreadsheet is usable.
opw-3329765
closesodoo/odoo#123359
X-original-commit: 37a5f6a5b4b8ecbacf7a8ce4be822c6f348eb5da
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Currently, when we create a draft move in an empty period, a sequence
number (name) gets generated and set on the move. This is fine.
When subsequently we change the date of that move to a period that
already has entries in it, the sequence number (name) for our draft move
is recalculated according to the new period.
When we post a new move in this same period afterwards, and then
delete our previous draft move, we are left with a gap in the sequence.
Example: We already have a move on 2023-01-01 with name `2023/01/0001`.
We add two new moves `A` and `B` as follows.
| Step | Move | Action | Date | Name |
| ---- | ---- | ----------- | ---------- | -------------- |
| 1 | `A` | Add | 2023-02-01 | `2023/02/0001` |
| 2 | `A` | Change date | 2023-01-10 | `2023/01/0002` |
| 3 | `B` | Add | 2023-01-15 | `/` |
| 4 | `B` | Post | 2023-01-15 | `2023/01/0003` |
| 5 | `A` | Delete | | |
A gap is now created, since we have `2023/01/0001` and `2023/01/0003`,
but `2023/01/0002` was deleted (possible since it was in draft).
To solve this issue, we now make sure that when a draft entry is moved
to a period that already has entries in it, we reset the name to `/`,
to not consume a sequence number and prevent possible gaps in the
sequence later on.
task-3326834
closesodoo/odoo#123329
X-original-commit: 31f94b31b820799459ad70593abb74a2f5415b47
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
The 'view_partner_bank_search_inherit' is inherited from 'view_partner_bank_search' and it is using replace value of position attribute. This is not letting the fields already added in the base view to display.
Steps to reproduce:
1. Go to Bank Accounts in Contacts' configuration.
2. Try to enter some value in search field.
Current Behaviour:
The search field will not work properly and will not even display the columns to search.
Expected Behaviour:
The search field should display the columns and search the table.
OPW-3340543
closesodoo/odoo#123328
X-original-commit: 6371bc5ce85f728fcaa6561bad4bef1aba161687
Signed-off-by: William André (wan) <wan@odoo.com>
Since [this commit] which allows to have mega menu with transparency,
the user can see the color of the block which is positioned at the very
top of the page (behind the mega menu when it is open). Before that,
the gap was always gray.
Steps to reproduce the bug
- Have a mega menu on your site
- Put a block on top of the page
- Put a red background color on this block
=> When you open the mega menu, you can see the red color between the
mega menu and the navbar.
[this commit]: https://github.com/odoo/odoo/commit/147f99bb04f83943aaedbacb1844234288e60eaf
task-3327094
closesodoo/odoo#123312
X-original-commit: dba1dac5d0b09e999e194debcb5907affca61bd7
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
A new validation was recently added to prevent importing
reserved quantities on stock move lines, to prevent inventory
discrepancies [1]. However, such validation inadvertently introduced
another issue, which is now, if the reserved quantity is not filled with
0, the new validation is triggered.
This commit fixes the above issue by not requiring the reserved quantity
to be provided.
In addition, a typo is fixed in the error message:
"it is not allow" -> "allowed"
[1] odoo/odoo#119201
X-original-commit: 79f825537aa6bed8cbcd7d7edab07ea0cb80a7cd
Part-of: odoo/odoo#123287
*: gamification, hr, hr_contract, hr_expense, hr_holidays, hr_org_chart,
lunch, mail, web
Since the Milk refactoring, the backend uses only `.rounded` avatar
images. The `.rounded-circle` classes on images have been replaced by
`.rounded`.
task-3336569
part of task-3326263
closesodoo/odoo#123286
X-original-commit: b492049788353274fb32bb6fbe4d40e97a184a87
Related: odoo/enterprise#41798
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
as Adyen sends the same notification data for POS and online payments
that can not be distiguished, the webhook controller logs a stacktrace
for every POS payment. If the payment_adyen is installed it generates
noise in logs as the POS transaction can not be found in online
payments. To clear the log we make missing transaction as warning to
not log the stacktrace.
task-2960381
closesodoo/odoo#123282
X-original-commit: 4754895ac7901c497f33a6bf9be6d18c0b4b55d8
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Valeriya Chuprina (vchu) <vchu@odoo.com>
The report_stock_quantity model defines a view in its init method
to compute quantity information related to stock. This view
is made of two CTEs and a three-part query separated by UNION ALL.
The first CTE, existing_sm, retrieves the stock_move data
from the database that are later used by the remaining of the query.
One of the where conditions of existing_sm is (m.state != 'done' or
m.date >= ((now() at time zone 'utc')::date - interval '3month')).
m.state != 'done' is translated to m.state <> 'done' by the query planner.
This type of operator has the side-effect of turning off index scan.
Therefore, the scanning of the existing_sm CTE performs a Seq Scan
and applies the where conditions in a Filter node. This can be quite
ineffecient if the stock_move table is big, and if the selectivity
of the m.state != 'done' condition is high enough to theoretically
justify an IndexScan.
To fix that, we take the inverse of m.state != 'done', i.e. an IN cond.
This allows postgres to use Bitmap Scan, which
is usually better under these specific conditions.
E.g. speedup: db with 7M stock_moves, select from report_stock_quantity
with conds for state, date, product_id, warehouse_id, company_id
4.5s -> 2.5s
opw-3288364
closesodoo/odoo#123221
X-original-commit: aad458e5c5ecf8e843bbe8ddb7710b93eb95b362
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Van Delft Aurélien (avd) <avd@odoo.com>
Before this commit, when a snippet section was hidden on mobile devices
and its height was then set to 50% or 100%, the visibility classes
remained as "d-lg-block" instead of "d-lg-flex". This inconsistency
resulted in the content not being vertically centered until the "hidden
on mobile" toggle was turned off and then back on.
Steps to reproduce the bug:
- In edit mode, drag and drop a "Text" snippet onto the page.
- Click on the "Mobile visibility" option button to hide the snippet on
mobile devices.
- Click on the "50%" button in the "Height" option of the snippet.
- Bug: The content within the "Text" snippet is not vertically centered.
This commit fixes the issue by properly updating the CSS class set by
the mobile visibility option when the "height" option is enabled.
task-3224575
closesodoo/odoo#123135
X-original-commit: 0377b035eff80baec3f78ea984e12ad1422dbf7a
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
Adding methods to trigger the cash drawer opening as well as a log in
the message to state by who and for which action the cash drawer was opened.
There is also a log now for when in an action for which the cash drawer
was opened is canceled. The action concerned are: Cash control at opening,
cash in / out, Cash control at closing.
task-3293113
closesodoo/odoo#121110
Signed-off-by: Monnom David (moda) <moda@odoo.com>
When user create a pos category from 'restaurant.printer' model in
'pos_restaurant' module. it will give an error with the
message -
'sequence item 0: expected str instance, bool found'
Steps to Produce:-
1. Install 'pos_restaurant' module
2. Go to 'point_of_sale' module
3. Go to 'Configuration' -> 'Order Printers'
4. Click on any printer or create new
5. Under 'Printed Product Categories' click 'Add a line'
6. Click 'New'
Trace-back will be generated.
Applying these changes will resolve this issue.
sentry - 4072172292
closesodoo/odoo#123247
X-original-commit: c99090d4b70f293d3784c19511d0a1f3078e3d9c
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Preksha Chouhan (prec) <prec@odoo.com>
Previous commit (https://github.com/odoo/odoo/pull/116570) renamed
this method _get_subtasks_recursively.
But instead of calling itself in the return statment, the
method _get_all_subtasks was called resulting in a non-recursive
function and to potential undesired behavior as _get_all_subtasks calls
_get_subtask_ids_per_task_id that calls _get_subtasks_recursively in
some cases.
With this commit, we just call _get_subtasks_recursively on the children
to make it actually recursive, like it was in the first place.
closesodoo/odoo#123149
X-original-commit: 3a6f5e4d8eddaa4effbf96d8b59d47afc0ee9503
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Audric Onockx (auon) <auon@odoo.com>
ValidationError: PayPal: Missing value for txn_id (78X739757D473425R) or
txn_type (None).
This issue occurs when there is some missing value in the received
notification_data while evaluating the '_process_notification_data' function.
It raises an Exception which will be caught by the sentry.
sentry-3954375754
closesodoo/odoo#123191
X-original-commit: 8c539133f374ad709b5ed7770b15a3233e2463b2
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, im status icon for "away" was brown
in white mode.
This comes from MILK redesign change changes the color of
`text-warning`, from yellow to brown in white mode.
This commit fixes the issue by explicitly using yellow color,
regardless of theme. Dark mode kept the yellow color, so this
is unchanged.
closesodoo/odoo#123188
X-original-commit: d500608c01370ffb712ea45ce3f6b58e706ed760
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Two issues solved in 1 commit; as their solutions depend on one another.
** ISSUE 1 **
To reproduce the issue, on a l10n with a tax report:
- Create a misc operation with a tax on it in the same form as a sales invoice ; post it.
- Reverse that move, and post the reverse.
=> Open the tax report: the amounts of the original move (for both tax lines and base lines) are doubled.
That's not what we want ; instead, the reverse should have entirely canceled the original move.
This is due to the fact the is_refund field of account.move.line is badly computed on the reverse: both tax and base lines are considered refund. Because of that, tax_tag_invert gets inverted, and ends up doubling the amount in the report instead of cancelling it. While made on a reverse move, those lines should not be considered as refunds, since they must both use the original repartition of the reversed move , unlike invoices, which would make use of the refund repartition in this case.
** ISSUE 2 **
To reproduce, on a l10n with a tax report:
- Create a cash basis tax, and set tags on its repartition lines so that it should be taken into account by the report. Make sure the refund repartition cancels the invoice repartition.
- Create an invoice using that tax, post it
- Click the "Add Credit Note" button, select "partial refund", and post the generated refund (which will cover the full amount of the original invoice)
- Reconcile the refund with the invoice
=> Because it's a partial refund, cash basis entries will still be generated. Open the tax report to ensure they sum up to 0... And the tax lines don't !
This happens because the computation of tax_tag_invert field inverts the sign of tag on cash basis entry tax lines when they have a negative tax_base_amount. In our case, when going through the "reverse" button and making a partial refund, we actually do get a negative amount in the credit note's tax_base_amount. This is inconsistent with what a refund generated from scratch does (then, you'll get a positive tax_base_amount in our case), and should only be legit when the document contains a negative line explicitly (so, a line with a negative quantity, hence inverting the meaning of debit/credit).
The root of the issue is that the tax_base_amount of the tax line uses the tax_tag_invert of the base line to define its sign. And tax_tag_invert was omitting to set copy=False. When reversing a move, the first step is to copy it. Because of the missing copy=False, tax_tag_invert was copied, and never recomputed (since it's a computed editable field) on the base line, giving it an inconsistent value, and ending up inverting the sign of tax_base_amount on the tax line. In turn, the tax line got a wrong tax_tag_invert because of that, and would propagate that to the cash basis entry when generating it.
This commit adds the missing copy=False to tax_tag_invert, but also fixes the computation of tax_tag_invert so that in does not rely on tax_base_amount anymore. This way, existing data will also benefit from the fix without having to recompute the field. Additionnally, there are currently plans to remove tax_base_amount in master, so this would have had to be done eventually anyway.
======
Forward-port note:
In 16.2, https://github.com/odoo/odoo/commit/84d7aab94e2984a81923f0546e24caf54cd53033 actually wrongly inverted the sign of the Mexican withholding tag in repartition lines. Those taxes are negative, so a tag needing to get the retention amount in positive must be negative itself. The bugs fixed in this commit shadowed the problem, and this fix reveals it. A fix of the tags's signs was added into this forward-port.
OPW 3255511
closesodoo/odoo#123187
X-original-commit: 688ab4d6688ccd2377ea9702c00b1ec16f99527a
Related: odoo/enterprise#41748
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
In a Kanban View, the container in which elements are dragged is a `d-flex`
element, and as such it has the `overflow: visible` css property by default.
This means that if there are more groups than the current dimensions of the
viewport allows for, those groups will overflow outside the dimensions of the
container, preventing elements from being dragged outside.
Therefore the dimensions of the draggable area should consider the container
`scrollWidth` and `scrollHeight`, as these values take into account the
dimension of overflowing elements.
task-3339978
closesodoo/odoo#123167
X-original-commit: b14f195a426183894dcd37d9776807114e8e05ef
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Abeloos Damien (abd) <abd@odoo.com>
The issue occurred when a loyalty program's rule was set to be
based on money spent, and the reward was a free product with a
sale price of zero. This caused a zero division error in the code,
resulting in the remaining points becoming NaN after the reward
was obtained in the point of sale.
opw-3253366
closesodoo/odoo#123123
X-original-commit: 1eaca074741157e42c12da22e945a1817e7ceec3
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Bruno Boi