Google now requires an API key for the static maps API. As API calls cost money, and we cannot restrict the domain of the caller with the API key in emails, as the domain may vary vastly, the signing of static API URLs is implemented in the existing 'google_map_img' of partners.
This in turn can be used to get a url for an existing location. While preventing anyone from stealing the API key for their own purposes
task - 3079113
closesodoo/odoo#107200
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Before this change URLs would get their url-safe encoding replaced
with regular characters when cleaning up
html content.
This caused signed URLs that use some of those characters to become
invalid if the target did not accept equivalent characters.
Concrete example:
/markers=size%3Alittle%7CAddress
is not the same as
/markers=size%3Alittle|Address
for google maps signed static urls
Do not add special handling for MAKO patterns
as they are not used in templates anymore
task - 3079113
Part-of: odoo/odoo#107200
Google now requires an API key for the static maps API.
As API calls cost money, and we cannot restrict the domain of the caller
with the API key in emails, as the domain may vary vastly,
the signing of static API URLs is implemented in the existing
'google_map_img' of partners.
This in turn can be used to get a url for an existing location.
While preventing anyone from stealing the API key for their own purposes
task - 3079113
Part-of: odoo/odoo#107200
Change the arch to use the new tags for the settings. If the new tags
are not used, the search cannot be performed on these settings.
closesodoo/odoo#110519
See: 02f7835aade005484ca49a8ba4c5c5feea249aae
X-original-commit: 4ab728c5ac0c28947901727f4986b3a6904f6ef7
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
When the only change in a form was made in the html editor, if the user
did not blur the editor, the content was not saved.
The reason is because the `urgentSave` in `basic_relational_model.js`
check if the record is dirty before the HtmlField had the time to update
the value to make it dirty since the commitChange in the HtmlField could
run promises before calling `update`.
To solve it, in case of urgent save, we update the value before any
asynchronous modification and re-update it after those modifications.
In order to have this strategy only on urgentSave and not on the
blur of the editor, the params `{urgent: true}` has been removed in
`_onWysiwygBlur` as it seems to not be useful. Another params will need
to be added if we want to keep that behavior on blur.
task-3140763
closesodoo/odoo#110517
X-original-commit: 3ff0d4b032e44719f52d09c7bfb701c47a79a5c3
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the form view in dark mode had some
coloring issue. This commit fixes that issue.
task-3138224
closesodoo/odoo#110516
X-original-commit: 11cb224a19f5ffdcda50ecf9274259d8ceea5730
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit:
When entering edit mode on the website and discarding directly, the editor
considers that there are changes in the DOM and displays a confirmation modal.
After this commit:
When entering edit mode on the website and clicking directly on discard, the
confirmation modal is not displayed.
Task-3056463
closesodoo/odoo#110515
X-original-commit: 650a97d1bd59254cc2115d54d58940b6112a8d70
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Dhaval Baraiya <dhba@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>
before this commit, when opening the test exception form from Tests -> Test exceptions -> Test exceptions, in the bottom of the form it currently shows Save and Discard button.
after this commit, on opening the same form, instead of save and discard, it will show Close button to close the opened form.
closesodoo/odoo#110361
Signed-off-by: Julien Castiaux <juc@odoo.com>
Before this commit, it was possible to edit void element if they were
branded. It does not make sense to edit a void element.
task-3096813
X-original-commit: fbf633b8110a74dbf25bdc5372a60e793017fbdc
Part-of: odoo/odoo#110513
Before this commit, if you create a sale order for partner who is not
is not a salesman on the res.partner, you become the salesman of the
sale.order. No matter if you are salesman or even employee.
After this commit, the customer or public user will be not assigned as a
salesman on sale.order when creating without forcing the user_id = False.
closesodoo/odoo#110486
X-original-commit: 008cd34c49574f1b0c50132a75b50111422e431a
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In the web editor when the placeholder using the class `oe-hint` is
shown the insertion caret color is almost invisible in dark-mode.
This commits reset the caret to its default behavior by removing the
`caret-color` property from the class `oe-hint`. Therefore making the
caret dark in white mode and white in dark mode even when the
placeholder is shown.
It makes it consistent with all the other inputs w/ a placeholder.
task-3099628
closesodoo/odoo#110477
X-original-commit: 4caf4eb9b957853245a881b645863d6af8a166d1
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The function that adds the missing url root on documentation links uses a regex
in startsWith, which is not supported.
startsWith is replaced with ``regex.test`` which will succeed
if the regex has any match.
Which is fine because we use a '^' to ensure it *starts* with https
task-3079113
closesodoo/odoo#110443
X-original-commit: fdaeaf69c1770edf3f33e32947326d1ebe42820e
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
On January first, the test test_so_and_multicurrency fails because it
creates a new currency rate on EUR. There is already a currency rate
created in the demo data (base/data/res_currency_rate_demo.xml) for the
01-01.
This commit removes all currency rate before the test to make sure we
avoid duplicates.
closesodoo/odoo#110488
X-original-commit: 6de19caf6aa38e040aaf4cb50b17dee894c20984
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- Go to product category → set the inventory valuation to
“Automated”
- Create a BoM:
- Add a component with the cost set to 10$
- Add an analytic account
- Create a MO to produce one unit of “P1”:
- Confirm the MO:
- an analytic account line is created with the amount of $10
- Mark as done the MO:
- The amount is updated to $0
Problem:
In the case where the inventory valuation is set to “automated” we use
the analytical distribution since this commit:
https://github.com/odoo/odoo/blob/7e3403068fc3fbc40182b3cfeb80e97a9300e8ff/addons/account/models/account_move_line.py#L2326
but in the case of MO it shouldn't use it
Solution:
If we are in MO, ignore the type of inventory valuation
opw-3081877
opw-3086626
closesodoo/odoo#110478
X-original-commit: af7be17b71fc72d15149c4baabadeacdcf77cc99
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- Go to Employee
- Open the Employee profile and click on Work information.
- In the Organization Chart Below the hierarchy See All button is visible.
- Click on the 'See All' button.
Currently, when we click on the ``see all'' button of the organization chart, the traceback
comes. Fixed it in this commit.
task-3133047
closesodoo/odoo#110476
X-original-commit: 9f4e1fa80dc75900fb8a2c979568c3ab8f65a635
Signed-off-by: Kevin Baptiste <kba@odoo.com>
before this commit, in the tree view of restaurant.printer model the field product_categories_ids is showing the value in tree as 1 records, 2 records based on the no of records added in the m2m field.
after this commit, the selected field values will be shown in the tree view, so the end users can see the selected categories without going into the form view.
closesodoo/odoo#110339
X-original-commit: fb7dbfb03f4e7c48d199c98fc852e037d3127d16
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
The PR https://github.com/odoo/odoo/pull/109461
fixed the size of the dragging row but it did not care
about cells with colspan.
Since this PR, another one (https://github.com/odoo/odoo/pull/110349)
has been opened to manage the colspan in the
section_and_note widget but the issue also exists in
other subclass of list.
This commit moves the fix from the section_and_note
widget in the base list.
closesodoo/odoo#110487
X-original-commit: 9de8080a45773c4fd4fc2882e9135b51e3e613ce
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Steps to reproduce:
- create a coupon program with a discount type reward on specific product;
- "reward_point_mode" has to be "per unit paid";
- create a sale order;
- add a product several times;
- click on the "PROMOTIONS" button to apply promotion program.
Issue:
We calculate the amount of the discount on the total price of the product.
Expected behavior:
- If you buy 1 product at 100, you can consume 1 point,
each of which is worth 10% of the remaining amount to be paid,
so you have to pay 100 * 0.9 = 90
- If you buy 2 products at 100, you can consume 2 points,
each of which is worth 10% of the remaining amount to pay,
so you have to pay 200 * 0.9 * 0.9 = 162
- If you buy 3 products at 100, you can consume 3 points,
each of which is worth 10% of the remaining amount to be paid,
so you have to pay 300 * 0.9 * 0.9 * 0.9 = 218.7
- If you buy 4 products at 100, you can consume 4 points,
each of which is worth 10% of the remaining amount to pay,
so you have to pay 400 * 0.9 * 0.9 * 0.9 * 0.9 = 262.44
- If you buy 5 products at 100, you can consume 5 points,
each of which is worth 10% of the remaining amount to be paid,
so you have to pay 500 * 0.9 * 0.9 * 0.9 * 0.9 * 0.9 = 295.24
opw-3112925
closesodoo/odoo#110445
X-original-commit: 1a01c8470b1971dfc2b06dcce0e06fe969ac8040
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Purpose:
========
Since the introduction of the required "title" field in the utm_campaign
model in commit [1], quick creation of campaigns from many2ones is not
possible anymore (the slow creation modal is opened when clicking on
"Create"), and the name value entered is not copied into the name field
of the creation form.
This is because the model now has a field "name", and a field "title",
which are both required. The creation using the many2one widget tries to
create a record using the entered value as title and no name, which fails.
It fails because the create method replaces this empty name by a False
value, since it could not generate a unique name given no name.
This commit makes sure that if a title but no name is given when creating
a new campaign record, one does not set the name value to False anymore.
It also makes sure that the value entered before clicking on the "create
and edit" button is copied in the form, by adding the "create_name_field"
option on the many2one fields (the form uses the title field, not the
name).
The "always_reload" option has also been added because without it, the
many2one shows the name of the created record instead of showing the title.
[1]: https://github.com/odoo/odoo/commit/4dbcefb5e5b1878e81fe9be9fe48a785f813334f
Task-3113954
closesodoo/odoo#110474
X-original-commit: 869208cd09b6ceb5dcda55b6fe4131d7cc8d43e8
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose:
========
The `create_name_field` option of many2one fields in form views does not
work: when setting it, the value entered in the many2one field is copied
in the default `name` field, instead of in the field set, when clicking
on the "Create and Edit" button.
This is because an incorrect prop is used: the many2one component uses a
prop named `createNameField` for that purpose, but passes a prop called
`nameCreateField` to the Many2XAutocomplete component.
This commit renames the `createNameField` prop of the many2one field to
`nameCreateField`, to match the prop used in many2many_tags_field and in
Many2XAutocomplete.
Task-3113954
X-original-commit: c0ff0824d964cd702470076d31c066c5443ce9ca
Part-of: odoo/odoo#110474
Steps to reproduce:
- Install stock
- Go to operations/replenishment
- Group by product or whatever
- Select one or all items
The buttons order and snooze disappear when using group by, to solve the problem we take advantage of showButtons property.
opw-3129241
opw-3126708
opw-3114485
closesodoo/odoo#110475
X-original-commit: 3527215730b0454cf92bf35a16f541748ad294ba
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: nea@odoo.com <nea@odoo.com>
The `product.product` method `_get_rules_from_location` can call itself
in case `_get_rule` returns a rule using the "Trigger Another Rule"
supply method. But if this rule cannot trigger any other rules,
`_get_rules_from_location` will continue to call itself endlessly until
it reach the recursion's limit, causing a traceback.
How to reproduce:
- In Inventory Configuration, enable "Multi-Step Routes";
- In Configuration > Rules, create a new rule with the following config:
- Action: Pull & Push
- Operation Type: Internal Transfers
- Source Location: same location than the Destination Location
- Supply Method: Trigger Another Rule
- Route: Receive
- Insure the created rule is the only one used by its route;
- Insure there is at least one product who needs to be ressuplied;
- Click on Operation > Ressuply --> traceback.
opw-3068546
closesodoo/odoo#110446
X-original-commit: 511eebf7de4b751b776e7b2d1b1d15a08c53171b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Sometimes the invoice import fails, because `payment_terms_node.text` can be None and we're trying to concatenate it with a string.
This commit makes sure that `payment_terms_node.text` is there first.
task-3132980
closesodoo/odoo#110430
X-original-commit: 3a3c83b90ed1bdedc2bb6aca59928225e3fdb55d
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Current behavior:
If there was no cost set on a product, the margin couldn't be calculated
for the PoS sale report.
Steps to reproduce:
- Install PoS and Sales
- Create a product with no cost
- Open a session and make an order with this item
- Close the session and go to the PoS sale report
- Add the margin measure to the report, and show the stats by product
- The new product does not have any margin.
opw-3120208
closesodoo/odoo#110429
X-original-commit: 9105f803095d7ddb07bc62ec1e2f2982215e273e
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Since 5b68871097, the scrollable menu of
the picking type kanban card (`kanban-menu`) is the mrp one even for
stock picking type. The inherited view replace the template without
testing the picking type code as it was done before.
This commit adds a `t-if` for stock picking types and another for mrp
one to makes sure the two template are mutually exclusives
closesodoo/odoo#110412
X-original-commit: c7f49d1381ab1bf3dd7ed42436d0c881d7bab27d
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In this commit, we remove the duplicate `Indian EDI Testing Environment` field
from the settings form view.
closesodoo/odoo#110411
X-original-commit: 5a6930e2ed54dc9c0ae6eb38b4b5546d27ec1816
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Bhavin Patel (bat) <bat@odoo.com>
Have a one2many that defines a list arch.
The list should not be editable, precisely, when adding a record, it should go through
a form view.
Define a standard form view in DB, not in the main arch, that doesn't have
at least one of the field that the list arch has.
Create a record in the one2many list, change a field in order to trigger an onchange.
Before this commit, there was a crash, because the onchange asked for the field present in the list
and the ones present in the form, but there was a description (the result of fields_get) only
for the fields present in the form.
After this commit, this is solved.
closesodoo/odoo#109749closesodoo/odoo#110410
X-original-commit: c6897e1e1e5bcf3378bddeb58393baa7426b64c7
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before account types refactoring, fec wizard would check whether company has accounts for unaffected earnings and only call `_do_query_unaffected_earnings` in that case. Now it would always call it.
This commit adds a check for `equity_unaffected` accounts back
closesodoo/odoo#110408
X-original-commit: f9bdc589450514c3e240efb2297ded1f1a4c5879
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Steps to reproduce:
- create a storable product with serial_number tracking
- create an confirm a PO that porduct
- recieve the product
- add serial_numbers to the list view and enter a number
- validate the reciept
- an error pops up (You need to supply a Lot/Serial Number for product)
Bug:
entering a serial_number creates a new stock_move_line with qty_done
while also setting qty_done of the already exising line
Fix:
If a stock move line already exists to reserve the product
use the existing line instead of creating a new one
opw-3060668
closesodoo/odoo#110407
X-original-commit: f1541c62b099ab40c295c60e86094232f5c51a2c
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
When the data takes longer to load, the UI is blocked with the loading
overlay.
Now the data is loaded in the background and we can still navigate
in the spreadsheet.
Note: I moved the `.silent` upper in the call chain. Lower level structures
such as ServerData, DataSources, MetadataRepository don't need to know.
closesodoo/odoo#110387
X-original-commit: 8b09c7347ebeffa7059ed0ccc63f73e3559b7712
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Before this commit, in a form view, from the second opening of a
selection dialog by clicking on the "Search More..." button of a
many2one with a "search_default_..." in its context opened the selection
view without the filter corresponding to the "search_default_...".
Why:
The search model removes the "search_default_..." keys from the context
it is given.
Solution:
Clone the received context so as not to modify it.
How to reproduce:
- Go to a form view with a many2one field having in its context "search_default_..."
- Click on the m2o
- Click on "Search More..."
The search dialog opens with the filter corresponding to "search_more_..."
- Close the dialog
- Click on the m2o
- Click on "Search More..."
Before this commit:
The search dialog opens without the filter corresponding to "search_more_..."
After this commit:
The search dialog opens with the filter corresponding to "search_more_..."
closesodoo/odoo#110342
X-original-commit: 82293c5f4d0955c4688a619bf69e3f0049f10fb6
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
This is cleaner and allows a more obvious line between the page
and the contents, especially since there will be a weird spacing
below the last element of the page list. This styling (vertical
notebook) is only used for the kanban example dialog and has a
limited impact.
The border was removed in the following commit:
16ddf96e0f
task-3113972
closesodoo/odoo#109105
Related: odoo/enterprise#35438
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
With this commit we add images to the answers in result page.
when clicking on the image, we open a survey_image_zoomer widget.
We also add "Responsible" filter on survey.survey view
task-3092439
closesodoo/odoo#108430
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
*:purchase_stock,stock_account
To reproduce the issue:
1. In Settings, enable 'Multi-Step Routes'
2. Create a product category PC:
- Method: FIFO
- Valuation: Auto
3. Create two products P_compo, P_finished
- Both:
- Type: Storable
- Category: PC
- With a positive cost
- P_finished:
- Vendors: a new vendor V
4. Create and confirm a SO with one order line:
- Product: P_finished
- Route: Dropship
5. Confirm the PO and process the dropship
6. Accounting > Accounting > Miscellaneous > Journal Items
Error: There are a lot of lines and most are incorrect
When marking the dropship SM as done, we check how we should
value it:
https://github.com/odoo/odoo/blob/18450973eaf3ca048cdcd2046a8cba5f5c0f98b0/addons/stock_account/models/stock_move.py#L244-L252
Here is one issue: `_is_dropshipped` returns `True`, which is
correct because the source is the subcontractor location and the
destination a customer:
https://github.com/odoo/odoo/blob/8276a9b51b7c5fc0ae6dd557ae88a9c31f1d1962/addons/mrp_subcontracting_dropshipping/models/stock_move.py#L14-L20
However, `_is_out` will return `True` too. To get this value, we
check if the source and destination locations have to be valued:
https://github.com/odoo/odoo/blob/18450973eaf3ca048cdcd2046a8cba5f5c0f98b0/addons/stock_account/models/stock_move.py#L99-L100
Again, since the source location is the subcontractor one (which is
an internal one) and the destination location is the customer one,
we will consider that we have to value this SM. As a result, we will
apply `_create_out_svl` and `_create_dropshipped_svl` on the same SM
(this explains some incorrect AMLs are generated).
Then, there is another issue. In `_create_dropshipped_svl`, we
create an in-SVL and an out-SVL for P_finished. However, when
processing the MO, an in-SVL will also be generated for P_finished.
The issue comes from `_create_dropshipped_svl`: it creates an in-SVL
but the source location is not outside from the company, so it
should not create the incoming layer.
Finally, when creating the SVL in `_create_dropshipped_svl`, we use
the unit price of the SM to define the value of the SVL. This is an
issue: suppose the unit price of the POL is $10 and the costs of
P_compo is $1, the unit price of the SM is then $10 (and so does the
value of the SVL) but the actual value of the delivered P_finished
is $11. Howver, when calling `_action_done` on a SM, we first
process it and only then we will process the MO:
https://github.com/odoo/odoo/blob/829369d3ca0530f1aad0599fbb1598810a928cc3/addons/mrp_subcontracting/models/stock_picking.py#L33-L36
So, in `_create_dropshipped_svl`, we can't know the actual cost of
P_finished. This is the reason why we have to create a compensation
layer once the MO is processed (i.e. in the override from
`mrp_subcontracting_dropshipping`)
Similar issues will happen if we return the
dropshipped/subcontracted product.
OPW-3078499
closesodoo/odoo#110390
X-original-commit: 200aac56771fd1ef759f73b277a6808d96ee5f31
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
In this commit, we update the vat string based on the company country vat label.
TaskID - 47184
closesodoo/odoo#110373
X-original-commit: e5e29b7c40282a2e4ca2da841d9f8aebe6c17992
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Signed-off-by: Bhavin Patel (bat) <bat@odoo.com>
Steps to reproduce the bug:
- Create an attribute with "Variant Creation Mode" = Dynamically
- In a product template, add the attributes and some values
- Create a new BoM for this product
- Click on "Stucture&Cost" smart button
Problem:
A traceback is raise, because the `_match_all_variant_values` function
is called but without the product, while it takes at least one:
https://github.com/odoo/odoo/blob/15.0/addons/mrp/models/mrp_bom.py# L456
https://github.com/odoo/odoo/blob/15.0/addons/mrp/models/product.py#L286
As the variant creation mode is set “dynamically”, the object must be a
`product.template` model and not `product.product` so the first
condition should be `True` and return a `false` value:
https://github.com/odoo/odoo/blob/5c16aa22c70f8a0a377a55b912307ab07222c643/addons/mrp/models/mrp_bom.py#L453-L454
Therefore, if the product has no variant, we have to use the
`product_template` and set it in the `_get_bom` function, but from this
commit:
odoo@ca3dfec
If there is no variant product, the template is no longer set:
odoo@ca3dfec#diff-e8f576a790cd7f3f0976358b9b07f63cee0c6f05b0ba6203fc7bcf91af3ad283L107
The change in this commit from line 107 to line 118 is useless because
it does not change any behavior and does not improve the code, the only
change is that the product_template is no longer set. So it makes sense
to revert this part of change
opw-3008838
closesodoo/odoo#110341
X-original-commit: 1d830b5080e4d05dc1ac6fbd4c435af532443f88
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
in purchase_requisition and stock module, when deleting a requisition and move, the raised warning says,the deletion can be done only in draft moves, where us the deletion is allowed for the cancelled records also.
improving the user error message to include the cancelled records in the message.
closesodoo/odoo#110340
X-original-commit: b71d298dabb4436182c0eb516d5a7b7e76fca437
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
before this commit, in the storage categories form view, the product uom is shown even if the multi uom feature is not activated in the settings.
* from inventory settings, enable storage categories
* inventory -> configuration -> warehouse management -> storage categories
after this commit, the uom will be shown only when multi uom is activated in storage categories view.
closesodoo/odoo#110327
X-original-commit: fa42ee1a161578028986caa2a60e0735d79b2734
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this change, the lots info of the products that are shown in the
invoice report were always computed, no matter if they were printed or
not. It is always computing the lots information, no matter if it will
be printed or not
With this change, the lost info only is computed when is actually used
and will be printed: that is when the user has the
sale_stock.group_lot_on_invoice group.
closesodoo/odoo#110326
X-original-commit: 28778f93dd92d1e460f1d816323b57792907f7c3
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Currently if you require internal transit pickings between warehouse,
it's not possible to use security days in order to plan them and
receive products on time (e.g the second warehouse need times to
manufacture them).
Also the deadline are impacted by security days, so it's hard to
do at the same time replenish on order an use the orderpoints.
(either you see them late in orderpoints or they are plan way to
early in replenish on order process)
To avoid this kind of issue this PR introduces a visibility days
global on the orderpoint. It's call `stock.visibility_days`.
It will add the number of days in the orderpoint forecast date but
it doesn't impact the documents (PO, MO) planned dates.
It could for example always show the quantity in 1 years if people
don't need the just in time feature and don't care to store for a
long period of time.
closesodoo/odoo#110303
X-original-commit: 24816bfee9825fecd60bd24a92d1496f30522b8e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
*: calendar, im_livechat, mail.
Before this commit, the legacy session was a dependency for the bus
service. This was problematic since one would need to import a bunch
of legacy files to fulfill this dependency in order to use it.
This commit removes this dependency. In order to pass parameters to
the `bus_service`, the `bus_parameters` service is now used.
closesodoo/odoo#110247
Related: odoo/enterprise#35974
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The purpose of #109773 was to fix the scrollbar that appeared behind
the sticky thead in Safari.
This commit introduced a bug where elements like the dropdown,
the draggable records, creation of reacord are misaligned.
As I don't find a quick fix for the scrollbar issue on Safari, this
commit reverts #109773 .
closesodoo/odoo#110367
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Odoo's Mergebot