Modifying product attributes involves discarding product variants via
the method _unlink_or_archive(), which tries to delete variants, and
archive the ones for which the deletion fails. This process is very
slow when most product variants must be archived. Instead, we filter
out the variants that must be archived anyway (like the ones used in
sales or stock), in order to avoid the variants that cannot be deleted.
On a product with ~200 variants, the time goes from more than 15 minutes
(the request times out) to around 5 seconds!
opw-2440417
closesodoo/odoo#65027
X-original-commit: 63b2f85079404eafac918a74c95e27051539c133
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
GLOBAl PURPOSE
Ability to have salesmen belonging to several sales team is a core requirement
of CRM. It is therefore moved from website_crm_score to crm along with cleaning
and behavior improvement. Automatic lead assignment is also moved and cleaned.
SPECIFICATIONS
Compute default team id for sales related documents. Note that this method is
not called by default_get as it takes some additional parameters and is meant
to be called by other default methods. Heuristic (when multiple match: take
first sequence ordered)
1- any of my teams (member OR responsible) matching domain
2- any of my teams (member OR responsible)
3- default from context
4- any team matching my company and domain
5- any team matching my company
Note: ResPartner.team_id field is explicitly not taken into account. We think
this field causes a lot of noises compared to its added value. Think notably:
team not in responsible teams, team company not matching responsible or lead
company, asked domain not matching, ...
We also improve various places where sale team is computed on sales documents.
Purpose is to try to use same heuristic as much as possible in various
team_id fields.
LINKS
Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#499
Upgrade PR odoo/upgrade#996
When offering services, it is critical to make sure that the time being
delivered is billable. Otherwise, the company is loosing money.
This commit adds two fields in product.template:
1. service_upsell_warning
2. service_upsell_threshold
The first one is a boolean, if it is checked than the second one is
displayed to add a threshold. This threshold is used to create a upsell
activity want the (qty_delivered / qty_ordered) in a SOL of this product
is greater than the threshold defined in the product.
Moreover, when the following condition for a SOL:
(delivered quantity / ordered quantity) >= threshold set in the product
is True, then we display an upsell warning for the corresponding
SO. The problem is we don't check if the warning has already displayed
by a certain SOL. Thus, each time we timesheet for this SOL, we display
one more time.
This commit avoids to spam the salesman, to do this, we add a new
boolean field in sale.order.line, this field will be True if the warning
upsell activity is shown thanks to the SOL.
A method is added in sale module to create the upsell activity for each SO.
This method is used in sale_timesheet module to avoid duplicated code.
Finally, an unit test has been added to check the feature.
task-2411291
closesodoo/odoo#64252
Related: odoo/upgrade#2066
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Create a promotion auto applied with 0 minimum amount on any product in
catalog.
Have a DEMO product invoiced on delivery
Create a sale order with DEMO, apply the promotion. Confirm.
Click on 'Create Invoice'.
The invoice will only contain the promotion because the line for
DEMO is to be invoiced only after delivery, while by default the
promotion product has the invoice policy 'on order'
This commit will:
* avoid highlight the button 'create invoice' if the only
invoiceable lines are promotion lines as well as raising an error if the
invoice is created in the same scenario
* refuse to invoice only promotion lines from a SO.
* adds a test to cover the case
opw-2414630
closesodoo/odoo#64826
X-original-commit: 6532c6ba7acb2de53fc839d5a7c5d8b200716565
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce the bug:
- Let's consider two pricelist PL and
- Create a new order O
- Add a line L
- Set PL as pricelist
Bug:
The button Update pricelist didn't appear
Closes#64269
opw:2429987
closesodoo/odoo#64734
X-original-commit: 77436f674d84666511b8b5c2b1355b95beaace94
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
PURPOSE
Notification may be sent using a generic mail.thread record, notably when
sending user notifications. In that case links to view document are
incorrect.
HOW TO REPRODUCE
Issue
- Install "Approvals"
- Submit new approval with you as "Request Owner"
- Click on "View Approval Request" in your mailbox
The link redirects to a 505 error
Cause
The model is not the correct one and the res_id is undefined
Solution
Specify the model and the res_id to _notify_get_action_link
when creating the link with kwargs
SPECIFICATIONS
Propagate message value through various notification sub methods. That way
we can rely on them if model seems void.
Also limit values given as URL parameters to some white listed values.
LINKS
opw-2358846
Task ID-2379766
Followup of odoo/odoo#60998
Followup of odoo/odoo#61545Closesodoo/odoo#63292Closesodoo/enterprise#15585closesodoo/odoo#64229
X-original-commit: 58bac5d242d6548d54f0163328fa64b319852e40
Related: odoo/enterprise#15634
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Achraf Ben Azzouz <abz@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Steps to reproduce the bug:
- Let's consider a re-invoicable and expensable product P at 100€
- Let's consider a pricelist PL with 20% of visible discount on every product
- Let's consider a confirmed sale order SO with PL set on it
- Create an expense E with P at 100€ and reinvoice customer set to SO
- Generate the entries of E
Bug:
A new sale order line was created with 80€ as unit price and no discount instead of
20% discount.
opw:2423147
closesodoo/odoo#64194
X-original-commit: 8815f4d9ab8620428d50abbe603c7f6c63076d6c
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Issue
- Create a Price list and set 'Discount Policy' as
"Show public price & discount to the customer "
- Create an SO
- Add a multiple product with at least one with price unit = 0
- Change the pricelist and update prices
Cause
Division by zero when calculating discount.
Solution
Calculate discount only if there is a price_unit.
opw-2393790
closesodoo/odoo#63218
X-original-commit: 9f70f405bc453ce56b75d22a318c9fd72e8bd496
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider a product P with sale UOM = Unit and unit price = 10€
- Create a SO and add a sale.order.option SOO with P and Dozen as UOM
Bug:
The unit price was 10€ instead of 120€
opw:2413237
closesodoo/odoo#62992
X-original-commit: 880555b38dee0c3e3b364c19bb6b0db983bf8aa0
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
1) forbid deletion of main uoms & categories
2) warn modifications of main uoms data.
Except for the working Hours uom, which isn't a strict UoM
representation and could change between countries (and/or be deleted).
3) Also move the Dozen UoM to demo datas, it's a confusing UoM and isn't
used by the majority of databases.
4) Restrict deletion of used uoms on main models.
On sale orders and account moves the uoms couldn't be deleted thanks to the
SQL constraint covering the display_type logic, but the generic error message
is more clear for a user when deleting an uom.
Steps to reproduce the bug:
- Let's consider a configuration with two languages L1 and L2
- Go to Settings / Accounting / Customer Invoice / Default term & condition
- Define a default text T1 and save
- Create a new customer invoice, T1 is displayed in the field narration
- Go to Settings / Accounting / Customer Invoice / Default term & condition
- Change T1 to T2 for L1, L2 and save
- Create a new customer invoice
Bug:
T2 was displayed in the field narration
opw:2388353
closesodoo/odoo#62270
X-original-commit: 98d36b80ed1b4f11491301d3b7b5818d81edf542
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
STEPS:
* activate Product Configurator
* create 3 attributes with custom values option
* create a quotation with a product having all 3 attributes and custom values
* select the custom values for attributes in different orders for each SO line
BEFORE: Product description get random order for the custom attributes list
AFTER: Order is fine
---
opw-2379778
closesodoo/odoo#61869
X-original-commit: 57eb05071a08251171dcfdb2308feb13c3281fa7
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Behavior prior to the commit:
- when setting the customer (partner) on a sales order, the sales team
is set based on the partner's sales person. If there is no sales person
on the partner then the team defaults to the first team in sequence for
the company.
- the team set on the partner is not used (by default, this field is not
visible, but it can be set from server action or added via studio). In
Odoo 12.0 the team set on the partner was used as a fallback, but this
was removed in commit 242be00429
Behavior after the commit:
- the partner's team is used as fallback when the partner is updated
- when the salesperson is updated on the quote, we also use the current
team as fallback (since presumably this was set either from the partner,
or using the existing default rule, there is no reason to change it)
- in debug mode, the field `team_id` is shown on the partner view (under
the `Sales & Purchases` tab)
Note:
- Change in existing installation is expected to be minimal since it only
affects the customers who are making use of the partner.team_id field, not
populated or displayed by default, but there is a risk for a customer who:
1. has that field populated on existing partners (maybe upgraded from
an old install where it was displayed?)
2. is relying on the new (as of v13.0) behavior of assigning the default
sales team based on the sequence
opw-2351868
closesodoo/odoo#61827
X-original-commit: 7683e1907f6eb1fde4626927957df4eede49b8ca
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
Configure card payment provider (stripe, Authorize, etc) in test mode
Allow the customer to decide if saving payment info
Go to web shop, fill cart and checkout
Select provider and check "save payment method"
After payment the card info is not saved:
the related check variable is overridden in the process.
Note: this occur only when using the provider site.
S2S payment via Odoo follows a different flow
opw-2335237
closesodoo/odoo#61351
X-original-commit: dc18fdba1d4e0d38df0ebce4eed46f8ad08f4821
Related: odoo/enterprise#14597
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Revert "[FIX] sale: correct _get_to_invoice_qty depends"
This reverts commit cfc9abe14689db82acf1872fa8d358662fc7e123.
While the field is indeed in the list of records, it's a big change of
behaviour.
Retroactively changing the invoicable lines of sale.order that are
closed is dangerous and can lead on unexpected behaviours.
Performances can also be bad when changing the product configuration
on a database with a lot of sale orders.
Changing the product configuration should only apply to future orders,
not past.
closesodoo/odoo#61168
X-original-commit: be13bc94c2ff51b99a4399be44a765d0b28202eb
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
`product_id.invoice_policy` dependency was missing.
When changing the policy from "delivery" to "order" of a product, the
quantity of invoiceable products was not recomputed and remained 0
Closesodoo/odoo#60674closesodoo/odoo#61026
X-original-commit: cfc9abe14689db82acf1872fa8d358662fc7e123
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- Create SO 1:
- Section A, sequence 10
- Product A, sequence 11
- Create SO 2:
- Section B, sequence 10
- Product B, sequence 11
- Select both SO
- Create the invoice
The resulting invoice lines are organized as follow:
- Section A, sequence 10
- Section B, sequence 10
- Product A, sequence 11
- Product B, sequence 11
This is obviously not expected as it messes up the organization of the
lines.
This happens because the sequences of the SO lines are kept at invoice
creation, while it is necessary to resequence the invoice lines to keep
them organized.
To do so, we loop on the invoice lines before their creation in order to
assign a sequence corresponding to the order in which they have been
added in the list. Since the invoice lines are added one SO after the
other, this allows us to keep the appropriate ordering.
Note that we only resequence if there are less invoices to create than
SO, meaning that several SO have been merged. Indeed, in case a single
invoice is created from a single SO, there is no need to resequence.
This assumption is not completely true: if not all selected SO were
invoiceable, the number of invoices created is also smaller than the
number of SO. However, resequencing should be safe so in the worst case
we might resequence an invoice while it was not necessary.
We also leave the possibility for third-party addons to alter the
resequencing thanks to the `_get_invoice_line_sequence` method.
opw-2363443
closesodoo/odoo#60789
X-original-commit: 97c2f5ea51a669830b3e6d6d2d7d857742a41481
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
change
Configure taxcloud, 2+ delivery carrier, card payment
Go to the website shop
Add product to cart
Checkout with USA address
On the Confirm Order page, the tax is computed via TaxCloud and shown on the right.
Pay via payment acquirer site
The Subtotal (without taxes) is sent to the Payment Acquirer instead of the Total
This occur because when selecting delivery carrier coupon lines are
recomputed. To be on the safe side with taxcloud, taxes are excluded before
recomputing coupon lines, but never added in this specific flow.
opw-2338103
opw-2362493
opw-2353048
closesodoo/odoo#60570
X-original-commit: f220e66d707654ee76dc343685dee8c2dda68dd5
Related: odoo/enterprise#14351
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Enable discounts on sales order lines
Create a service type product with invoicing based on timesheet and
task in sales order's project
Create so for 6 hours and deliver 8 hours.
Create 2 invoices: One for 6 hours with the regular price and 2 hours
h 100% discount.
Invoice status of the order will be Fully Invoiced
Go to Sales>Reporting>Sales Analysis report will show the untaxed amount
associated with 2nd invoice as still to invoice which is incorrect
This occur because when saving the invoice the untaxed amount is
calculated on the amount invoice after discount
opw-2338564
closesodoo/odoo#59638
X-original-commit: be5ec58d0a1a71fc84ca790555cac02a6be5b67a
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Let's consider two pricelist PL1 and PL2 with discount_policy = 'without_discount'
- Let's consider a product P
- PL1 has 10% on P and PL2 has 20% discount on P
- Create a quotation Q with PL1
- Add P on Q (the 10% discount is correctly applied)
- Change PL1 to PL2 and click on Update pricelist
Bug:
The 20% discount on P was not applied.
opw:2352577
closesodoo/odoo#59541
X-original-commit: 9f1280e275fd851fce17bf82c603fdc50a8ef94e
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Go to Invoicing > Configuration > Taxes
- Create a Tax and enable "Included in Price" in Advanced Options tab
- Go to Sales and create a Quotation:
* Add an Order Line with the created Tax
- Save & Confirm
- Edit the Quotation to set a delivery quantity, then save
- Go to Sales > Reporting > Sales:
* Display row by "Order #"
* In Measures, add "Untaxed Amount to Invoice"
- Check the values for the create SO
The amount for "Untaxed Amount to Invoice" is the amount with taxes included.
It is due to the fact that untaxed_amount_to_invoice field of sale.order.line is computed
from price_reduce field.
As price_reduce is computed from price_unit, if there is a tax that is included in the price,
price_reduce will also contain the tax in its value.
opw-2347571
closesodoo/odoo#59334
X-original-commit: 8c54ed42eef16817f198f10697820eddcc7d0c74
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
1. Lead to loose the tour: Remove the step of the tour that asks
to set an address (the address is auto-completed at free trial
based on domain name).
2. Bug: At step 3, it redirects to the
invoice settings to select a localization, when you click on
"install more packages", you are sent back to the sales app.
--> this bug is related to res_config_settings.js from base addon.
I tried to fix this bug by adding a data-attribute "discard" in the
res_config_settings_views and checking this additional condition in
the js.
3. Bug: Tour blocks at last step "send by email" on quotation.
After clicking on "sent" on the pop-up, there should be rainbow
effect to mark the end of the tour.
4. Bug: Sale order line: fix the blue color on Invoiced Quantity
only, instead of the full line
5. Put the "sample product" in active= false (it's necessary for
the sample invoice but should not be visible to the user, they
should create their own)
6. Merge the 2 dates fields related to expected delivery on sale.order
--> since other modules extends this module, I made the field
expected_date invisible and put the same value in both fields. This
value is the max of the order_lines.expected_date
closesodoo/odoo#59261
Taskid: 2277314
X-original-commit: 0f81816d4ddb0febd28f6c6bb5dd50ae570333e1
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the terms and conditions could not be html formatted text.
closesodoo/odoo#56512
Taskid: 2304199
Related: odoo/upgrade#1689
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce the bug:
- Let's consider a product P with three variants red, yellow and blue
- Let's set a customer lead time on P = 10 days
- Set Order Grid Entry on P
- Create a quotation Q and add P
- In the grid entry matrix add 1 red, 1 yellow and 1 blue
Bug:
The customer lead time of these three variants were not set on the lines.
opw:2337049
closesodoo/odoo#58675
X-original-commit: 0eae213d6c8a656ab2c045995e1f0643ff65df51
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
If an user that only has access to accounting but not to sale, tries to
validate an invoice created from a sale order, an access error will be
raised. That's because, when the invoice status changes, the invoiced
quantity on the related sale order is recomputed using the current user,
which may not have access to read sale order lines.
This commit fixes the above by ensuring the recomputation is performed
with superuser access rights.
closesodoo/odoo#58304
X-original-commit: 0bf30e1b5907997ae22d27cc420c3533940d634f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a SO
- Add a line with a lead time != 0, e.g. 7 days
=> the Expected Date is today + 7 days
- Add a note or a section on the SO
The Expected Date is today
This happens because we do not filter out notes and sections when
computing the minimum date.
opw-2340419
closesodoo/odoo#57792
X-original-commit: d3a6afe51fc4b864368acbc40a86ac6974d328dd
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Let's consider a rental product RP with variants
- Configure product configurator
- Create a rental order
- Select RP and set a quantity in the product configurator
- Click on Add
Bug:
When the rental.wizard was opened, the quantity was not taken into account and was reset
to 1.
opw:2321357
closesodoo/odoo#56913
X-original-commit: afe0f0d5566df9bccc28535e85dec98d3c7587b4
Related: odoo/enterprise#12871
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce
Enable optional products in sale order
Make a sale order with optional products for a portal customer
with taxcloud fiscal position. Validate the order.
Tax will be calculated on the sol.
Access the sale order as the portal user.
Add the optional product, verify the order and pay.
The optional product will get the taxcloud data
AFTER the order has been verified and possibly paid. As this should not
occur this add the override to calculate taxcloud data right after
adding the optional product
opw-2310614
closesodoo/odoo#56110
X-original-commit: a7a91d5de55817b7580f3cd3d262a9dcce7496e7
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: agr-odoo <agr@odoo.com>
Currently, if users try to send invoices / quotations / purchase orders to
themselves in order to look at final result, they can't do so because our
default chatter protection prevents sending mails to authors themselves.
This commit uses 'mail_notify_author' context key and allows users to send
mails from the header buttons available on SO / PO / invoices to themselves
if they are in recipients.
This commit targets only those buttons as this is the main case where we
want to allow people to send emails to themselves. In order to avoid
side effects no other use case is supported.
Task ID-2294130
closesodoo/odoo#56370
X-original-commit: 08c0dc929da38595e29a9d1db93065547cd98ad1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This provides a better API to search for records by name without the
formatting part (`display_name`).
This also simplifies all the overridings of `_name_search` that no
longer need to call `name_get()`. The call to `name_get()` is done in
method `name_search` in a generic way.
- The deadline of MO generated via procurements is calculated differently.
Now, it doesn't take anymore in account the manufacturing_lead
of the company (Security Lead Time of MO). The computation of planned date remains unchanged.
- The date_expected fields was duplicated with the date fields
except when the move was done. Merge both fields.
The only information lost is: we can't know what was the
scheduled date before processing move (`state` == done).
Indeed, the date becomes the actual move processing datetime.
- The `date` in `stock.picking` field contained the time of
(purchase) order `date_order` (`purchase.order`).
This field is was wrongly used in the kanban view where we
expected to see date_planned instead. Also, the `_order` used
this date instead of date_planned too.
- The `delay_alert` is activate independently of stock rules.
Then it is now activate in all case.
- Remove the auto-reschedulting process of stock move via
the stock rule (`propagate_date` and `propagate_date_minimum_delta`).
Replace it by a automatic deadline date (`date_deadline`) propagation.
The deadline is the promise done to/by vendor/client (SO/PO)
then it is a readonly fields on picking/move and MO.
- Now the Scheduled date (`date`) of stock move is never propagate
and it is only related to the Scheduled date of
related document (MO or picking).
- Now when a move is created from procurement (sale),
`date_planned` = `date_deadline` - `security_lead`.
- The `delivery_date` of sale is no editable after confirmation
and propagate as the deadline to related stock move linked to order_line
- Adapt filter and decoration of MO and picking.
- Because we are the client in case of purchase (PO), the promise of vendor
can be not respected. Then we add the lead security to the deadline
(inverse the sale order logic) of PO picking (promise reciept date
+ security lead) to match with the replenishment.
task-2246665
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.*
Replace wrong usages of any(list|recordset), by any(generator)
to speed up computations, avoiding list creations and/or looping twice on a recordset
for nothing.
any([generator]) => any(generator)
any(filtered) => any(generator)
closesodoo/odoo#55768
Related: odoo/enterprise#12360
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )
It was removed here https://github.com/odoo/odoo/pull/32303 but readded
later. We still don't want it for the same reasons.
Having it on related (non stored) is enough.
By specifying the with_company at a higher level:
1) The risk of multi-company conflicts decreases
2) We allow customizations to use _prepare_* methods to potentially
create records in other companies when needed.
closesodoo/odoo#55192
X-original-commit: 33c767e1778d2b1fc83aaaea92c3c2aa008b9520
Related: odoo/enterprise#12105
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Avoid concatenation of translated strings & raw values and/or other
translated values, and use the new _ API (by providing the formatting
values to ensure the fallback on the english terms in case of wrong
translation).
By including the expected values inside the string to translate, we
ensure that the formatted values are included at the right place in the
resulting translated text.
This also provides more information on the string to translate to
the translators, s.t. the chosen terms for the translations can be more
adapted to the translation context.
closesodoo/odoo#54635
Related: odoo/enterprise#11925
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The payment.transaction type field allows filtering some potential
payment methods down the line of a transaction being created; e.g. if a
subscription product is present in a quote, the payment's type should be
`form_save` to save the payment token for future use on the subscription
that will be created at confirmation.
The transaction that got created by sale flows did not set the type of
the transaction correctly, and this value was not propagated to the
rendering values of the acquirer. It now is.
This is necessary as part of task 2275051, where we need to know which
payment methods to enable in Stripe depending on a need for tokenization
or not (since some methods are not tokenizable).
closesodoo/odoo#54426
X-original-commit: 09dbbd77d83332c48f62b1c36c3b33ddbfa3a4eb
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closesodoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Issue
- Turn on Sales Product Configurator
- Create a product template with an attribute and an attribute value defined as "is custom".
- Create a new quote, add the template, and configure the product, entering a custom value.
- Save.
- Duplicate the Quote
Custom value missing.
Cause
Custom value (field product_custom_attribute_value_ids) not duplicated.
Solution
Add attribute 'copy=True' to field product_custom_attribute_value_ids.
opw-2279933
closesodoo/odoo#53827
X-original-commit: 0ca092361819bb198c87ca6772ec0e93a2158018
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Ivan Yelizariev