Steps to reproduce the bug:
- Enable “subcontracting” in the mrp settings
- Create a storable product “P1”:
- Add a vendor:
- supplier: “Azure interior”
- currency: euro
- price: 20
- Add a BoM:
- Type: subcontracting
- add any product as component
- Save
- Check that the currency of the company is in dollars
- Click on BoM overview
Problem:
The seller's price is displayed with the dollar symbol, but it is not
converted into dollars
opw-3085392
closesodoo/odoo#108187
X-original-commit: 05a8abde43ef6870d9494e34810632b9b2091e63
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
The problem is that when you archive a company and then install
subcontracting, you get a traceback.
Step to reproduce (in a multi-company environment):
-install 'stock'
-archive a company
-install 'mrp_subcontracting'
-->traceback
Explanation:
When installing the 'mrp_subcontracting', there's a search on all
(active) companies in order to add a subcontracting location for each
of them (this is is triggered by
'/odoo/addons/mrp_subcontracting/data/mrp_subcontracting_data.xml').
But there is still a warehouse linked to the archived company.
So when adding routes to all warehouses and looking for the
subcontracting location of the archived company, it is set to
False. Which is not intended and causes the traceback.
Solution:
Add '.with_context(active_test=False)' to the search for the companies
in '_create_missing_subcontracting_location(self)', so the missing
subcontracting location will be created for the archived companies too.
Discussion:
-The ability to archive companies is new to Odoo16 (implemented due to
the new pricing).
-Here I considered that we want to create a subcontracting location for
an archived company instead of taking action on the warehouse linked to
the archived company (like not considering it when creating routes).
I did this because a company can be unarchived and with this fix, it
will not cause issues.
-I think other problems similar to this one (in any app), should appear
in the future.
opw-3039495
closesodoo/odoo#107168
X-original-commit: 1dcdbe9e3cc21af50ed580c032b1927e21c3c24b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Since fixes done on the bom overview had to be done in a released
version, no method signature changes could be done, hence the use of
excessive context keys to bypass it.
Changes the signatures so that future work is done on better grounds,
and so that each method explicitely asks for what parameters it needs to
do its work.
closesodoo/odoo#107006
Related: odoo/enterprise#34577
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Before this commit, the rules were checked related to the currently
selected warehouse. Doing this didn't allow to check the subcontracted
locations for their related rules (like Drophip subcontractor on order).
The point here is that when no rules are found within the warehouse, it
checks the subcontracted location of the parent if the parent is
subcontracted itself.
Part of task-2985735
X-original-commit: feeef868093042ae4cb788d513c02244b8c36623
Part-of: odoo/odoo#106935
Before this, when working on a bom with variants, when checking the
parent from the component / child_bom, it would always take the first
variant since it used the bom's product_template.
This could lead to incorrect data when working with subcontracting, as
when another variant from the first would be selected, when fetching
quantities no parent info would be found as it would seek info from the
first variant of the bom instead of the correct one.
By doing this, we can now have the right variant and fetch the right
informations.
Part of task-2985735
X-original-commit: c855038c73e2c964ef78b41090c35e3a07d30f9b
Part-of: odoo/odoo#106935
In large database, if you try to get all subcontrat quant you can crach postgres with a big query.
closesodoo/odoo#106543
X-original-commit: aa104980d483efef087198dc5bb70ec63a47ed7e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When click action_show_details button on portal, the field product_id
and product_qty are clickable. Fix it
closesodoo/odoo#103346
X-original-commit: 717d501cbf7e321124ddbe9d9061221ea97787b5
Signed-off-by: Tiffany Chang <tic@odoo.com>
1. Except for registering components, the portal should be readonly
2. Don't open sm form when click it.
closesodoo/odoo#102935
X-original-commit: 4c5ba480e91b7e06c49b3683c36ff0a9aac9b60f
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
Within Purchase tab:
- Make Quantity hidden by default.
- Move Currency right after Price.
Move Purchase Description to the right of Vendor Bills.
closesodoo/odoo#102702
Task: 3004014
X-original-commit: b3e78b5a8f825650123004a8b8677aaacfe6b43e
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Jean-François Aubert <ajf@odoo.com>
The `is_subcontracting_location` setting is intended only for
complicated route/rule use cases therefore we make it visible
only in debug mode to prevent users from setting this value and
unintentionally creating a lot of new routes/rules unnecessary.
Additionally, it is expected that users who previously set these up
manually will not want their custom rules/routes changed but will still
need the existing behavior to continue, so we restore the previous check
for subcontracting locations set as sublocations of the primary company
subcontracting location.
Follow up to task: 2720393
Part-of: odoo/odoo#100219
Translated fields no longer use the model ir.translation. Instead they store
all their values as JSON, and store them into JSONB columns in the model's
table. The field's column value is either NULL or a JSON dict mapping language
codes to text (the field's value in the corresponding language), and must
contain an entry for key 'en_US' (as it is used as a fallback for all other
languages). Empty text is allowed in translation values, but not NULL.
Here are examples for a field with translate=True:
NULL
{"en_US": "Foo"}
{"en_US": "Foo", "fr_FR": "Bar", "nl_NL": "Baz"}
{"en_US": "Foo", "fr_FR": "", "nl_NL": "Baz"}
Like before, writing False to the field makes it NULL, i.e., False in all
languages. However, writing "" to the field makes its value empty in the
current language, but does not discard the values in the other languages.
Here are examples for a field with translate=xml_translate:
NULL
{"en_US": "<div>Foo<p>Bar</p></div>", "fr_FR": "<div>Fou<p>Barre</p></div>"}
Change for callable(translate) fields: one can now write any value in any
language on such a field. The new value will be adapted in all languages, based
on the mapping of terms between languages in the old values. Basically the
structure of the value must remain the same in all languages, like before.
Reading a translated field is now both simpler and faster than the former
implementation. We fetch the value of the field in the current language by
coalescing its value with the 'en_US' value of the field:
SELECT id, COALESCE(name->>'fr_FR', name->>'en_US') AS name ...
The raw cache of the field contains either None or a dict which is conceptually
a subset of the JSON value in database (except for missing languages). For the
sake of simplicity, most cache operations deal with the dict and return the text
value in the current language.
Trigram indexes have been adapted to the new storing strategy, and should enable
to search in any language. Before this change, only the source value of the
field ('en_US') could be indexed.
Computed stored translated fields are not supported by the framework, because of
the complexity of the computation itself: the field would need to be computed in
all active languages. We chose to not provide any hook to compute a field in
all languages at once, and the framework always invokes a compute method once to
recompute it.
Code translations are no longer stored into the database. They become static,
and are extracted from the PO files when needed. The worker simply uses a cache
with extracted code translations for performance. This is reasonable, since
fr_FR code translations for all modules takes around 2MB of memory, and the
cache can be shared among all registries in the worker. Changing code
translations requires to update the corresponding PO file and reloading the
worker(s).
Performance summary:
(+) reading 'model' translated fields is faster
(+) reading 'model_terms' translated fields is much faster (no need to inject
translations into the source value)
(+) searching translated fields with operator 'ilike' is much faster when the
field is indexed with 'trigram'
(+) updating translated fields requires less ORM flushing
(-) importing translations from PO files is 2x slower
Some extra fixes:
- make field 'name' of ir.actions.actions translated; because of the PG
inheritance, this is necessary to make the column definition consistent in
all models that inherit from ir.actions.actions.
- add some backend API for the web/website client for editing translations
- move methods get_field_string() to model ir.model.fields
- move _load_module_terms to model ir.module.module
- adapt tests in test_impex, test_new_api
- because env.lang is injected into SQL queries, its returned value is
now guaranteed to correspond to a valid active language or None
- remove wizard to insert missing translations (no longer makes sense)
task-id: 2081307
Co-authored-by: Fabien Pinckaers <fp@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
XML files are now declared in python module manifests. During the qweb
't-call-asset' directive, assetbundle will fetch the declared xml files,
apply the inheritance (t-inherit) and create a javascript service (for
eg: 'web.assets_backend.bundle.xml') which is added at the end of the
*.js mimifier file.
When the debug mode is activated, comments are added in the template
indicating which file the template comes from as well as the
inheritances applied to it.
****
JavaScript:
assets.js (module @web/core/assets) takes care of loading libraries,
javascripts and styles.
`loadJS(url)` (loads the javascript and returns a resolved promise when
the templates are also loaded via the '*.bundle.xml' service)
`loadCSS(url)` (loads the style a resolved promise when the file is
loaded)
`loadXML(xml, app=assets.defaultApp)` (load template into
application/owl, used by the `*.bundle.xml` services)
`getBundle(bundleName)` (get the bundle descriptor)
`loadBundle(desc)` (load the files and bundle from a descriptor)
templates (XML element content all owl templates)
A new `ready(serviceName)` method on boot.js lets you know when a
service is loaded are the require.
The xmlDependencies attribute no longer exists.
Python:
The xmls taken into account by assetbundle.py, applying `t-inherit`
inheritances and adding an `name_of_the_bundle.bundle.xml` service in
the generated JavaScript file.
****
Every manifest changes is into the next commit, except 'web_tour' in
this current commit as example.
Part-of: odoo/odoo#95500
This commit allows the user to archive/unarchive subcontracting rules by
toggling warehouse settings `Dropship Subcontractors` and `Resupply Subcontractors`.
Additionally, if there is no warehouse with a setting enabled, the corresponding global
routes are archived as well.
Part-of: odoo/odoo#95770
This commit introduces a new pick type used when dropshipping subcontractors,
specifically when the PO resupply relies on the dropship mechanism
this is done by using it for the rules of the `Dropship subcontractor on order` route
Part-of: odoo/odoo#95770
Before this commit, to access the location subcontractors, you needed to search
everytime, the one2many will provide this as well as cache the result for future use.
Taskid: 2848013
Part-of: odoo/odoo#95770
The goal of this revision is to get rid of the `groups_id` field of the model `ir.ui.view`.
- This feature wasn't really known or used by most developers,
and not straight-forward to understand.
Removing it allows one less complicated thing to learn for developers.
Besides, thanks to odoo/odoo#95729,
changing the behavior of the `groups=` attribute,
we can easily get rid of this `groups_id` feature
by simply adding `groups=` in the elements of the views
using the `groups_id` field, it will have the same effect:
adding the elements in the view only for the users part of the specified group.
- By getting rid of the groups_id many2many field on ir.ui.view,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the groups_id groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
Part-of: odoo/odoo#98551
The 'Structure & Cost' report has been changed to 'Overview', changing
some of its functionnalities. The override previously done in
mrp_subcontracting must be adapted to match the changes done in the mrp
module.
Also, the report has been converted to OWL in the process, requiring
changes in the overriden files as well.
Finally, the now obsolete code only related to the old 'Structure &
Cost' report has been removed.
Task-2628323
Part-of: odoo/odoo#93194
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Ease subcontractor stock tracking by using dedicated locations.
Simply declare location as a subcontracting one (rules are
automatically adapted) and set it on vendor.
closesodoo/odoo#88644
Task: 2720393
Related: odoo/upgrade#3755
Signed-off-by: Tiffany Chang <tic@odoo.com>
Previous fix: https://github.com/odoo/odoo/pull/84631 missed the case
when raw_move_ids have already done move_orig_ids (i.e. when 2/3 step
MOs or subcontracting w/ resupply contractor). This made it so when
MOs are backordered, these moves would not be reserved even though they
were in the original MO.
This issue was fixed during a refactoring (reserved amounts are now
distributed to backordered MOs), but this commit will add a test to
prevent the issue from returning in the future.
Part of Task: 2777571
Original PR fix (pre-refactoring): odoo/odoo#91460closesodoo/odoo#97383
X-original-commit: a825d9ed715b369128c876174ca6ebfac72adbe5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce:
- create a subcontracted product (i.e. create subcontract BoM)
- create and confirm PO for subcontracted product (qty > 1)
- try to decrease PO qty for subcontracted product
Expected Result:
Since receipt is not yet validated, the qty in the receipt should
decrease (it will in the subcontract MO as well, but this doesn't matter
since no one should work directly with the MO)
Actual Result:
A validation error occurs saying the qty to produce must be non-negative
We allow neg demand qtys to be proprogated from SOs and POs since
https://github.com/odoo/odoo/pull/76752 . While we added in a check to
make sure MOs are not created when a neg qty change is proprogated, we
forgot to add a check for subcontracted created MOs, hence the
validation error (i.e. the neg qty change is trying to create a
subcontracted MO of a neg amount.)
Task: 2777571 (issue 2 of additional issues)
X-original-commit: 251f146b6ecb0e2d428089669199a6deb3a6c060
Part-of: odoo/odoo#97383
Fixes a few incorrect subcontracting UX behaviors:
- When subcontract BOM is flexible, the record burger should always show
so user can more easily record varying quantities
- When `show_operations=True` then `action_assign_serial` button in
Operations tab should only show if subcontract BOM is NOT strict AND
has no tracked components (instead of always showing regardless of BoM
consumption and its components)
- When a subcontract receipt is backordered, the Done moves should no
longer return `_action_record_components`.
- When 'show_operations=True' for receipts, we shouldn't display the
subcontracting component lines in the Detailed Operations tab
Task: 2777571
X-original-commit: e9b9fe541df984bba33c4f44d48e57820ea4968f
Part-of: odoo/odoo#97383
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>
It now uses the new owl code, instead of the legacy list view, which
will be removed in the future.
closesodoo/odoo#96595
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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>
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
Currently the linked receipt (in case of subcontracting)
is visible in the tree view and search view of every MO.
However we want to limit the feature to landed cost scope
since it's only useful in that case and it adds noise otherwise.
We need a new module since we don't have any bridge between
subcontracting and landed costs
closesodoo/odoo#89399
Signed-off-by: Steve Van Essche <svs@odoo.com>
BoM Structure & Cost report has different errors:
- The product cost of a subcontractor included in a product doesn't
scale with the quantity of the product (Issue 1)
- The BoM cost of a product composed of a subcontractor doesn't include
the subcontractor price (Issue 2)
- The BoM cost of a component composed of a subcontractor doesn't scale
with the quantity for the subcontractor price (Issue 3)
Steps to reproduce:
1. Install mrp_subcontracting_purchase
2. Create a product 'TEST 1', in the Purchase tab specify 'Azure
Interior' as vendor with price 5$
3. Create a bill of material for the product 'TEST 1' with BoM type
'subcontracting', subcontractor 'Azure Interior' and product 'Bolt' as
component
4. Create another product 'TEST 2', in the Purchase tab specify 'Azure
Interior' as vendor with price 8$
5. Create a bill of material for the product 'TEST 2' with BoM type
'subcontracting', subcontractor 'Azure Interior' and product 'TEST 1'
as component
6. Go to the BoM Structure and Cost of product 'TEST 1'
7. The product BoM Cost doesn't include the subcontractor price (it
should be the sum of its components) (Issue 1)
8. Increase the quantity of the product by 1
9. The subcontractor's product cost doesn't change (it should increase
with the quantity) (Issue 2)
10. Go to the BoM Structure and Cost of product 'TEST 2'
11. Increase the quantity of the product by 1
12. The BoM Cost of component 'TEST 1' only counts the subcontractor
price once (it should be the sum of its components) (Issue 3)
Solution:
Scale the subcontractor product cost with the quantity, update the
BoM cost of a product with the subcontractor price (in `_get_bom`) and
scale the subcontractor price with the quantity (in `_get_price`)
opw-2844482
closesodoo/odoo#92095
X-original-commit: 4f3347c6925e10ec62a85bb01d7cdb65b1e13b15
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Bug fixed where when the MRP subcontracting module was installed the merging of MO's would not open the MO form view.
Correctly displays the breadcrumbs as well.
Task: 2799674
Community PR: https://github.com/odoo/odoo/pull/88801
Part-of: odoo/odoo#88801
Usecase to reproduce:
- Install mrp_subcontracting
- Create a user with inventory access but not mrp access
- Validate a receipt for a product
Current behavior:
Access error on `mrp.production`
Expected behavior:
The receipt and the linked subcontracting order are validated
The stock user only receipt the products from the subcontractor so
he doesn't need to know the `mrp.production` behind that's why he
doesn't need access right. However he should be able to validate the
transfer since he receipts the goods. And it should update the quantity
on the subcontractor side by validating the subcontract order, so
we pick the sudo solution.
closesodoo/odoo#90301
X-original-commit: f1660b2254460abe10ce1d0a1fa7639d5c3e2b33
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Adapt db775ffd308638a390be52eba3ca11c9c2d1602d to subcontracting flow,
to avoid performance issues when receiving a large amount of SNs
closesodoo/odoo#85603
Task: 2777451
Signed-off-by: Arnold Moyaux <arm@odoo.com>
This task will:
- Clean the code (e.g. the production's moves are now created directly)
- Have the same behavior when creating object in the UI or directly in
backend
It's mainly on the `mrp.production` object and most of the computed
stored field are used as default value or act like an onchange on draft
production. Once the production order is validated, it's only modify
by direct write
Task-2709753
closesodoo/odoo#83576
Related: odoo/enterprise#24405
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Since bcf665a291, this helper has moved.
closesodoo/odoo#88559
X-original-commit: 2ac6357073d80fb07c7bd71cfd472d26ea1e5d83
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When adding a landed cost and selecting Manufacturing Order, the name of the receipt of the subcontracted products is now shown as well as the MO name for subcontracting orders.
Task: 2667152
Community PR: https://github.com/odoo/odoo/pull/88199closesodoo/odoo#88199
Signed-off-by: Arnold Moyaux <arm@odoo.com>
If a warehouse is set to a route like default 3-steps, updating the MO's
quantity to produce won't update the outgoing picking from
post-production to stock.
Since the quantity is now changed in the following pickings, no need to
put a warning in those pickings for the quantity change as their moves
quantity were automatically updated.
Task-2797359
closesodoo/odoo#86572
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Touati Djamel (otd)