Make sure not to remove inline styles when emptying an element.
task-3102841
X-original-commit: 8d0397c99798f05a41276d62a66f47c41f255ef8
Part-of: odoo/odoo#116558
Community PR: https://github.com/odoo/odoo/pull/91187
## Proposed feature and relevance
Add a new retrieval strategy for gathering products: "Least packages".
The goal of this strategy is to select specific product quantities from stock by using as few packages as possible, to allow for efficient logistics operations and avoid unnecessary opening/unpacking of packages.
This strategy will behave as follows:
- In case a negative qty is requested this strategy will behave as a FIFO strategy.
- Otherwise, the strategy will determine a combination using the least amount of packages that sum to the requested quantity, and adapt the provided domain to select only the quantities in these packages. This way no packages need to be opened to select the requested quantity.
- In case an exact matching of current packages to get the requested quantity is not possible, a selection of packages is made where the largest packages are selected one by one until the requested quantity is reached, or until no more quantities are available. For this approach, one package needs to be unpacked as it will not be used completely. The final selected package that will be unpacked will be the smallest one possible, to try to unpack smaller packages over bigger packages.
- In case the search for a minimal matching of packages results in an out-of-memory situation, the strategy will fall back to a FIFO strategy.
- Loose items (not tied to a package) are considered as single-item packages for the purposes of package selection.
- **NOTE:** To force the selection strategy to "clean up" certain packages that have previously been opened, it is recommended to unpack these packages into single items, as they will then be consumed to "fill up" requested quantities in later retrievals.
## Changes to allow more complex strategies
To allow for the integration of this new strategy the structure of `_gather()` needed to be adapted to allow a removal strategy to provide not only the SQL `ORDER BY` string but also adapt the domain used to retrieve the requested quantities.
This change is reflected in the method signature of `_get_removal_strategy_domain_order()`.
## How the strategy works
The strategy does one extra query of the database, to determine the different packages and their respective quantities (using the provided domain).
Loose items (that do not belong to a package) are added as single-item packages to also consider them.
For minimal exact package selection, an A* algorithm is used with 2 performance modifications:
- Using the information that the packages are sorted by size (large -> small).
- Using the information that the generated subtree for a specific package of size x is the same as all other packages of size x at a specific node.
By using the A* algorithm, as soon as a matching packaging selection is found, it is ensured to be optimal and other combinations do not need to be considered.
In case the A* algorithm runs out of memory the provided domain is just returned, which equates to a FIFO strategy.
In case the A* algorithm does not find an exact matching of packages for the requested quantity, a selection is made using the least amount of packages, unpacking the smallest possible package (or until no more quantities are available, in which case effectively all quantities in the domain are returned).
## Used heuristic
The heuristic used for the A* algorithm exploits the knowledge that our packages to select from are ordered by the highest to the lowest quantity (on the database side, SQL `ORDER BY`).
It assumes the "best case scenario" as an estimate for the amount of packages remaining, which is if we were to "match" the required quantity using fractional multiples of the next biggest package size.
***Example**:
Remaining quantity to select: 27
Remaining package sizes to select from: [10, 10, 5, 5, 5, 1, 1, 1]
Heuristic for choosing package with qty 10 as next package: 27/10 = 2.7
Heuristic for choosing package with qty 5 as next package: 27/5 = 5.4
Heuristic for choosing package with qty 1 as next package: 27/1 = 27*
This way the heuristic is always a "best case" (fractional) for the amount of packages that still need to be selected.
As required by the A* algorithm this also results in an underestimation as the fractional result is not possible, and it is not certain that there are still enough packages of this size that can actually be selected, but favours larger packages to make the search converge more quickly.
## Performance
### CPU
Two test cases were run to evaluate the performance.
***Total nr of pkg**: The total amount of different packages generated during data generation
**Qty to select**: The total quantity that needs to be selected
**Selected nr of pkg**: The amount of packages that was ultimately selected by the algorithm
**Data generation time**: The time required to generate all packages
**Assignment time**: The total time to run `_action_assign()` for the move
**A\* time**: The time to run the `_run_least_packages_removal_strategy_astar()` method*
#### First test case
This scenario simulates a case with a large quantity to select from a large amount of packages, but of relatively homogenous size.
Generate 30 different package sizes between 2 and 1000. For each package size, generate 100 to 250 packages each. Also add 100 to 250 "loose items".
The quantity to select is chosen between 1 and 50000.
| RESULTS | RUN 1 | RUN 2 | RUN 3 | RUN 4 | RUN 5 | AVG |
|--------------------------|----------|-----------|------------|-----------|----------|------------|
| Total nr of pkg | 5298 | 5772 | 5855 | 5533 | 5179 | 5527.4 |
| Qty to select | 10319 | 20762 | 44422 | 39306 | 1783 | 23318.4 |
| Selected nr of pkg | 11 | 22 | 48 | 41 | 3 | 25 |
| Data generation time (s) | 64.59124 | 92.916682 | 133.673384 | 82.711438 | 85.54542 | 91.8876328 |
| Assignment time (s) | 4.060216 | 11.212937 | 4.763776 | 8.60248 | 3.461941 | 6.42027 |
| A* time (s) | 0.28 | 6.88 | 0.21 | 3.96 | 0.03 | 2.272 |
#### Second test case
This scenario generates a large amount of small packages of different sizes.
Generate 250 different package sizes between 2 and 10. For each package size, generate 5 to 15 packages each. Also add 5 to 15 "loose items".
The quantity to select is chosen between 1 and 10000.
| RESULTS | RUN 1 | RUN 2 | RUN 3 | RUN 4 | RUN 5 | AVG |
|--------------------------|-----------|-----------|-----------|-----------|----------|------------|
| Total nr of pkg | 2485 | 2406 | 2491 | 2555 | 2542 | 2495.8 |
| Amount to assign | 27 | 4029 | 3966 | 3049 | 1833 | 2580.8 |
| Selected nr of pkg | 3 | 411 | 411 | 306 | 184 | 263 |
| Data generation time (s) | 18.502933 | 18.692048 | 19.969955 | 19.169106 | 19.16439 | 19.0996864 |
| Assignment time (s) | 1.35635 | 7.958852 | 8.470518 | 6.300406 | 3.895457 | 5.5963166 |
| A* time (s) | 0.01 | 0.07 | 0.77 | 0.56 | 0.31 | 0.344 |
### Memory
In cases with large amounts of different-sized packages (200+ different sizes and 200+ packages required to get an exact match) the memory performance of the A* strategy might become problematic.
When lots of packages have the same size (which would be considered typical in cases where there are large amounts of packages) the specific modifications to the A* algorithm ensure that the strategy still delivers good memory performance for this use case as the tree size can be significantly reduced, even with large quantities.
### IO
This strategy only requires one extra SQL query to fetch the different quantities and their respective packages.
## Limitations
No tests for this strategy were done for non-integer quantities. In these cases the performance of the A* algorithm might not be satisfactory and another approach might be preferred.
More research could be done for specific use cases where packaged quantities are non-integer values.
closesodoo/odoo#91187
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
l10n_es localization was written in Spanish. We want the code to be fully
written in English then translated to necessary languages.
We also made taxes compliant to new taxonomy.
closesodoo/odoo#115968
Task-translation: 3235816
Task-taxonomy: 3052677
Related: odoo/enterprise#38468
Signed-off-by: William André (wan) <wan@odoo.com>
To reproduce the issue:
1. Go to Settings > Website
2. Activate "Automatically send abandoned checkout emails"
3. Click on "Customize Abandoned Email Template"
4. Template "Gamification" appears
Error: The template "Ecommerce: Cart Recovery" should have
appeared instead
The hardcoded res_id was wrong
OPW-3207424
closesodoo/odoo#116440
X-original-commit: 92a9fe972337554f8dac8bad47e911f054fb27d9
Signed-off-by: Demany Antoine (ande) <ande@odoo.com>
Current behavior:
If set an owner on a product and make a pos order with this product then
refund this order. The owner would be lost on the refund.
Steps to reproduce:
- Activate the consignment feature
- Create a product, and add some stock with a owner (e.g. "John Doe")
- Create a pos order with this product
- Refund the pos order
- Go to the stock picking of the refund, the owner is not set on the
move lines.
opw-3146749
closesodoo/odoo#116437
X-original-commit: 7f70d990b1f42d7a830cf5886637cb35d346e276
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
When printing the label of a lot, the datamatrix may overlap the
product/lot name and will overlap the 'best before' date.
To reproduce the issue:
1. In Settings:
- Barcode Nomenclature: GS1
- Enable "Print GS1 barcodes for lots [...]"
2. Create a product P:
- Name: a long name
- Type: Storable
- Barcode: 1111111111113
- Tracking: USN
- Expiration Date: True
- Dates > Expiration Date: 1 days
3. Process a receipt with 1 x P
- The serial number should be long
4. Print Labels
- To Print: Lot/SN Labels
- (Confirm)
- Format: 4 x 12
Error: the datamatrix overlaps the product name, the serial number,
and the 'best before' date
For the product/lot names, we can only improve the situation. If the
user define a too long name, the issue will still happen and nothing
can be done
For the dates, we can shorten the labels. That way, the dates will
always be correctly displayed
OPW-3193836
closesodoo/odoo#116541
X-original-commit: f175897cefd1db149e94a50882d9e7babfc6293d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Before this commit:
When we select text and take the selection to the hex input box and then try
again to add a solid color, it gives us a traceback.
After this commit:
Now it did not give traceback.
Task-2965091
closesodoo/odoo#116539
X-original-commit: 981713bd024a98f5d9099bfec8458224dac32a32
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
in the commit 763fbb1c of #101115
an assert is added for translated sized char fields
It is too strict for some legacy customized fields, we decide to remove it
closesodoo/odoo#116538
X-original-commit: 44f09e927d0f9338a42a3f121377db00cc70f714
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
Before this commit, the sub-menus that appear when the mouse hovers them
were not displayed correctly. The Bootstrap/Popper code which is in
charge of positioning the sub-menu could not work because the dropdowns
were opened manually (which is not recommended) and so, the
`show.bs.dropdown` event was never triggered which prevented
Bootstrap/Popper from aligning the sub-menu items correctly.
Steps to reproduce the bug:
- Have a long sub-menu in the last position of the navbar.
- In edit mode align the navbar elements to the right.
- Enable the option to have the sub-menus displayed at hover.
- Save the page.
=> When hovering the sub-menu, it opens on the right and overflows the
page while there is enough space on the left.
task-2904507
closesodoo/odoo#116535
X-original-commit: https://github.com/odoo/odoo/commit/03c82f6b0094c9d038b1699376d49f2846298bcd
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
After trying paying for a digital product and trying to download it
from the customer portal a server interal error occurred.
There was a confusion between the expected argument of
`_get_stream_from` wich is a record and the return value of
`search_read` wich is a dictionnary.
After this fix it will no longer be the case.
opw - 3233478
opw-3216900
closesodoo/odoo#116526
X-original-commit: 51f939267f4e101a78ffbc7eb2edc6fc279ed0c3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, the `mail.channel/seen` notification handler
would have returned if the channel was unknown.
This is incorrect since it would prevent other notifications from
the same batch from being processed. This commit fixes the issue.
closesodoo/odoo#116518
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Create a second warehouse WH02
- Let WH01 be the existing one
3. Create two storable products P_compo, P_finished
4. Create a BoM:
- Product: P_finished
- Components: 1 x P_compo
- Operation Type: "WH02: Manufacturing"
5. Create a MO:
- Product: P_finished
Error: Once the product is set, nothing defines the BoM (and
therefore the components, picking type, and so on)
When opening the MO form, the picking type is directly defined with
"WH01: Manufacturing". Therefore, when looking for a BoM, we use
that picking type as criteria -> we will not find the BoM of step 4
Notes about the fix:
- Small behaviour change: once the picking type is set, it does not
change automaticaly (whatever the BoM is)
OPW-3122384
closesodoo/odoo#116515
X-original-commit: 93381af48e20a10c3fded88f010f89cd03cc5131
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Before this commit, the discount name in the paid orders was different
from the one displayed when creating the order. This was due to the
fact that the `full_product_name` field was not being sent to the point
of sale, so the discount product name was being used instead.
This commit fixes the issue by ensuring that the `full_product_name`
field is sent to the point of sale, which allows for the correct discount
name to be displayed in the order menu.
opw-3213225
closesodoo/odoo#116473
X-original-commit: 8df45f2b50f01a9312a2513f39b467583d735a1d
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
In https://github.com/odoo/odoo/pull/105730,
we deleted `_compute_allocated_hours` method,
but it is still referenced in the description of field
`allocated_hours`. In this commit, we erase this reference.
And because it is not compute anymore, no need to specify
`store` and `readonly`.
closesodoo/odoo#116465
X-original-commit: 94f76339b6b15f60a33db5305d67a647c46c2caa
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Audric Onockx (auon) <auon@odoo.com>
In large databases with > 2M stock_move_lines, installing
the product_expiry module can raise a MemoryError because the
field_cache is overfilled by the computation of the expiration_date
computed stored field.
Adding an _auto_init for this field prevent such errors from being
raised by creating the column manually.
closesodoo/odoo#116456
X-original-commit: 8b82d3154858582f6d321bd6473557fc192af25f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, the field account was readonly on the expense sheet and
the accountants have to go thourgh each expenses to change the account.
After, we allow changing the account on the expense sheet directly.
closesodoo/odoo#116439
Task-id: 3244925
X-original-commit: 3102ec4c3b108be18ccc6856c1c235b0b37d1e00
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Detry Thomas (det) <det@odoo.com>
Before this commit:
Applying color on empty selection generate traceback.
After this commit:
Now, able to apply color on empty selection.
Task-3089214
closesodoo/odoo#116435
X-original-commit: b4793caddc52b7f4a6a3510a04604b88387e767e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
If the SO partner changes, we shouldn't use the pricelist id stored
on the session, only the new partner pricelist.
opw-3138262
closesodoo/odoo#116434
X-original-commit: 16ba84c25c107996fd0c57f4ffbeb63737601406
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Create a Credit Note, save and confirm
Go to Reporting>Invoice Analysis
Switch to Pivot view, add mesures ntaxed Total and Total, expand rows by Move.
The credit note untaxed total is correctly reported as negative, total
is reported as positive
opw-3223043
closesodoo/odoo#116421
X-original-commit: 06b1f3d0c78fc22250fc544b4c3152a58bfbe05c
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Before this commit, we could not change
the currency on invoice if related journal
has a default currency set.
opw-3226228
closesodoo/odoo#116420
X-original-commit: 7f7743470ac1309d5e047563d06362e54edb552a
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Before:
When taking a SO from the Sales app in the POS, there is no "Down payment limit".
There is either no way to check what has still to be paid. So the POS user can
charge a customer several times for the same down payment because he cannot see
if it has already been paid.
After:
When you click on the Quotation/Order list the amount left to pay is displayed.
When a down payment is chosen and a percentage is entered that is too high and
represents more than the remaining amount to be paid, a warning appears and warns
that the orderline will be adjusted to the remaining price.
closesodoo/odoo#116182
X-original-commit: 185324cc1abf1448d3db976c8e5751196baad3ee
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
To reproduce the problem:
- Install project
- Remove all tasks
- Go to settings -> Technical -> Email Templates
- Select the template "Project: Task Rating Request"
- Click on Preview
Without the fix, a stack trace is displayed. With the fix, the preview is
displayed with the message "No record for this model" for the field "Test
record".
Technical note: the error happens because error_msg was not assigned in the
compute method of that field when the reference to the record is missing or
incomplete.
Task-3196081
closesodoo/odoo#116431
X-original-commit: 1f296539210a07e0b1aed0d9d3cd736c5cb33375
Signed-off-by: Dufays Pierre-Yves (pydu) <pydu@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add a test that check recipients displayed in the template preview. This test
has been added following the fix that solves the template "partner_to" not
displayed in the preview.
Task-3196081
X-original-commit: 86a492275e56217a5edd57d99a0db7576aa91377
Part-of: odoo/odoo#116431
Main Flow Tour Mobile shouldn't require a specific `user_agent` as it
targets a small screen and not a mobile platform (iOS, Android...).
Actually, during refactoring of the tours (odoo/odoo@3a798039d6),
a confusion was made between the legacy `isMobile`, which represents a
small screen (cf. `env.isSmall`) and `isMobileOS`, which targets
"mobile" platforms (ie. iOS, Android...) independently of the screen size.
This commit applies the proper condition (isSmall) for the tours
management and removes the useless `user_agent` property. It also
removes the logic added to support custom user_agent in the Chrome
automation for testing.
closesodoo/odoo#116186
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously, the productScreen component used numberBuffer.use(), this
function has been removed in this PR :
- https://github.com/odoo/odoo/pull/112219
This removal causes a crash when in mobile mode. This is because the
productScreen component tries to reset the buffer when it is mounted
with this.numberBuffer.reset().
The problem is that in mobile mode no component initializes the buffer
in productScreen, which causes an error.
Now the number buffer is again initialized in the productScreen
component and not in its children. This solves the problem.
closesodoo/odoo#116457
X-original-commit: d317a7093c07a955abee1979ad8c3235cd16faef
Signed-off-by: Samuel Degueldre <sad@odoo.com>
1. Install [Events]
2. On [Settings], create an admin for Events (uncheck all other rights)
3. Click on Events, enter an event
3. Click on [Communication] tab, and try adding a line
Issue: accessing ir.model is blocked
Solution: Find another way
Original fix in 15.0: #112527
Fix of the fix in 15.0: #115881
Original forward-port in 16.0: #115101
This commit is fixing the original forward-port in 16.0 and includes
the fix of the fix.
affected branch: 16.0-master
opw-3163138, 3193659
closesodoo/odoo#116438
X-original-commit: 38594f13586d95c8ed74593ea368e8b51826740b
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Reproduce:
* Create a journal entry
* Add a new line
* Select account
* Select partner
The selected account is annoyingly changed/removed.
This should only be done for invoice-like documents. The account is
selected manually for miscelaneous operations.
closesodoo/odoo#116436
X-original-commit: 55826a514b0a25aff03dde2d4bc9f520fa295203
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
This issue was caught in sentry.
When we try to create or update an invoice by uploading an `.xlsx` attachment,
it raises an Error as it will go to convert it into XML tree because the
concerned LOC will check `xml` in `mimetype` of attachment which is
`application/vnd.openxmlformats-officedocument.spreadsheetml.sheet`.
sentry-3929855076
closesodoo/odoo#116343
X-original-commit: 400932b5ad89ac124bd1fa8373e21b569cf3d779
Signed-off-by: William André (wan) <wan@odoo.com>
Current behaviour:
When checking on the activities that are "Late/Today/Future", the
resulting search view doesn't apply any filter.
Expected behaviour:
If you click on "Late" activities for Tasks, then you should see
only the "Late" activities, not all of them.
Steps to reproduce:
- Install Project
- Create a project and 3 tasks for that project
- On each task, put an activity that is "Late"/"Today"/"Future"
respectively (1 activity per task)
- Click on the activity widget (top-right in the header) > Tasks > Today
- All tasks are shown, not only those for "Today"
Reason for the problem:
Since the view refactoring from
b77f60b , search filters follow an
hierarchy of inheritance to reduce code duplication. The issue is
that it's "delegation" inheritance (so the childs have a mode of
type "primary") but all their priorities are the sames, so the
algorithm for view matching (refer to documentation) matches the
parent view, that doesn't contains the necessary filters for the
activities, which are defined a few level lower in the inheritance.
Fix:
Add descending priority in the inheritance chain so we match the
lowest child when web-client requests the search view.
Affected versions:
- saas-16.1
- saas-16.2
- master
opw-3234525
closesodoo/odoo#116337
X-original-commit: 609f484
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Since [1], the `temporary_id` of a message is passed to the
`message_post` route in order to renconciliate the temporary
message on the client side and the real message created by the
server.
This led to crashes when sending message on the chatter because
this parameter was not allowed as a `_notify_thread` parameter.
Since this parameter is highly specific and isn't linked to any
business/model code, this parameter is now passed via the context
thus solving this issue.
[1]: https://github.com/odoo/odoo/pull/116085closesodoo/odoo#116333
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Steps to reproduce
==================
- Go to a form view with a binary field, or add one with studio
- Upload a file a.txt to a record
- Upload a file b.txt to another record
- Switch between both records with the pager
- The filename is not updated
opw-3208810
closesodoo/odoo#116323
X-original-commit: 90515916e8adb3edb560d73ec8889ad52319cc1d
Signed-off-by: Luca Vitali <luvi@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
In tests, if we need to interact with dropdowns, we should patch setTimout so that we don't have to wait x ms for the dropdown to open.
closesodoo/odoo#116319
X-original-commit: 008d4faebabbecb88d4ce514650b59cdc21ff85a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This PR fixes several issues with the unread counter:
- Notifications being considered as unread messages (which is not
the case on the server side which resulted in inconsistencies).
- Counter greater than it should be when the last seen message is
not loaded.
- Messages not marked as read on first thread opening.
task-3239957
closesodoo/odoo#116208
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit:
popover collapsed when there is fewer fields available.
After this commit:
Now, the popover will not be collapsed when there are fewer fields available.
Task-3072813
closesodoo/odoo#116194
X-original-commit: 787b9b0b49793598c44aebc20e4a0c5e7850f5af
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
**Notable feature changes**
- PoS app continues to load even if no nomenclature_id is configured.
- When scanning, an error popup is shown to the user mentioning about
the misconfiguration.
- We introduce a default error handler that shows the ErrorBarcodePopup
when there are no registered barcode handlers via the
`useBarcodeReader` hook.
closesodoo/odoo#115906
Related: odoo/enterprise#38444
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before this commit, the state mode for subtask without any project set
is not the toggle one as it is the case for the private task.
This commit changes the state mode to have the toggle mode when the
task has no project set, that is, the subtask without any project set
or the private task since a subtask without a project set could be see
as a todo task and not a task in a real process as it is the case for a
task linked to a specific project.
task-3230063
closesodoo/odoo#115781
X-original-commit: e2d7ee73222ab3330da9c45570a4a6330d87c016
Related: odoo/enterprise#38378
Related: odoo/upgrade#4448
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, since the display_project_id field has been removed and
the project_id field could be unset on subtasks (default value as the
`display_project_id` field), the widget `project_private_task` consider
a task as private if the task has no project_id set.
This commit changes the widget to check if `is_private` field is true
to display the `Private` on `project_id` field value.
task-3230063
X-original-commit: b0a8a9aedb3b5cfb2acb6ff3b10a77c279bda8fd
Part-of: odoo/odoo#115781
Before this commit, the `display_project_id` field was a bit confusing
for the user to know what is the goal of this field. Also this field is
available when the user wants to import his data into Odoo, if he does not
know the goal of this field then he could be lost to know which field he
should for his data to import (or even export).
This commit removes the display_project_id field and so a task will be
private one if the project and the parent fields are not set. The
project to set to the timesheet will be the one set on the task or the
one set on one of its parent tasks.
task-3230063
X-original-commit: 22eda5a5ddcfcda9fa6597d6fe21eb20f525799f
Part-of: odoo/odoo#115781
Before this commit, the use of multiple <field> with the same name in a
view was not well supported.
Why was this?
Some Field components need to know information related to the <field>
such as context, domain, required and readonly. The solution used before
this commit to access this information is to use the getFieldContext,
getFieldDomain, isReadonly, isRequired functions of the model.
Unfortunately, these only take into account the last occurrence of the
<field> because the model is not aware that the same field is present
several times on the view. The information must therefore not come from
the model. For example, it was not possible to have the same field
twice with 2 different domains. It will use the domain of the last
field for both.
Solution:
We will add the object "dynamicInfo" to the fieldInfo passed to the Fields
extractProps function. This object will contain a getter to get the value
of required, readonly, domain and context for the current <field>.
If a Field needs one of its information, it will just have to get it
from extractProps.
Part of Task: 3179751
closesodoo/odoo#115197
Related: odoo/enterprise#38151
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The aim of this commit is to allow any tax tag to be set on a journal
item and to allow the user to put tax tag from foreign countries in
which they have a VAT number on any tax.
The end goal is to allow the user to impact tax reports from several
country with the same journal item, avoiding the creation of a whole
journal entry and setting the path for some more automation.
Context:
Our user has a company based in Belgium but has a warehouse in
Netherland. Thus, when the company sells anything from that warehouse, it
needs to fill the Dutch tax report directly.
Moreover, the company needs to fill a grid on the Belgian VAT tax report.
That means that the user would need to gather some journal items on both
the Belgian tax report and the Dutch tax report.
Before this commit:
The user can't set tax tag from another country on its tax nor in the same move.
After this commit:
The user can set tax tags from any country for which its company has a
foreign vat number on any tax and in a move
Task-id: 3196547
opw-2810712
closesodoo/odoo#113027
Related: odoo/enterprise#37247
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
The current algorithm to match vendor bills with purchase orders was written
while keeping in mind that the vendor bill data came from an OCR scan and was
thus not very detailed or totally reliable.
The current algorithm tries to match in this order:
1. Document reference(s) match(es) one or more purchase orders and the total
amounts of the bill and the purchase order(s) match as well.
2. Document reference(s) match(es) one or more purchase orders and the total
amount of the bill matches a subset of lines in the matched purchase order(s).
3. Document reference(s) match(es) one or more purchase orders but the amounts
do not match.
4. No document reference, but the vendor and total amount of the bill matches
exactly one purchase order.
When we generate a vendor bill from an EDI document (electronic invoice), we do
have very accurate information however and can also match line by line, since
our vendor bill will contain separate lines.
In this commit we add an extra algorithm specifically for EDI documents:
* We find all purchase orders matching the vendor bill reference(s)
* For every vendor bill line (having a unit price), we try looking in our
matched purchase orders' lines for the same unit price and a remaining
quantity higher than or equal to what is in the vendor bill. If multiple matches
are found, we check the name similarity and take the most similar line.
* We replace the vendor bill line with the purchase order line, changing the
quantity to the one on the original vendor bill line.
* Unmatched vendor bill lines remain untouched.
We also remove matching method 2 (see above) for EDI documents, in favor of the
new algorithm.
This approach makes that more purchase order lines will be able to get matched
when using EDI documents.
task-3140712
closesodoo/odoo#112684
Related: odoo/enterprise#37061
Signed-off-by: Laurent Smet <las@odoo.com>
This commit fixes a crash that occured when a message has
no author. The author avatar url was assuming an author
would always be given while it is not the case.
closesodoo/odoo#116306
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When grouping a kanban view by a m2o field, a configuration menu
('cog' menu) is available with actions available on the target
record.
This menu contains the entries 'Fold' and 'Delete' which have very
generic wording, and for some reason 'Edit Stage', which of course only
makes sense if the target record is a stage of some kind. Often, it
might not be - there is no reason to use such restrictive language.
Task-3244415
closesodoo/odoo#116299
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Before this commit, the compute method was not returning the value for the
field karma_flag field, and thus it was returning compute method failed to
assign value error.
After this commit, the compute method will return correctly set the value
for karma_flag field from the forum.
closesodoo/odoo#116281
X-original-commit: odoo/odoo@bfa3f2d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Antoine Guenet