Before this commit, the cancel button is visible in the done state and
on clicking showing the validation that it cannot be cancelled.
by the commit:
https://github.com/odoo/odoo/commit/8d37cf462badc25d911d3fa6d3382c6f7418904f
one of the cancel button in the form is made hidden in the done state,
similarly applying for the other cancel button also.
also currently on trying to delete a done repair order, it says to
cancel first and then delete the order, from the commit:
https://github.com/odoo/odoo/commit/8d37cf462badc25d911d3fa6d3382c6f7418904f
cancelling a done record is prevented, thus modifying the warning
message and its related pot file
After this commit, the cancel button will not be visible in the done
state.
closesodoo/odoo#118726
X-original-commit: 981f804ff507f693a395bb1146a33eb5f06d84a3
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, the accounting module had a setting on the selection of taxes used by the sales, purchase, website_sale, ... modules. In addition, the website_sale module had the same setting related to the accounting one.
This PR isolates the tax selection parameter in the website_sale module, and instead of using the tax selection, the accounting module will use rounding method (round per line, round globally).
Selecting one of the two will change the display of all account_move or other view using the tax selection setting.
Display changes:
In round per line, a column tax excluded will always be displayed while a column tax included will be in optional hide.
On the other hand, in the round globally, only the tax excluded columns will be available.
closesodoo/odoo#99209
Task-id: 2954332
Related: odoo/upgrade#3826
Related: odoo/enterprise#30853
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce the bug:
- Create a repair:
- Add any product to repair
- Add any other product as part of the repair
- Confirm the repair
- Start the repair
- End repair
Problem:
The cancel button becomes visible and clicking on it won't cancel the
moves, so it doesn't make sense to cancel a finished repair.
opw-3146606
closesodoo/odoo#112191
X-original-commit: f8c489b7484c054a7b870b22cf610b615bab2cc8
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Removes the constraint of using a pricelist and makes all sales flows
rely on the currency of the sale order (or repair order)
task-2735672
closesodoo/odoo#84920
Related: odoo/enterprise#24716
Related: odoo/upgrade#3642
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Support a real res_ids field on mail.compose.message model. Instead of relying
on active_ids from context, store it once for all at composer level and use
it in code. Active_ids usage is still done at default_get level, using it to
populate the field.
Improve usage of domain, renamed to res_domain to match other document related
fields naming. Add support of a res_domain_user_id field allowing to set the
user from which the domain should be evaluated.
Composer now runs on a list of IDs. Mass mail mode and comment mode are now
distinct from running on a singleton or on more records. Rendered or raw
mode is not triggered by
* mass mailing mode: always display raw mode, whatever the number of records;
* comment mode: display rendered mode when having a single record (like the
previous comment mode). Display raw mode when having either no records
either at least two records.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
currently the returned warning from the sale, stock and repair apps are not translatable to user languages.
this pr makes the string's translatable and correct the grammer of the warning.
closesodoo/odoo#108379
X-original-commit: 217115e68d117d7cf1eeb94794118819d6082547
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
mrp
===
- no time has been recorded on operations then give warning with apply button
- do not allow to mass edit UOM in any manufacturing state
- set value of lot/serial from MO and set read only on unbuild from MO
- remove "archive operation" icon
repair
======
Currently it is not possible to select a return on a repair order unless save it first. so after this commit user can able to select it without save it.
only show picking related to selected product
closesodoo/odoo#106571
Task: 2845380
X-original-commit: dd60647ce41547ecd00bbde45ddf564a7ada91c7
Related: odoo/enterprise#34403
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Previous fix
https://github.com/odoo/odoo/commit/72dff43a4da277b002966f5fd4045b7f9a3855ad
re-exposed uoms in the view even if the setting is not active, but we
prefer to avoid this if possible. In order to do this we ensure that the
uom is set even if it is not visible in the view. Most of these are
already handled by compute methods, but except for `repair.fee` so we
only add in a guarantee for that model.
Note that the write case is included in cases when:
- the uoms were previously activated and set => deactivated again
- demo data has different uoms set and uoms setting is not active
X-original-commit: 7e64ebb3d8d3f3d3749304a325eb073777b129dc
Part-of: odoo/odoo#104900
TLDR:
* invoices are implemented using computed methods instead of onchange
* the synchronization only happens when switching tabs in the Form view
to improve perfs.
_______________________________________________________________________
The whole engine of the synchronization of Invoices to the Journal
Entries has been refactored
* by using computed fields instead of onchange functions
* by synchronizing only from invoice to journal entry in `create` and
`write`
* by saving when switching tabs on the Invoice form, to synchronize
before showing the values
This comes with numerous advantages:
* no need to call the onchange methods manually
* no need to use the Form emulator to build invoices (i.e. EDI, OCR,
intercompany, ...)
* the performance for invoices with many lines improves drastically, going
from 2 minutes to 4 seconds to create an invoice with 500 lines
* the model is more declarative, we can now see how the values are computed
instead of having the values being copied from various places.
* remove the hack in `onchange` that disabled the recursivity of it,
which was unexpected and needed to be managed manually in all the
onchange methods
This means that:
* Some fields need to be exclusively computed on journal entries values
or invoice values, more specifically the Tax Summary widget.
It is now
- computed from entry lines, when opening the view
- computed from invoice lines when changing those, because the tax lines
will need to be recomputed anyways, erasing previously set values
- set with an inverse function when saving; after the sync has been done
* Some possible operations previously possible have been dropped.
(i.e. look at the removed test test_in_invoice_line_onchange_accounting_fields_1)
This is because such a behavior was undefined (how is changing the balance going
to affect the unit price? How is the amount currency going to affect it?)
_______________________________________________________________________
Implementation Details
----------------------
The "dynamic lines", meaning the payment terms and the tax lines are now
only created in the `create` and `write` functions.
In order to reduce code duplication, it has been implemented using
context managers used in both `account.move` and `account.move.line`
These context managers help comparing the values before/after, acting
like a local `onchange`, but getting benefit from the dirty flags from
the `compute` dependences.
This is relying on computed fields on the move (`needed_terms`) and on
the lines (`compute_all_tax`) which contain the values needed for the
related move.
Depending on the needed values and the existing values (`term_key` and
`tax_key`, respectively) the context manager will determine what needs
to be created/updated/deleted.
Some related changes are to produce a `dict` instead of a `str` for the
`tax_totals` (previously `tax_totals_json`) fields, by simplicity to
reduce the complexity of IO, and simplicity of debugging, because the
logic of the field needed to change (cannot be computed at the same time
anymore since it needed the lines to be synced)
By simplicity, and also because it makes more sense, some boolean fields
have been merged into `display_type`:
* `is_rounding_line`
* `exclude_from_invoice_tab`
* `is_anglo_saxon_line`
The `price_unit`, `quantity` and other "invoice fields" are now not set
anymore on lines that are not product lines since it didn't make any
sense to have it.
Performances
------------
You have to keep in mind that a simple `create` didn't compute a lot of
fields, for instance not taxes were set, no payment terms,...
Now it does.
```python
import random
from timeit import timeit
from odoo import Command
domain = [('company_id', 'in', (False, self.env.company.id))]
products = self.env['product.product'].search(domain).ids
partners = self.env['res.partner'].search(domain).ids
taxes = self.env['account.tax'].search(domain).ids
def create(nmove, nline):
self.env['account.move'].create([
{
'move_type': 'out_invoice',
'partner_id': random.choice(partners),
'invoice_line_ids': [
Command.create({
'name': f'line{i}',
'product_id': random.choice(products),
'tax_ids': [Command.set([random.choice(taxes)])],
})
for i in range(nline)
]
}
for j in range(nmove)
])
# After | Before
print(timeit("create(1, 1)", globals=globals(), number=1)) # 0.11 | 0.09
print(timeit("create(100, 1)", globals=globals(), number=1)) # 2.76 | 2.50
print(timeit("create(500, 1)", globals=globals(), number=1)) # 14.56 | 12.34
print(timeit("create(1, 100)", globals=globals(), number=1)) # 1.03 | 5.52
print(timeit("create(1, 500)", globals=globals(), number=1)) # 3.99 | 125.02
print(timeit("create(50, 50)", globals=globals(), number=1)) # 19.44 | 79.55
```
Another metric that can be used is running the test suite with
`--test-tags=/account` (only `account` installed)
* before: 404s, 267127 queries (366 tests)
* after: 318s, 232125 queries (362 tests)
Why this commit title?
----------------------
Someone told me that this was the perfect way of naming your commits.
c04065abd8
task-2711317
closesodoo/odoo#96134
Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
When creating an invoice from a repair order, the account mapping of the
fiscal position doesn't apply even though the tax one does
Steps to reproduce:
1. Install Repair and Accounting
2. Go to Accounting > Configuration > Invoicing > Fiscal Positions and
create a new fiscal position with:
- Name: 'FP test'
- Tax Mapping from 'Tax 15.00%' to a new tax 'Tax 10.00%'
- Account Mapping from '400000 Product Sales' to '450000 Other
Income'
3. Go to Sales > Products and create a new product 'Product A' with:
- Product Type: 'Consumable'
- Customer Taxes: 'Tax 15.00%'
- Income Account: '400000 Product Sales'
4. Create another product 'Product B' with same values except type which
is 'Service'
5. Go to Repairs and create a new repair order with:
- Any Product to Repair
- Any Customer (once set, edit the customer's fiscal position to 'FP
test')
- Invoice Method: 'Before Repair'
- Parts: add a line of type 'Add' with product 'Product A'
- Operations: add a line with product 'Product A'
6. Confirm the order, create an invoice and open it: the account mapping
of the fiscal position didn't apply (it should be '450000 Other
Income')
Solution:
Apply the fiscal position mapping on the income account of the product
opw-2902056
closesodoo/odoo#96038
X-original-commit: 02975a8a7b1803167a5ba8365cfbf29f80f84b2e
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
This allows to create a repair.order record without
the need to call the onchanges to set the uom and locations
or to set them manually during the `create` call.
For instance, this makes easier to create repair orders
using XMLRPC when you do not use multiple UOMs or multiple locations.
closesodoo/odoo#95321
Signed-off-by: Raphael Collet <rco@odoo.com>
This feature supports the use case of:
- a customer receives a delivery from you.
- there is a defective product in the delivery
- they schedule a repair (RO) + return (picking) for the product
We want to ease the creation/management of the repair order associated
with the return, therefore the following features are added:
- Create links between ROs and return pickings (smart button in return
of all repairs associated with it + field in RO)
- Option (requires active setting) to create RO(s) directly from a
return picking
Implementation notes:
- Because return picking type doesn't have its own "Type of Operation"
(it is 'code'='incoming'), we default to only incoming picking types
that have at least 1 other picking type it is the
'return_picking_type_id' of.
- Originally a Wizard for choosing which/how many products should have
ROs created for them was designed (i.e. to match return wizard + to
multi-create ROs), but this was determined to be too complicated due
to SN/lot selection. Instead simple approach of creating a single RO
each time button is pushed was implemented to match the helpdesk >
repair button workflow.
- ROs are purposely allowed for 'draft' and 'cancelled' returns/moves to
support different types of workflows (e.g. RO is confirmed before
return is)
closesodoo/odoo#85157
Task: 2732517
Signed-off-by: Arnold Moyaux <arm@odoo.com>
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Suppose a tracked-by-usn and consumed product returns in the stock
thanks to a repair order. Using again this component in a new
manufacturing order will raise an error
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create two products P_finished, P_compo
- Storable
- P_comp tracked by USN
3. Update the quantity of P_compo:
- WH/Stock: 1 x Lot01
4. Create a manufacturing order MO:
- Product: P_finished
- Components:
- 1 x P_compo
5. Confirm, Check availability and Mark MO as Done
- (Lot01 should be consumed)
6. Create a repair order RO:
- Product: P_finished
- Parts:
- Type: Remove
- Product: P_compo
- Lot: Lot01
- Destination Location: WH/Stock
7. Confirm RO, Start RO, End RO
- (There should be one Lot01 available in stock)
8. Repeat 4-5
Error: When checking the availability on the MO, Lot01 is correctly
reserved. However, when marking the second MO as done, a User Error is
displayed: "The serial number Lot01 used for component P_compo has
already been consumed" although this lot should be available
When checking the uniqueness of the lot, nothing includes the products
back in stock thanks to the repair orders.
OPW-2701668
closesodoo/odoo#82544
X-original-commit: 3d9355f90fa1dd9436f1745c515c89947ed04de0
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
* Do not rely on context, everything should be cleary specified through
parameters
Catch context keys in an unique targeted place to improve code clarity
* Drop strange old API
* do not provide unused partner parameter anymore
* do not provide products, qty as a list of tuple, we only request the
same qty for all products anyway
* Clear methods, add/adapt comments and docstrings
* Reduce potential side-effects of context content.
This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: odoo/odoo#80434
RATIONALE
Currently we can specify email used for notification layouting through context
use in mail composer. It is then propagated to message_post, stored on
mail.message and used to encapsulate emails sent based on posted messages.
SPECIFICATIONS
Get rid of context usage (``custom_layout``) and use a real field on composer
model: ``email_layout_xmlid``. Use now a default value coming from context
(default_email_layout_xmlid) instead of custom_layout.
Support old context key in composer for backward compatibility, working like
a default value for the field itself.
Task-2621326 (Mail: add 'view' button in 'light notification template')
Task-2647302 (Mail: add layout field in composer)
UPG odoo/upgrade#2829
Part-of: odoo/odoo#76418
Steps to follow
- Enable group_show_line_subtotals_tax_included
- Create a repair order and add a tax to a line
-> The subtotal doesn't contain the tax amount
opw-2513287
closesodoo/odoo#78631
X-original-commit: 133888a1859d81a252177b58b046b54d22ba5ca8
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Hubert Van De Walle <hubvd@users.noreply.github.com>
When find a location_id for repair.line, we didn't restrict the location
to have same company_id with the repair.order. Add it.
closesodoo/odoo#78350
X-original-commit: dff911a1b006a542bf9b082c76910a2d8346fef1
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Before this commit, User was allowed to delete repair order which
is linked to posted invoice by moving it to Draft.
With this commit, user is not allowed to delete repair order linked to
a posted Invoice.
closesodoo/odoo#75109
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Followup of odoo/odoo@cb4f597410 and odoo/enterprise@971f3ed9ae
We have converted string into markup string in repair as we cannot concatenate
strings directly to Markup string. And if we try to do it we will see the
html elements '<br/>' in field value, so we have to convert '<br/>' string
into markup language to avoid this.
Also avoid adding pseudo-void html content in narration.
LINKS
Task Id-2558824
PR odoo/odoo#74795
PR odoo/enterprise#20117
How to reproduce the problem:
- Install the repair App
- Repairs -> Create (a Repair Order) (and activate the debug mode)
- Change the Location Field to something else (than the usual default WH/Stock)
- Open Developer Tools -> Set Defaults
- For Defaults, choose "Location = [the changed Location]", "All Users" -> Save Default
- Create a new Repair Order: the Location is not set to the default we set earlier through the Developer Tools
Cause of the problem : an Onchange method was overriding the default Location
Solution : it will now check, in the onchange, if the change is necessary, before overriding the default.
opw-2545876
closesodoo/odoo#74871
X-original-commit: 9877ad1599513338c5333d3a728edb8d6ebcac26
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
Models -> fields
1) maintenance.request -> description
2) maintenance.equipment -> note
3) maintenance.equipment.category -> note
4) mrp.workcenter -> note
5) mrp.workorder -> operation_notes
6) mrp.routing.workcenter -> note
7) repair.order -> internal_notes
8) repair.order -> quotation_notes
Task Id: 2499504
X-original-commit: 0cca26b5358cd9d69a65c6b93cfecb33d7e659c5
It replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
Models -> Fields
1) sale.order -> note
2) sale.order.template -> note
Task Id: 2499504
X-original-commit: 6a345c2695129a5cd907e5e23e057871ebf9ebfa
Have 2 repair records with the same partner_id, ready to be invoiced
In list view select both records and click Action>Create invoices
In the wizard check 'Group by partner invoice address', create invoices.
Separate invoices will be created, but while grouping 1 invoice should
be created joining the 2 repairs
opw-2476539
closesodoo/odoo#70434
X-original-commit: 8f6e2fa1096f57ace6c84ae6083ab77ee37a69a1
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
When adding a product to a repair order, the module automatically adds
all product's taxes, even if some taxes belong to other companies.
To reproduce the error
(Need 2 companies C01 and C02. Let C01 be the current company)
1. Create a product P
- Must have a tax T_C01
2. Switch to C02
3. Edit P
- Add a tax T_C02
4. Activate C01
5. Create a Repair Order
- Add a customer
- Add a line with product P
Error: Both T_C01 and T_C02 are added. However, since C02 is the current
company, T_C01 should not be added.
(Similar issue possible with `repair.fee`)
OPW-2486791
closes#68079closesodoo/odoo#70352
X-original-commit: 75a122bbae3a32bfa79da3506179fc63a8bced5d
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Steps to follow to reproduce the bug :
- Install the Repairs and Accounting application
- Create a new user and give him only access to Accounting
- Connect with this user
- Create a draft invoice
- Try to delete it
- Access rights error is triggered.
Problem:
When we delete an invoice and the Repairs app is installed, we check if it is not an invoice related to a repair.
But the user does not have access to “repair.order”, so we can not check the field "repair_ids".
opw-2507867
closesodoo/odoo#70095
X-original-commit: b5588246a0e032c92b8443e67875ff4146858fe8
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
The purpose of this commit is to improve the repairs module general
workflow, to make it more intuitive and more flexible.
1. Change in the way the Repair Reference is created. It is now always
autogenerated. A new Repair Description can be used.
2. Make the 'Parts' and 'Operations' tabs editable up until (and
including) the stage 'Under Repair'.
3. Make the 'Lot/Serial Number' Field non mandatory for tracked
products, up to and including to the stage 'Under Repair'. If the
user forgot to specify the serial number and clicks on 'End Repair',
shows the exisiting error message.
4. Add product moves related to the repair order in a smart button at
the top right of repair, just like for a finished manufacturing order.
5. Add a Sale Order field in the repair form to make it easier to
perform return if needed.
6. When a component is not tracked by serial/lot number, leaves lot/serial
number read only.
7. Separationo of notes and internal notes into 2 seperate tabs.
8. Lot/serial field always visible but readonly when no tracking.
Task ID-2424420
closesodoo/odoo#66496
Related: odoo/upgrade#2327
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Steps to reproduce the bug:
- In Repair: create a new repair order
- add some product to "Add' and operation.
- Select option for Invoice Method: Before/After Repair.
- Confirm Repair, finish repair and create invoice.
Bug:
No line was created in the invoice
PS: the invoice_line_ids were popped from function _move_autocomplete_invoice_lines_create
opw:2493091
closesodoo/odoo#68587
X-original-commit: 952ff15a3af90bb32660262b4fd32ca8a1172eac
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
commit 38711e9f9c prevent multi company issues.
But it goes a litle too far in restriction and prevent to put a service
in the repair fee. Which is a feature since user would like to register
and invoice human ressources in maintenance cost.
closesodoo/odoo#64033
X-original-commit: 64de68b4420eb4d82ff2130dfaa310e40775a0b7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.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.
Fine-tuning of 9d7d618220e27024321a75be0058db2289115af2
Although the mentioned commit delays the consumption of a sequence
number at creation, it has the drawback to not generate one if the user
modifies the name.
In practice, we still want to generate a RMA number even if there is a
custom name. A good balance is to generate the RMA number if the user
leaves the `/` at the beginning of the name. If the user removes the
`/`, we don't generate the RMA number.
opw-2301412
closesodoo/odoo#57932
X-original-commit: 2ad9b4b2b5780c20a0cd77c48b24dcb76d69f912
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- On Safari, go to Module Repair
- Create a Repair Order
- Add a new line L
- A default type Add was set
- Set a product P on L
Bug:
The default value was reset
opw:2319954
closesodoo/odoo#57332
X-original-commit: 3aa92c1805f9d47dad4655b3ba49d08c319ef1df
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When a field is specified as widget="monetary" it makes sense to have the
currency actually shows. It won't happen if currency field is not present
within the view.
An heuristic to detect missing currency field presence when using monetary
fields or monetary widget tag will land soon in master. As this commit targets
a stable version only view fixes are provided.
Task ID-2329114
PR #56946
X-original-commit: 9c1c848ad1e8fef11320e2a162b008de7e304bcb
- Install Contacts and Repairs
- Go to Contacts and configure Payment Terms of Contact X (i.e. 2 Months)
- Go to Repairs and create a Repair Order:
* Select Contact X as Customer
* Select "Before Repair" as Invoice Method
* Add Parts or Operations
- Confirm Repair and Create invoice
The Payment Terms of the created invoice is the default one and not the Payment Terms of Customer.
opw-2304818
closesodoo/odoo#55152
X-original-commit: 351718d5f579fca4945538c78e63aa50118af2b4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a repair order
- Cancel the creation
- Create another repair order
There is a gap in the sequence number.
The gap is due to the fact that the sequence number is consumed by the
`default_get`.
Although this is a change of behavior, the actual one is not really
expected. Even if a gap is possible with the sequence, we don't want to
consume a number every time we get the default values.
opw-2301412
closesodoo/odoo#55005
X-original-commit: 9d7d618220e27024321a75be0058db2289115af2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a repair order
- Choose a customer A
- Change the invoicing address to customer B > set default
- Create invoice
The delivery address set on the repair order is not taken into account
on the invoice. The delivery address field on the invoice stays empty
despite having a delivery address set up on the repair order.
opw-2285659
closesodoo/odoo#53831
X-original-commit: e109faec5f1e14864addfb1eb56c508ab04f6eb0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
niyasraphy