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>
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>
Joseph Caburnay