Previous fixodoo/odoo#135784 added a test to repair that references
a sale_order_line field that only exists when the sale_margin module is
installed. Unfortunately there isn't already a common module that
requires both repair + sale_margin and runbot doesn't do single module
app tests so this test slipped through the cracks.
To avoid the error when the nightly single module tests occur, we avoid
running the test when sale_margin is installed since it will still run
during standard runbot tests and ensure that the bug doesn't return.
closesodoo/odoo#137490
X-original-commit: 6343e2f3125bb48b01bf5b1ef7be36d86ae35f86
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@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>
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>
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>
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>
Improve the returns process by adding the following improvements:
- Removal of the 'return' operations type. Returns of deliveries now
become receipts.
- Update of the `stock_picking_return` wizard by removing the onchange
on picking_id.
- Show returns in the sale portal, with a new 'return label' PDF report
- Enable returns for multi-step receipts on purchases
Community PR: https://github.com/odoo/odoo/pull/118568
Enterprise PR: https://github.com/odoo/enterprise/pull/39761closesodoo/odoo#118568
Task: 3081370
Related: odoo/upgrade#4660
Related: odoo/enterprise#39761
Signed-off-by: Tiffany Chang <tic@odoo.com>
Rewrite the whole chart template mechanism, removing the templates
stored in the database. The new format will mainly use CSV.
Speed up install time
---------------------
* About half of the time of installing a localization for the first time is
taken by creating the template records. This new in code format gets
completely rid of this.
* Creating the template records could often not be done in batch because
of parent/children relations.
* The instanciation of the accounts on the company has been entirely
reworked too, by
- optimizing the order of creation of records to avoid UPDATE queries
- using precomputed fields to avoid UPDATE queries
- updating the translation in batch
- deactivating logging in the chatter
- avoiding access rights checks by checking the rights at the start
Overall, when installing a chart template for the first time, it is 4
times faster because half of the time spent on saving the template in
the database is not done at all anymore, and the instanciation on the
company is more than twice as fast.
Reduce technical debt
---------------------
There is no need to synchronize the templates with the real records
anymore. No need to use hooks to copy the data from one to the other.
It is easier to change a template in a stable version, which can often
be necessary due to legal reasons (i.e. a change of tax rates, reporting
tags,...)
Two modules have been removed:
* `l10n_generic_coa`: since there is nothing left datawise in this
module, it can be integrated in `account` for free. It is just code
and CSV.
* `l10n_multilang`: the fields that this module modified to be
translatable are now always translatable:
- there was an issue when updating modules that deleted all the
translations because the fields were not translatable at some point
during the loading of the registry, then they because translatable
again but lost all translations because of the column type change.
- most devs are not able to understand all the languages needed for
all the localization available. Therefore, english has been added in
the sources in most localization to understand better issues while
debugging.
- no need to call post init hooks anymore, doing the sync with the
templates.
- more: see "Translations" section
Because most of the data is now in CSV, it is also easier for product
owners to edit, audit, modify files themselves, removing one layer
during trivial development processes when only data should be changed.
More flexibility for declaration
--------------------------------
The data declaration can now be done easily in python or CSV.
A nice feature is that you can declare everything at once, even for some
more complex chart of accounts:
* if you have to set default taxes on accounts, would need to
- declare the accounts because accounts are required on the taxes
- declare the taxes
- declare the taxes to put on the accounts
This would lead to scatter information in multiple files. Now,
everything can be declared in the same place and the loading of the
chart of accounts will do the 3 steps automatically.
* if you have a relation of child/parent, you would first need to
declare the parents then the children, and the loading would not be
efficient because done one by one. Now, everything is done in batch
automatically without having to think about it.
It is also easier to update fields on records where there was no field
for that on the templates, like
* setting a restriction for journals on accounts
* setting specific values on the company
* modifying journals and linking them easily by using the xml_id instead
of having to compute it manually
Translations
------------
Some countries have multiple languages (i.e. Belgium uses officially
French, Dutch and German, and the CoA also has an official English
version) and we must support the languages in all these countries.
All these translations are known, and hard coded without using out
translation platform (Transifex). We also like to have the English
version (even if an official one doesn't exist) so that support can be
done more easily in databases using chart templates in other languages
(especially using a non roman alphabet).
Because the translations were not on Transifex for these records, it was
really hard to maintain: the translation templates (`.pot` files) were
not easy to extract as the automatic export would give values mixing
both the CoA and the menuitmes, the fields' strings,... But we don't
want to translate the CoA as we already know the value.
Managing the translations in the `.po` files was also annoying:
- it is easy to forget that the translations need an update too
- it requires a special editor, special terminal commands that everyone
is not familiar with
- it is easy to make mistakes in the source string
The new format is the following: `field@en_US` where `field` is the
translatable field (usually `name`) and `en_US` is the locale code.
This allows to have the whole declaration on one line, everything in one
file. It also makes the process easier when debugging: instead of
searching for the translation in the `.po` files, it directly appears
next to the configuration of the account/tax/... .
Update of the code
------------------
The code can be updated using this script
https://github.com/william-andre/transform_coa
Forward ports can be managed too by stashing/resetting/checkout the new
modules or the changes in the modules updated in the same PR.
task-2687567
Part-of: odoo/odoo#110016
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@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>
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>
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2296213
- create new repair instead of using the demo data to make further
extensions easier
- integrate the fees testing in an existing test
- test the created moves of a repair order
Purpose: When running tests, all the tests for the installed/updated
files are done. This commit adds a 'tagged' decorator that can be used to
tag tests. Combined with a new 'test-tags' CLI option, it adds the ability
to filter which tests are executed. For example, @tagged('slow') will
add a tag 'slow' to the test. The CLI option 'test-tags="slow"' will
only run tests tagged 'slow'.
One can use prefixes to select cases with tags.
'+' or no prefix means that the tests tagged with this tag are selected
for execution. '-' prefix will exclude the tests tagged with this tag.
Exclusion takes precedence over inclusion.
Also, by default, all Odoo tests cases are tagged 'standard' and with
the technical name of the module.
This means that when selecting tests with the 'test-tags'
parameter, if '-standard' is not specified, all tests tags are
going to be executed.
When tagging tests, one can remove such automatic tag by prefixing the
tag name with '-'. E.g. @tagged('-standard') will remove the standard
tag from the test.
Another example, if one wants to test the 'sale' module alone,
even without adding any 'tagged' decorator thos tests can be selected
like that: --test-tags="sale"
Tests are selected or deselected using a TagsSelector. When instanciated,
a string is passed with comma separated tests selectors like
'+slow,-standard'. When the 'check' method is called with a test as argument,
it returns True or False if the test has to be executed or not.
Tiffany Chang (tic)