The method filtered_domain() didn't conserve the order of `self`, which
may be confusing, and a subtle source of bugs. It now preserves the
order from `self`.
The processing of `child_of`/`parent_of` making a search with the
default order of the model, which may be slow.
Add documentation.
Part-of: odoo/odoo#83687
When a warehouse used multi-steps for incoming/outgoing shipments,
negative procurements could create returns pickings instead of reducing
the quantity of subsequent moves down the chain.
For example a two-step delivery, a sale order with 5 product A would
have the following pickings linked :
Pick:
- product A : 5 qty
Out:
- product A : 5 qty
Then reducing the amount of product A to 2 in the sale order would do :
Pick:
- product A : 2 qty
Out:
- product A : 5 qty
Return:
- product A : 3 qty
closesodoo/odoo#84900
X-original-commit: c9bc689468d2c775d3b3ec65c8894e4dd66e7249
Signed-off-by: Arnold Moyaux <arm@odoo.com>
When creating a MO _date_planned_finished_ is not added.
Consequently calculates wrongly the date planned to finish the MO.
X-original-commit: 2b2509e154af0e58a3f30f1d7fe40fb854b6b881
Part-of: odoo/odoo#84896
The function that converts inline images to urls returned the modified
html as a byte string. As a result, the Mail Debug tab showed a
hexadecimal string rather than rendered html. This makes sure the string
is encoded in unicode instead, so the format of the string coming out of
the function is the same as it was coming in.
closesodoo/odoo#84942
X-original-commit: b4094ed004a59512d70913f9cc41de8df894296e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The method call_button sometimes returns an action with a help key.
That help was not marked up, leading to an incorrect display of that help.
closesodoo/odoo#84869
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Try to put some logic and clarity in the cached e-commerce pricelist logic
* Try to reduce cache invalidations
* Pass all parameters as id/tuple(ids) to have clean/coherent cache keys
* Add comments
Part-of: odoo/odoo#82374
Clean whole flow of cart updates (new lines, modified quantities, ...)
* Use clean hooks to differentiate line update and creation, quantity verification, ...
* Avoid write calls with unmodified values, useless recomputations, queries, ...
* Create new lines directly with the correct quantity and values
* Delegate fields computation logic to sale as much as possible (price, discount, name, ...)
Part-of: odoo/odoo#82374
Bypass the unnecessary `_get_combination_info` call for each template
and compute the prices in batch, avoiding N-1 times the calls to get the
pricelist price and the fiscal position.
Part-of: odoo/odoo#82374
The discount must be computed regardless of user groups (computed fields
should not be dependent of user groups ideally).
Anyway, pricelist discount policy is by default to show the price with
discount.
Unless the database and user groups are wrongly configured, this
shouldn't have any impact.
Part-of: odoo/odoo#82374
Instead of calling the method `_get_current_pricelist` multiple time.
(This should not be noticeable on perf, but is a pure cleanup)
Part-of: odoo/odoo#82374
Discount wasn't computed the same way in backend sale flows and e-commerce flows.
Now the pricelist discount policy will be considered in the core logic of
event_sale.
Part-of: odoo/odoo#82374
* consistent/clear sale_get_order params (force_create is a boolean value, do not provide integers)
* use one coherent way to get website current pricelist, through the dedicated computed field
Part-of: odoo/odoo#82374
* query pricelist filters/domains directly for the correct company
instead of relying on context/session/... content
* pass the record instead of the id to avoid useless browse calls
* also clearly highlight sudoed partner record
Part-of: odoo/odoo#82374
* order fields, methods according to guidelines
* fix some typos
* rename methods according to guidelines
* remove useless field attributes and class specifications in super()
calls
Part-of: odoo/odoo#82374
There is an issue with the Italian carryover, line vp14b.
Use case:
- Month 1, have a value of 25 in this line => will trigger a carryover to line vp7
- Month 2, add more value to vp14b so that it goes above 25.82.
This will set the bound as None, and thus this will not impact the carryover.
This is wrong, because then the next month we will see a value of 25 in vp7
while it should be 0.
closesodoo/odoo#84938
X-original-commit: ffbc7af321a36d4fd0aebb94d7a636cb1fc34b88
Related: odoo/enterprise#24555
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
Before this commit, the numbering system used by luxon was the default
one set by the browser (in most cases: 'latn'). This caused issues when
translating luxon dates with moment dates, as moment supports some
locales differently (e.g.: ar_001 uses the 'arab' numbering system
while Intl uses 'latn').
To have proper consistency, this commit assigns (as much as possible)
the same numbering systems as luxon for each supported locale.
Warning: since the numbering system is now set according to the user
'lang' parameter, it's now unsafe to use `DateTime.fromFormat(...)` with
static date strings, as they might not be parsable with the current
numbering system.
closesodoo/odoo#84833
X-original-commit: 8bd8b299d57ea930b0549446900bd51d03800041
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Since [1] when fuzzy search was introduced, fuzzy search was also used
when the search term contained numbers.
This is a problem for companies where the shop search is used on
references: the fuzzy search does not match against the whole database
and therefore the exact match might not be found.
After this commit the exact search is used whenever the search term is
made of 80% of numbers or more - because it is very likely to be a
reference or an identifier.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
opw-2715647
closesodoo/odoo#84943
X-original-commit: 7b44907c322a7b78ef4a5cb46627df4f72b21240
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
- A new flag is added to the Setting (l10n_it_edi_sdicoop_demo_mode)
that is computed from the ir.config_parameter
'account_edi_proxy_client.demo'.
If the flag is 'demo', Odoo will not send invoices through the EDI,
if the flag is 'test', Odoo will send invoices to an IAP test server
instance that operates with a test SDICoop service
if the flag is 'prod', Odoo will send invoices to production IAP,
that routes them to the official SDICoop service.
- Some minor UI rework for the EDI parameters on res.company
The EDI settings in the res_company form, under the
'Electronic Invoicing' tab, must stay on the left
closesodoo/odoo#84925
X-original-commit: c5d049c55d21f9885e79182df2bd5f433c5bb782
Signed-off-by: Josse Colpaert <jco@odoo.com>
With this commit we can now call a hook when we want to modify the code for this route.
Before this commit the only way to modify/extend this would be by taking over a big part of the code.
closesodoo/odoo#84905
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Prior to this commit the next call date for the first level would not
take the second level into account, as such it could be that the first
level would be completely skipped instead of being prorated properly.
TaskId-2768435
closesodoo/odoo#84899
X-original-commit: 791b801c7b96a94353031a06dd5da4eeb20ee08b
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
This commit orders the records coming from the mock server the same
way they are ordered by the ORM, while also allowing it to support
multiple levels of orderby.
This has been done to increase consistency in the test suite and provide
a more accurate representation of how records would be returned by the
actual server.
Some tests performed their assertions based on this previous
undeterministic system and have been adapted, either by altering
the base setup or the assertions themselves.
closesodoo/odoo#84718
Related: odoo/enterprise#24509
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Ensure the user can keep typing inside a newly emptied inline tag:
* Add Zero-width Spaces (ZWS) in empty html tag
> We add zero-width spaces in elements in certain cases where they would
> not be correctly displayed by the browser if they were truly empty.
> This also ensure the user cursor can stay in an empty elements,
> and thus we keep the ability to add content in those elements.
>
> See the `fillEmpty` utils function.
* Remove lingering zero-width spaces
> However, we never remove those zero-width spaces when they are not
> useful anymore. In particular, keeping those invisible characters in the
> content prevents the ecommerce from saving the new price of a product if
> the previous price was previously completely emptied during edition.
> This commit fixes that.
>
> The issue didn't happen with the previous editor because they were
> using non-breaking space instead, which is removed by the text_content
> method of lxml. However, non-breaking space were visible during edition,
> which was weird on its own.
>
> Some changes had to be made to the deleteForward and backward commands,
> to ensure the new behaviors.
> Author : @dmo-odoo
* Adapt the deleteForward and backward commands
> To ensure the added ZWS do not break the Deletes behaviors,
> we need to adapt the `deleteForward` and `deleteBackward` commands.
Co-authored-by David Monjoie <dmo@odoo.com>
task-2622455
closesodoo/odoo#84891
X-original-commit: 4360643a446271d4ff1898d67a5b5287722a0820
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
* Fix some tests that will break when we change the empty inline tag handling.
* Add missing tests to ensure the new empty tag management
behave correctly.
* Improve some tests with `contentBeforeEdit` and `contentAfterEdit`
X-original-commit: af379b11462d9393c3c9846aaecb9488ffaa9212
Part-of: odoo/odoo#84891
* Ensure the test environment is clean from previous editor instances.
* Provide a way to clean the successfully test cases
to have a better and quicker overview of the failed tests.
* Better error messages in test report
X-original-commit: 9a362195ad7b3485877946d18d64fd84c62605f9
Part-of: odoo/odoo#84891
Purpose
=======
The module website_crm_partner_assign has its own partner_longitude
and partner_latitude values that are resolved independently, when the
linked partner doesn't exist yet.
So when a lead is turned into an opportunity and a partner is created,
the address info is copied to the new partner, but not the geolocation.
In case these partners are supposed to be geolocalized (for example
on the FSM application), the geolocation will be recomputed despite
the fact that this information was already available at the convertion
time.
closesodoo/odoo#84890
Related: odoo/enterprise#24517
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
This @depends could be 'dangerous' because it would trigger a
lot of calls to the GeoIP API.
It would be more reasonable to make it lazy instead.
So we just reset the geolocation to 0 when the address is modified
without providing the new values, and the user can manually trigger
the geolocation again when needed.
For FSM, it will be updated when needed as the computation is
triggered when the geolocation information is empty.
Part-of: odoo/odoo#84890
Before this commit the only way to modify the domain is to completely override portal_my_quotes/portal_my_orders.
Since this function is so big this is not clean/easy to do.
By creating a separate function we can simply override it and we can reuse the same domain in two places.
closesodoo/odoo#84886
X-original-commit: ff50844da0e4423372746e767f482a2a71148be4
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to repoduce:
- Go to Sales - products
- Create a product
- Add variants (3 attributes and 2 values each) Total is 8 variants.
- onfigure variants: Select 1 attribute and exclude it for 1 variant (for example: exclude for size 12x12)
-> the number of variants remains at 8. The one that is excluded is still visible in the Product variants tab.
Solution:
When an exclusion is created, archive all the not-possible-combination.
OPW-2729329
closesodoo/odoo#84883
X-original-commit: 91642f4e29beb89d110084a20443fb300ee26530
Related: odoo/enterprise#24512
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The history of the replenishment info may be empty while it should not
To reproduce the issue:
(Set your device on January)
1. Process a delivery for product P
2. (Inventory > Operations > Replenishment, create a new one for P)
3. Click on the information icon (I) of the P's line
Error: The sales history does contain anything
When calling `relativedelta`, `month` is considered as an absolute value
and will replace the corresponding value while `months` is a relative
value and will be added/subtracted to the corresponding value.
OPW-2740123
closesodoo/odoo#84881
X-original-commit: c87fea0916b61cb4b0c37f3fe2ddad8359e6aeb2
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Usecase to reproduce:
- Create a batch picking from a new location to customer
- Put some `stock.move.line` in a wave
- Validate the remaining of the initial `stock.picking`
- Create a new `stock.move` with the same data and without `picking_id`
Current behavior
The stock.move is added to the existing wave. However the
stock.move.line created could not match the current wave specification
Expected behavior
A new picking is created and it could be merge in the wave picking if
wanted
closesodoo/odoo#84875
X-original-commit: 4ea418ed1cceff4aee916cf791011a1dc67c77a1
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Rémy Voet (ryv)