1. Add Confirmed and Under Repair section to repair kanban cards.
2. Modify default filters for repair orders.
3. Modify the repair's location_id field's name
4. Following recent changes on stock.picking.type, adapt return option
creation on repair operation type defined as return.
5. Only return transfers are proposed on the repair orders.
6. Filter product_id selection based on set picking_id and vice-versa
Task : 3369400
Upgrade : odoo/upgrade#5108closesodoo/odoo#133932
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Since https://github.com/odoo/odoo/pull/110737, it is better to use
`_read_group` instead of `read_group` in the backend. In fact, the
public method is less efficient (it computes display_name of relational
groupby, extra order, ...) and more verbose.
This commit replaces these new uses of `read_group` with `_read_group`.
closesodoo/odoo#136381
Related: odoo/enterprise#47826
Signed-off-by: Raphael Collet <rco@odoo.com>
When calling action_repair_done on a Repair Order that has been created
from a Sale Order (which is done by adding a product.template with field
'create_repair' set to True), we should update the delivered quantity of
the product responsible of the creation of the Repair Order if and only
if this product Invoicing Policy is in ['Ordered Quantities',
'Delivered Quantities', 'Prepaid/Fixed Price'].
closesodoo/odoo#136195
X-original-commit: fcbc689dc37cafd5a0cba7b57a2f40ad6acf4e26
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Mathias Mathy (mama) <mama@odoo.com>
With the removal of the repair.line model, we must now use the stock.move model instead.
The smart button on stock.lot should only show repair orders where the related product is used as a component however it shows all repair orders containing the product.
Now, it will correctly only select repair orders where the product is a component based on the repair_line_type of the stock.move.
Also renamed repair_order_ids and repair_order_count for easier differentiation with new fields.
Part-of: odoo/odoo#129933
Added a todo count field on the button where the lot is the product being repaired.
Changed the texts to better fit the buttons.
Part-of: odoo/odoo#129933
Steps to reproduce the bug:
- Create a storable product “P1”
- Create a Transfer:
- Operation type: delivery order
- Product: “P1”
- Validate the delivery
- Create a return of the delivery:
- Confirm and validate the return
- Create a repair order from the delivery
- Set the product “P1”
- Confirm, start and end the repair
Problem: A stock move is created when the repair is completed, but it's
linked to the return picking what is wrong. When a 'repair' order is
created, the 'default_picking_id' is passed into the context to be set
in the 'repair.order'. Consequently, when the repair is completed and
the stock move is created, the context isn't cleared, leading to the
utilization of the 'default_picking_id':
https://github.com/odoo/odoo/blob/5d25900cd88ebc1fd16b0bd6ebba4602a13e9d76/addons/stock/models/stock_move.py#L317
In the button, no context is passed as a parameter:
https://github.com/odoo/odoo/blob/86aa7b78aadee5747c93b4bd27046cfaed1e438d/addons/repair/views/repair_views.xml#L36
opw-3269813
closesodoo/odoo#135939
X-original-commit: 558c647d5c70f7729c663ec3d45fb0cae813db04
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”
- cost= $100
- Create a repair order:
- select any product in the product to repair
- add “P1” as component
- create the quotation from the repair order
Problem:
The cost is not computed correctly and is set at 0 in the
`sale.order.line`
opw-3502317
closesodoo/odoo#135822
X-original-commit: b95ed3617f465a655c8f918bee8edc673c8f202b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Legacy code still use 'onchange' on the 'stock.picking.type' field code
to compute the different xxx_location_id.
As it is no more viable, this commit replace all these onchange by
compute methods.
These changes also has a side effect as some already existing compute
methods now get a set of 'stock.picking.type' in input, such that these
methods are also updated to handle this case.
closesodoo/odoo#134650
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
As the `default_remove_location_dest_id` field of the stock.picking.type
model is required, it is intended to be set by the user, and so it
must be editable rather than readonly.
Moreover, for accounting purpose, we want the ability
to modify `default_location_dest_id`.
Finally, we ensure to set a default value on all locations when
selecting 'repair_operation' as code.
closesodoo/odoo#134587
X-original-commit: 7504484ba2ebc93963bc0dec6441e351caee2638
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Mathias Mathy (mama) <mama@odoo.com>
Minor cleanup after odoo/odoo#104741 thanks to edge-cases and the fun
complexity of logistics code. Fixes include:
- removing some readonly=False that were added on computed/stored fields
that already have an inverse func or were already not readonly (i.e.
redundant => cleanup)
- fixed visibility of qty to prod in subcontractor portal view of a MO
(i.e. yay they know how much they're supposed to make again)
- remove unused imports
- adding back in readonly functionality of default dest of repair
operation type (and removing the now useless field override that used
to add in the readonly functionality)
- adding back in the `_set_product_qty` inverse function since it was
probably removed by mistake (and is still important to have)
unrelated to viewpocolypse change, also fixed:
- mobile view of PO was for some reason allowing products to be changed
in already confirmed/done POs, which could lead to some inconsistent
data => made this consistent with existing desktop view behavior
closesodoo/odoo#133502
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This fix splits the compute method of fields location_id,
location_dest_id, parts_location_id, recycle_location_id. This enables
to independently compute those fields at record creation when some of
them have a default value.
closesodoo/odoo#124614
Signed-off-by: Raphael Collet <rco@odoo.com>
These changes are made as a result of simplifying attrs and 'states' in
views. However, they should have remained in a separate commit. When
applying the script making the xml changes (used later for the migration
script), the script checked the definition of the python fields in order
to convert the information into a python expression. Therefore, this
commit is not applied when the script is applied to xml changes.
During this attribute deletion pre-existing errors were found. Part of
the code was using the boolean values of 'states' and another part of
the code was not. The behavior could therefore be different (in cases
where readonly on the field had the same value as the ballan in
'states').
Following the deletion of 'states' and without the application of the
view migration, the js tests (tower) were no longer functional. Tests
using the Form view suffered the same effect. There are few tests that
had to be adapted, including two tests in business accounting (updated
by the accounting team). A test for column_invisible did not work. Test
checking if the test system triggers an error if we try to write on an
invisible field. It turns out that Form was testing on the value of
invisible but not taking into account if the column was invisible. The
test system fix is applied separately because there were a lot of tests
that were incorrect.
Part-of: odoo/odoo#104741
Main changes include :
- Separate Repair and Sales/Invoicing functionalities
- Possible binding between a Sale Order and many Repair Orders
- Specific 'repair.line' model is now replaced by a 'stock.move' inheritance
- Added a new 'Repairs' Operation Type to warehouse(s)
Task : 3046560
Enterprise : odoo/enterprise#36088
Upgrade : odoo/upgrade#4391closesodoo/odoo#106911
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
When we include the author in the recipients of the quotation email of a repair order he doesn't receive the email.
Steps to reproduce the error :
1- create a repiar order
2- add the author in the list of recipients
3- send the email
The origin of the problem is that mail_notify_author=False , se we need to add it as True when we have the author in the recipients.
Similar old fix : https://github.com/odoo/odoo/commit/f49dbf595c870b682f36c11443c9cf1a9a027474
opw-3295744
closesodoo/odoo#126986
X-original-commit: d4d48526867e93295d93d4504e824cfdc2b146a7
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
add the following features:
- add location in form , kanban and list view. Change location creates move
- add smart button for repairs
- add next activity widget in list and kanban
- from the lots/SN smartbutton on the product form, open the kanban view
- show the last delivery partner on serial
closesodoo/odoo#117316
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
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>
Mathias Mathy (MAMA)