Currently the profitability test assumes the project is in the USD currency.
However, if the companies default currency is something else, the asserts will fail.
Here we guarantee that the 0.00 amount will always be in the same currency as the
project to allow the tests to pass.
opw-3210514
closesodoo/odoo#116773
X-original-commit: 6ad9d1af8d8add56f2b7752632af55c3e66bd148
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
loyalty_delivery: the demo data updates the `tracking` field, which is a
stock-dependent field. As this module does not rely on stock anymore,
and since these lines only assign to the default value, the file is
removed.
website_sale_picking: the module dependency to stock has been forgotten
in the split of delivery from stock, and is added back to the manifest.
closesodoo/odoo#116747
X-original-commit: 9da0e43651070de2bf617035329ddc6a250398ff
Related: odoo/enterprise#38847
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Issue:
A user being in the group `group_hr_timesheet_approver`
will have a traceback if he goes to "Timesheets / Reporting / Timesheet/Attendance".
Cause:
The `project_id` field does not exist on the `hr.timesheet.attendance.report` model.
Solution:
It is acceptable for the `group_hr_timesheet_approver` group to have the same
access rights than the `group_timesheet_manager` group.
opw-3221963
closesodoo/odoo#116741
X-original-commit: 9d0bc00eff0f9290b401f648f865fd591ad5fca0
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This error was caught by sentry.
Steps to produce:-
* Install eCommerce,loyalty module.
* Delete 'Top-up eWallet' product from eCommerce/product.
* Then create a new Gift card & eWallets from eCommerce/Gift card & eWallets.
* At this moment A trace back raise.
Because user deleted the product 'Top-up eWallet'.
Sentry:-3985154178
closesodoo/odoo#116738
X-original-commit: e5ae091a530de45741749e01d25f436af093a8a2
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
`Account.move.line` contains a stored related field called `parent_state` which relates to `move_id.state`. This allows for performance improvements by accessing that instead of `move_id.state`.
However, across odoo and enterprise `account.move.line` is domained against `move_id.state`.
This can produce an unnecessary left join on SQL queries for reports or other queries when instead it could use the stored field directly.
To accomplish this fix, we adjust domains to refer to 'parent_state' instead of `move_id.state`
While this PR will adjust multiple modules to fix this domain, it should improve SQL queries over large tables when a left join is no-longer necessary.
opw-3178866
closesodoo/odoo#116679
X-original-commit: c94d57edc002e499e317d04b2864d22acb5f40fa
Related: odoo/enterprise#38808
Signed-off-by: William André (wan) <wan@odoo.com>
before this commit, on enabling mass editing in payment and journals tree view, using studio throws exception saying field used in domain is missing in the view.
* install studio
* go to payment/journal tree view
* enable mass editing for the view using studio
* traceback is thrown
after this commit, no traceback on enabling mass editing
closesodoo/odoo#116127
X-original-commit: 3a53901aa4fce3080a42f9507de4afa5eb7cf7a4
Related: odoo/enterprise#38520
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
The product `sale_timesheet.product_service_deliver_milestones` uses
`milestones` service_type but this is not available always.
Steps to reproduce issue:
1. Install sale_praject (with demo) in a clean DB
2. Unmark "Use milestones" in settings
3. Set invoice policy at delivery in settings
4. Try to install sale_timesheet
Demo data fails to install due to attempt to use milestores as service
type.
```
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 2720, in convert_to_cache
raise ValueError("Wrong value for %s: %r" % (self, value))
```
This issue blocks many upgrades.
closesodoo/odoo#116697
X-original-commit: 8ae7bf6c9a3af45353e5ef43d8b72f95c6731e5f
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce the bug:
- Add an Image Gallery (IG) snippet on the page.
- Click on "Remove all" to remove all the images of the IG snippet.
- Add 2 new images in the IG.
- Click on the first image of the IG to load its data.
- Click on the trash button to remove the snippet.
- Bug => The snippet is not removed (an image is removed instead).
When a snippet is removed, the `removeSnippet` function is called. The
problem is that the `call_for_each_child_snippet` will never resolve.
Two mechanisms are of interest to understand why: the first one is the
`updateCurrentSnippetEditorOverlay` function. Its goal is to destroy a
snippet each time its target is not in the DOM anymore. The second
mechanism is specific to the IG snippet: when an image of this snippet
is destroyed, the `slideshow` function goes through the remaining
images to update parameters. To do it, the function uses the
`_replaceContent` function that empties the content of the carousel and
then fills it with new data.
When a snippet is removed, a `SnippetEditor` is created for each
element of it. In the case of the IG, a `SnippetEditor` is created for
each image of the the snippet. Because the first image already has a
`SnippetEditor` (because it has been clicked), the callback of
`call_for_each_child_snippet` is called to remove this image from the
IG snippet. The second mechanism explained before will then be called.
Meanwhile, a `SnippetEditor` will be created for the second image.
However, because the `_replaceContent` function emptied the content of
the carousel, the `updateCurrentSnippetEditorOverlay` function will
destroy the `SnippetEditor` of the second image as its target is not
considered present in the DOM anymore. Unfortunately, the
`call_for_each_child_snippet` still needed this `SnippetEditor` and
will never entirely resolve.
To solve this problem, the `removeSnippet` function is executed inside
a mutex. Because the mutex is also used by
`updateCurrentSnippetEditorOverlay`, we are sure that this function
will not destroy the snippetEditor while the `removeSnippet` is still
running.
task-3147271
closesodoo/odoo#116352
X-original-commit: 1c99ab2bc04f65999098f70d062d24ed1ac4a9c3
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: loco-odoo <loco@odoo.com>
The web client has a mechanism to invalidate the action and the view
cache: in the basic model (and the relationalmodel), some code is
looking for updates to some specific models (such as ir.actions) and
trigger a `CLEAR-CACHE` event. This event is then listened by the action
and view services to properly clear the caches. This mechanism was also
used to reload the page after editing a company, or reloading the
currencies after editing some currency.
With this commit, we modify the orm service to trigger an event after
each rpc. This event can then be used by the action/view service, and
also by the currency/company services to perform their specific cleanup.
This work is one step in the future refactoring of the relational model.
closesodoo/odoo#115655
Related: odoo/enterprise#38814
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
1) website config: show strikethrough price (price comparison), show tax included price, discounts, pricelists(with advanced price rules).
2) create a pricelist with "show price and discount to customer", and any rule like 50% off any category (doesn't really matter).
3) apply the pricelist to the website
Issue:
Notice that some strikethrough price is applied wrongly - the crossed amount is the same as the written amount
Cause:
Strike is applied if base price not equal to price_reduce, which is actually calculated using taxes prior.
it should not be the case for the tax-included product ( or base price should also have tax applied).
opw-3140616
closesodoo/odoo#116668
X-original-commit: 58108a84946817175a07c5e8f09f7a5ba88266ee
Signed-off-by: Djoumatchoua Eteil Junior (etdj) <etdj@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
filtered method doesn't mutate the recordset, thus, we should reassign to
have the new set of desired records.
closesodoo/odoo#116667
X-original-commit: 7cca8011e0f97a2db00c769b8f629506eca6cbdd
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Create an misc journal entry with 1000 as debit and a tax.
The tax line is linked to a refund tax repartition line.
Open the manual reconciliation widget and do the same.
The tax line is linked to an invoice tax repartition line.
When dealing with tax grids, the resulting tags set on the journal items are not the same.
This is because the given price_unit is not following the sign of the debit/credit column.
Indeed, a positive amount means you are adding something on the credit column.
opw-3236208
closesodoo/odoo#116433
X-original-commit: a70f804d7da68d5cc7cdd79b75d73359c41b9367
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
This removes the `clearEmpty` util which was only used in the `enter`
command.
closesodoo/odoo#114178
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This removes a parameter in `isVisible` that made it consider (wrongly)
all blocks as visible. This made it confusing to use because it was
effectively returning fake news by default.
Part-of: odoo/odoo#114178
Steps to reproduce:
- create a new job application;
- click on the 'CREATE EMPLOYEE' button;
- save.
Issue:
Two contacts have been created.
Cause:
When creating an employee from a applicant, if the applicant does not have a linked contact, one is created.
Then, when validating the creation of the employee, we will create a contact if he does not have a contact linked to him in the `work_contact_id` field.
Therefore, two contacts will be created.
Solution:
Different information will be put in the context when we are redirected to the form view for the creation of an employee and in particular `default_applicant_id`.
If a current applicant is detected when creating an employee, we are certain that a contact already exists (because it was created previously).
In this case, the contact linked to the applicant is added to the employee's `work_contact_id` field to avoid the creation of another contact afterwards.
opw-3208808
closesodoo/odoo#116663
X-original-commit: 84507e03e47d49ee32ca4693bba8dcc22b772b1a
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, we were trying to access
`channelMember.thread.channelMembers` when inserting a member, but
some inserts come without this key.
A traceback could occur when inserts of `rtcSession` records came
with a `channelMember` with little information on their thread.
closesodoo/odoo#116656
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
HTTPS certificate IoT issues can be complicated to troubleshoot
as the information are not visible/given.
This PR aim to share this information on the IoT box homepage.
As there is a lot of possible causes for a given problem,
a code is used that will be explained/detailed in Odoo's
IoT documentation:
https://github.com/odoo/documentation/pull/3818
OPW-3227004
closesodoo/odoo#116650
X-original-commit: 8bc6b2d0033676507f95b74b3ae383ab17164203
Signed-off-by: Loan (LSE) <lse@odoo.com>
Signed-off-by: Sens Loan (lse) <lse@odoo.com>
When editing a purchase order line which is not in the company currency
the price_unit on the stock.move is overwritten with the price_unit in
the currency of the purchase order.
Secondary issue this causes is that if any further quantity changes
occur on a purchase.order, any new stock.moves may not be merged. If the
quantity is reduced this results in a negative stock.move quantity which
Odoo helpfully inverses the location and destination locations.
closesodoo/odoo#116620
X-original-commit: e7dfe10c81e69e3eb82b209db25483f29eb557e6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Problem:
The prices for products shown on the dynamic content: products on the website
can be displayed incorrectly.
Example:
Consider Product AB that is shared between Company A and Company B.
Company A sets Tax A for Product AB.
Company B sets Tax B for Product AB.
Product AB is published on Website A that belongs to Company A.
However, the price shown for Product AB on the dynamic content: products
is incorrect because the price includes taxes from both Company A & B.
Solution:
Filter the tax records based on the current context's allowed_company_ids.
The price for the product should only include taxes based on the website's company.
opw-3201283
closesodoo/odoo#115114
X-original-commit: 7046dd7c3095686c7cb33f441532e4234e8bdf1b
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The fiscal country was changed each time the user modified his
company's country. This caused problems (in particular at onboarding)
because it was not done transparently for the user and possibly
overrided his setup.
After this commit, the fiscal country will behave like this:
- When we install Invoicing/Accounting, it is set by default to company's country
- When we install CoA, it is set to the CoA's country, if there is one (override above setting)
- It is **no longer automatically changed** when the company's country changes.
Fixes related tests that depended on the previous way of compute fiscal country.
closesodoo/odoo#116322
Task: 3221792
X-original-commit: ac1f2a5774a2f8d03003b481829f6e183ab0b713
Related: odoo/enterprise#38623
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Claire Bretton <clbr@odoo.com>
Having one or more blank lines at the beginning of an xml file can
cause problems when parsing the xml.
closesodoo/odoo#116624
X-original-commit: aa400dbec834e7229f0f8d22298db995a490379b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- Activate analytic accounting
- Create a Sale Order, with an analytic account for the whole order
- Add a line with a distribution containing the same account (100%)
- Create Invoice From this Order
=> The distribution on the account for the invoice is of 100% and
not 200% (the sum of the order's account and distribution).
The problem is that on the dict that we're returning, the key is a string
closesodoo/odoo#116617
X-original-commit: 9ecf263d4124b186b55e50ab025acb7541043d3a
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Insteadeither is added without space, adding spacing between the words.
Insteadeither --> Instead either
closesodoo/odoo#116493
X-original-commit: 4e59006e2a5a3812cc72dd622b2fcec1468ec0d2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If applied, this commit will solve the keyError for _invalidate_documents.
Before this commit:
============================================
KeyError 'rating' or 'False' occurs when a user tries to send a message and
_invalidate_documents() takes the parameter model equal to 'rating' or 'False'.
but the model 'rating' is not available in the database and It will be accessed
by the self.pool[model].
After this commit:
============================================
Solved the issue when the model 'rating' is not available or the model is 'False'
while sending a message.
sentry - 3956327451
closesodoo/odoo#116302
X-original-commit: 5becbca6531d5829bee262a5c1b64ae5e0917f8e
Signed-off-by: Anh Thao PHAM <pta@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since commit c1cbfb07516d2d06c3311d66e220b1de87c1b681, fieldsToFetch
has been renamed to relatedFields.
Apparently, some commits were merged after this one without using the
new name.
closesodoo/odoo#116623
X-original-commit: dea116bf4c65295e93cc7894132d9f48f98e4189
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
Launch a contract which has an end date
scheduled for the next day for an employee
and manually activate the "HR Contract: update state" cron.
Issue:
Running contracts are closed one day in advance.
Solution:
Correct the condition which selects contracts to close.
opw-3217616
closesodoo/odoo#116580
X-original-commit: e08aa67009b191cb99dfb1f7f1d0cb9d6539376a
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Before this commit, when the user edits a float time field a border
is displayed instead of having the same style then the others fields
(float, integer, etc). The reason is a style is added (`outline: none;`)
on input with `type="text"` but the type is missing on the input tag of
float time field component.
This commit adds a prop `inputType` and by default is `text` the others
fields component and this prop is used to define the type on the input
inside the template of float time component.
Issue found in task-3000757
closesodoo/odoo#116629
X-original-commit: 8ec5f7eb73844daf278b3f2aafa73dd0d65ec59c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
`/project_sms:ProjectTask._send_sms` called `_message_sms_with_template`
without numbers, and so no sms was sent.
Now, we give the method an `sms_numbers` arg, and it works.
closesodoo/odoo#116514
X-original-commit: 5de1b941ce580253a21f0e4f6da0a8ca818f26b3
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit,
- create an expense
- click on create expense report button
- click on add expense in expense lines
- click on create
> the record does not exist error.
After, you can add expense to expense report via the lines without issue.
The (not yet existing) expense sheet is not part of the context anymore.
closesodoo/odoo#116544
Task-id: 3245816
X-original-commit: ee222533bedec6a1910723b28429c8f6c04d2169
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Detry Thomas (det) <det@odoo.com>
before this commit, on creating new invoice address from
the sale order form, the created contact is assigned
by the type as contact, which is expected to be with
type invoice address.
this happens due to multiple field in the form for
partner_invoice_id field in the form and context
was missing during the creation.
after this commit, the invoice address will be
created with invoice address type
closesodoo/odoo#116542
X-original-commit: 10f0eced62fe6ce085ae1a694aa5debbdc06dc1d
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Step to reproduce:
1. create a product
2. duplicate it and change its translation (but DO NOT change the product name)
3. create a transfer for that new product without a contact
4. print delivery slip
Bug:
the db's product name is used instead of the translated name
(i.e. "original product name (copy)")
FIX:
when partner id is not set in picking, then default to the user's language
opw-3141202
closesodoo/odoo#116610
X-original-commit: e56b955fbd7963709b9547eb50d97cf105f9d430
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
before this commit, code in files for Odoo core which are outside of
root_path/addons/
e.g. odoo/models.py, odoo/service/model.py
cannot be translated. Because the translation tool thinks they don't
belong to any module
after this commit, by reusing the same logic while exporting these code
translations,
they will be translated by using po files of the 'base' module
closesodoo/odoo#116602
X-original-commit: e29aca207e95725d4072fe2a6dfc928128c1e47b
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
Steps to reproduce:
- Install l10n_it_stock_ddt, studio
- Switch to IT company
- Create transfer: Operation Type - Delivery Order, add a product > Save
- Toggle Studio > Reports > DDT report > Print
Issue:
The signature table in the resulting PDF is offset and overlapping.
opw-3149466
closesodoo/odoo#116559
X-original-commit: 8abc4956d01df17251b8ee716b99dad5202e0411
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
When pressing enter at the end of a heading, we want to insert an empty
paragraph instead of a new heading. This failed when the paragraph had
a zero-width space in it because we didn't recognize it as empty.
closesodoo/odoo#116558
X-original-commit: 228e7937f818f5606601e575b1d9a2bb87cda99d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
If a block ends with a zero-width space, the mechanism that skips these
characters when using the arrow keys should not skip all the way to the
next block. This is because this mechanism happens before the browser
applies its own behavior for the arrow key so we want to let it skip to
the next block instead (or we'll end up navigating too far).
X-original-commit: acae237410e43e1cf97fc023568f49cc2e974db4
Part-of: odoo/odoo#116558
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>
Andrew Gavgavian