Fine-tune of #59524.
If the delivery address doesn't have any delivery method assigned, you get an
undesired change of behavior: no delivery method is populated in that cases.
Note that the delivery method is not a commercial field that is propagated from
parent to children.
With this patch, we get a very similar behavior, which is fallbacking to the
commercial partner's delivery method if there's no delivery method in the delivery
address.
The only different behavior will be if the order partner is different from the
commercial partner of the delivery address.
closesodoo/odoo#60881
X-original-commit: 682b2e6c214b73f67e849df927bd4bda0af31d5a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps:
* Create a delivery method (1) restricted to Spain (any country would do)
* Create a delivery method (2) restricted to Madagascar (same)
* Create a partner, main company, whose country is Spain and the default
delivery method is the first one.
* Create a delivery address for that customer with Madagascar as country and the
default delivery method as the second one.
* Now place a new quotation with such partner and set the delivery address to
the one of Madagascar (multiple addresses setting must be on).
Before:
* The delivery method for the quotation is set to the one restricted to Spain
although we're sending it to Madagascar.
After:
* The delivery method for the quotation is set to the one restricted to
Madagascar.
---
opw-2348336
closesodoo/odoo#59890
X-original-commit: 535d429960a0347d01c528c2440c2b8e9ff2fb51
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Issue
- Ensure that the provider of "The Poste" delivery method is "Based on Rules".
- Create a quotation with "The Poste" as shipping method.
- Confirm, then click on "Delivery" stat button.
- Click on "Put in Pack" and create a "Delivery Packaging".
- Save, go back to quotation and duplicate it.
- Confirm, then click on "Delivery" stat button.
- Click on "Put in Pack".
The "Delivery Packaging" created previously is not available.
Solution
If 'current_package_carrier_type' is equal to 'fixed' or 'base_on_rule',
replace it by 'none' since there are the equivalents in
'package_carrier_type' for 'delivery_type'.
Related fix : https://github.com/odoo/odoo/pull/37427
opw-2310258
closesodoo/odoo#57444
X-original-commit: 5898d31025eacad3e8c37f7a105e20c81831ed17
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
When creating a new delivery method with a provider based on rules, if the base list_base_price was equal to x.8, that ended to a float with endless decimal. (eg: 2.8000000000003)
This fix modify the display to show a rounded value.
closesodoo/odoo#54177
Task-id: 2272472
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
This commit extends the delivery slip so that products added as a kit
component to a stock.picking are grouped together by kit (or non-kit)
when at least 1 kit exists. Kit grouping occurs for products from a kit
without a package assigned. Non-kit section appears only when no
packages are assigned.
Implementation notes:
- Sub-kits (i.e. kits within kits) of kits are purposely not included
- Duplicate product names with different BOMs will be merged into one
since there is no straightforward way to distinguish them within
current db structure
- There are some cases where this doesn't work as expected and may lead
to components being grouped together under the same kit even if they
are from different kits (e.g. kit1 has bolts and so does kit2 => on
slip bolts will only show under kit1 section). Two cases where this
happens is when kits are added before 'Operation Type' is specified
and 'Operation Type = Manufacturing'
This completes subsection 1 of overall Improve delivery slip task.
Task: 2039720
This commit makes it so if a delivery slip contains 1 or more packages
then move lines will be split by package (and non-package) groups with a
"section line" between them. This only applies to when a stock.picking
is 'State=Done'.
In order to accomodate complexity of splitting by package + grouping by
product unless printing serial numbers/lots + template inheritance,
reoccurring parts of the template are split into their own templates and
called. Relevant inheritance has been updated to match.
Additionally, picking.shipping_weight calculation has been updated so if
a pack.weight = 0 then calculation will default to the calculated
product weight. This prevents inconsistency between the "Total Weight"
at the top of the Delivery Slip and the package sections' displayed
weights. To distinguish which value is being used, package sections that
use the total product weight rather than the pack.weight have
"(estimated)" after it.
This completes subsection 3 of overall Improve delivery slip task.
Task: 2039720
This commit makes it so move_lines with the same product+description+uom
are grouped together ONLY WHEN serial numbers/lots are not to be
printed. This is the case when the setting "Display Lots & Serial
Numbers on Delivery Slips" is not active or when there are no
lots/serial numbers assigned in the picking. This is only applicable for
stock.pickings that are 'state=Done'.
In order to implement this, some clean up of lots/serial numbers printing
was also done.
This completes subsection 2 of overall Improve Delivery Slip task.
Task: 2008609
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closesodoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
In case `carrier_tracking_url` is `False`, a `TypeError` is raised and
not catched.
opw-2232268
closesodoo/odoo#49083
X-original-commit: a4b5bd7770bca3f2e4327c65de673e2fcc00e7e5
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.
This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
* Avoid reading all lines invoice_status when the SO isn't confirmed.
* Do not use _default_product_id to discern down_payment lines, use is_downpayment instead
(one ref = one query less by compute call)
* Do not consider display_type lines for SO invoice_status.
X-original-commit: 76a6d0475872f9ffa21cb917f13bc553c720eafd
Before this commit, on a picking, when we want to put in pack, we can't
select packages created with no package carrier type as they had a
confusion between `package_carrier_type` and `delivery_type` when we
pass the value in the context (value who is reused to the package
domain, making some package unfindable).
closesodoo/odoo#46992
X-original-commit: 21f054731e8635b9e3681e673a7cbf627ad49cca
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When a picking is validated with the delivery prices based on rules, you
can face an error, if you are not inventory manager or sales manager.
First, because you don't have access rights to see the sales orders used
to compute the price.
And then you don't don't have access rights on the delivery.price.rule
object to apply the formulas.
As the computation of the price of a delivery should not depends on
access rights other than the ones that let the user validate the
picking, as 'sudo' is called.
OPW-2209148
closesodoo/odoo#46947
X-original-commit: b68139bf2fec8fd2a79e1a578d126f260891c4f6
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
- The volume field of stock.picking extended in delivery was unused,
-> remove it.
- The commit 2ff3749064, add
the 'check_packages_are_identical', which is never used.
- Remove useless variable 'res' of print_return_label in stock_picking
task-2201168
closesodoo/odoo#46516
Related: odoo/upgrade#866
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Steps to reproduce:
- install sales and easypost shipping
- have a delivery order of multiple packages with easypost
- click "send confirmation email"
previous behavior:
the template does not handle multiple package references
and the associated link is wrong
current behavior:
each reference is set in a separated link
opw-2167037
closesodoo/odoo#45507
X-original-commit: 65eaa3e7daf0b547ae2bb98e335fc5941cb200a6
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
In order to prevent `CacheMiss` errors.
Closes#45242closesodoo/odoo#45550
X-original-commit: 6b5c5124c34245ca93716131c6496d1d4dea72a2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
If the shipping weight is changed on a package, we want to update the
shipping weight on the picking to be consistent.
We also want to be able to set a shipping weight on a package that has
no carrier packaging, as we'll use the default one set on the carrier.
Use the 'Volume' decimal precision on all `volume` fields.
Complement of commit c1a5221ba2
opw-2185374
closesodoo/odoo#44473
X-original-commit: dc0111d6cdf4032fa840f9ff95f4fa687d33f77c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Let's consider a delivery method DM with fixed price of 10€ and a margin of 20%
- Let's consider a storable product P
- Create a SO for P and get the rate (12€) but don't add it on the SO
- Confirm the SO and process the delivery
Bug:
A SO line was created for the freight cost without the margin. So it was 10€
instead of 12€.
opw:2144894
closesodoo/odoo#43279
X-original-commit: 621dac802ddddc3a4dd58f7370250386e1031598
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Since new ORM in Odoo, the compute methods should always return values.
In the case of return label in delivery, nothing was returned when there
was no carrier on picking.
So we are now setting the field to False when there are no carrier on
picking.
ISSUE-43270
closesodoo/odoo#43452
X-original-commit: 9bf52959a5afad01970f1ef39a64d6b3694abcc8
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
length is a reserved attribute in JavaScript, and may cause problems
when returning the object to the JS framework.
This commit is to rename the field.
PR
Task 2152050
closesodoo/odoo#43222
Related: odoo/enterprise#7686
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Set the company currency in USD
- Create a pricelist in EUR
- Create a SO with the EUR pricelist
- Add a stockable product
- Click on 'Add Shipping'
- Select 'Normal Delivery Charges' which has a fixed price
The price is not updated according to the USD - EUR exchange rate.
This happens because no company is set on the delivery method, so no
conversion is performed.
We fall back on the order company, then the current environement
company.
opw-2159838
closesodoo/odoo#43167
X-original-commit: 6a6a7e6e64a7e3727a6de1ca8d35361112d99de8
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Using the debug mode on carrier and validate a picking with a
carrier will block and run until request's timeout.
It happens because log_xml create a new cursor and a new environement.
So it should be flush before the ir.logging creation since it's in
another env.
closesodoo/odoo#40561
X-original-commit: cdc09f5b70ad200014ac38f314bf1ec53cd5b8ca
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The default `compute_sudo=True` makes sense for recomputing stored
fields that are indirectly related to a business operation. This
ensures that the recomputation of the field does not break an operation
that is not aware of the fields to recompute.
However, computing non-stored fields in superuser mode is usually not
necessary. It even leads to unexpected values: counting a partner's
sales orders does not give the same result in superuser mode as in
normal mode. That is why non-stored fields are not computed in
superuser mode by default.
[FIX] account, delivery, event, hr_recruitment, point_of_sale, stock:
adapt the model definition to make all fields with the same compute
method have the same value for `compute_sudo`.
[FIX] sale: split the computation of `invoice_ids`, `invoice_count`
(non-stored) and `invoice_status` (stored), as no code is actually
shared.
closesodoo/odoo#39195
X-original-commit: 843fd38a97f02b49dc09d7f55919072d272fd80e
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
When you are adding a line on your sale order that is a delivery line,
the carrier is not always set on the sale order which means that when
the carrier is not explicitly set on the sale order, the carrier won't
be set on picking created from the sale order.
When you are using the wizard on sale order, it works, but when the
carrier is selected on the e-commerce, it is not set on the sale order.
To avoid such difference in behavior, we are writing the carrier_id of
sale order in the function 'set_delivery_line' insread of the wizard and
e-commerce.
closesodoo/odoo#35855closesodoo/odoo#38740
Original-signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
X-original-commit: a15f9921fa1ce92c41c263a8a2c6a32342a8cb1b
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
-Create a sales order.
-Add product E-COM11 (invoicing policy "Delivered quantities").
-Add Delivery method "Normal Delivery Charges".
-Confirm Sale.
-Sale Order Invoice Status = "Nothing to Invoice" (OK).
-Now Open Sales Order again in Edit mode.
-Add Choose "Add a note" in the order line section and add a random note and
don't save yet.
-Check the "Invoice Status" in the "Other Information" tab.
Before this commit:
-The status of the invoice changed to "Fully Invoiced".
-If you save the invoice with the new note, the status changes to "To Invoice".
After this commit:
The status stays "Nothing to Invoice" in both cases.
closesodoo/odoo#38097
Opw: 2078581
X-original-commit: 86301d36fa7b0b6f7f524fff2623077c4366273a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When real cost invoice policy is active in a delivery carrier, the
delivery price is set after validating the delivery. When there is
margin, the estimated price is calculated with margin but when the
delivery is validated, the price set in the delivery line does not
include the margin. This commit fixes this behavior by setting the price
of the delivery line with appropriate margin.
closesodoo/odoo#37178
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Be in multi-company, with shared products, let P be a product in company C.
Suppose there are stock moves or pickings in company C'.
Suppose a non-admin writes on P: it triggers an access error.
Stock moves are not shared across companies in all cases.
So fields that depend on product_id might trigger a recompute on stock.moves
that are in another company, and thus trigger a spurious ACL error while
simply writing product attributes.
Note that _cal_move_weight depends on product_qty, however it is not sufficient
to only put that field in compute_sudo; the product_qty has already been marked
as todo, and so it is recomputed in the initial environment.
opw 2066691
forward port of 7d4d8fa18aecb3b78c8d359434a165c1de71a9b4
closesodoo/odoo#36838
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
The carrier argument passed to the _create_delivery_line function
can be different to the carrier already existing in the sale order
so we should use the correct setting of carrier where we are calling
the function.
closesodoo/odoo#36424
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
If the chosen delivery method has free_over active, and if the cost
of the sale over exceeds the free_over amount, the delivery line
should have price_unit of zero.
When you are adding a line on your sale order that is a delivery line,
the carrier is not always set on the sale order which means that when
the carrier is not explicitly set on the sale order, the carrier won't
be set on picking created from the sale order.
When you are using the wizard on sale order, it works, but when the
carrier is selected on the e-commerce, it is not set on the sale order.
To avoid such difference in behavior, we are writing the carrier_id of
sale order in the function 'set_delivery_line' insread of the wizard and
e-commerce.
closesodoo/odoo#35855
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The user can already send a confirmation email when the
Stock Picking is done. It'd be great to communicate the
same information by SMS.
In addition, the current mailing tool requires a manual
action. The idea is to automate the process via a
Setting instead.
id=1972567
closesodoo/odoo#35662
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
When the many2xxx field relates to a model where company_id is required, set
this domain [('company_id','=',company_id.id)]
When the company_id field of the related model is not required, set this domain
['|',('company_id','=',company_id.id),('company_id','=',False)]
When setting the domain on a field which is in the treeview of a xxx2many field
evaluate against the company_id of the 'parent'.
Some constraints have been added on sereval models. Take a look at the complete
specification for more details.
TaskID: 2024446
Closes: #35266
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Now we hide the generate return label if this option is not available for the current carrier.
Before this fix, we could set the field to true even if the option was not available for this particular carrier.
Task-Id: 1956970
closesodoo/odoo#35178
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The "Recompute shipping cost" button will now reopen the wizard
to be able to change carrier.
When adding to the order, it will replace the current shipping cost.
Relabelled the "Recompute shipping cost" to “Update Shipping Cost”
and moved it to the right.
Shipping method field will have radio widget and cost will be editable
in the wizard.
Also, it was not allowed to delete a delivery line when the order was
confirmed ('sale' state). So here, as we want to allow user to change the
carrier even after the order is confirmed, we have allowed delivery line
to be deleted so that new line is added in place of that.
task-2033229
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
Pedro M. Baeza