Steps to reproduce:
- Create a manufactured product P with AVCO valuation
- On the bom of the previous product add a component C with unit cost 5$
- Manufacture product P (Unit cost correct so far 5$)
- Change component cost to 0 and manufacture again
- Unit cost of P is still 5$ were it should be 2.5$
Bug:
since the move unit price is 0 the standard price of the product P is
used insted for the valuation of the newly created qty
Fix:
force unit price to 0 in the case of manufacturing
opw-3374462
closesodoo/odoo#132047
X-original-commit: f6c2b5368e3abdc292e66dc04efc4031eb12f742
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@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>
This issue occurs when the user has not provided production account and is
trying to produce the manufacturing order.
steps to produce:
- Install `mrp_production`, `account_accountant`.
- From Settings > Users > Manage Users select a user (eg: Mitchell Admin) and
under `Technical` select `Stock Accounting Automatic group`.
- Inventry > Configuration > Products > Product Categories open a category and
change it's `Inventry Valuation` (property_valuation) to Automated.
- Through Accounting > Configuaration > Settings >
Stock Valuation check `Automatic Accounting` and remove Production Account and
save it. (You will see that production account got removed from the product
category).
- Now create a manufacturing order by Manufacturing > Operations > Manufacturing
Orders
- While creating manufacturing order select the product which comes under
product category you have modified, then confirm the
manufacturing order.
- Once it is confirmed click on `Produce All`.
video: https://encr.pw/09a2c
Error: `AttributeError: 'bool' object has no attribute 'id'`
Through our commit if the user does not specify a `Production Account` then the
user will face the UserError. The error is specified in
`_get_accounting_data_for_valuation` function while checking for `account_src`
or `account_dest`.
sentry-4271608065
closesodoo/odoo#128594
X-original-commit: 9265e785dedd8943296573fc6e5218925a33c522
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
- Component: "C1", cost: $100
- Create a Manufacturing Order to produce 1 unit of "P1":
- Set any analytic account
- Confirm and validate the MO
- An analytic account line is created for $100 of C1.
- Change the quantity of the component to 0.
- Try to save
Problem:
A traceback is triggered, because the `amount` and `unit_amount`
variables are used without assignment.
Solution:
Assign “0” value to both variable in the beginning of the function,
therefore the analytic account line will be deleted.
opw-3257240
closesodoo/odoo#128495
X-original-commit: 513e3dea2c838bb6f805c567069ea39406c6634e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce
- Create Manufacturing Orders and confirm it.
- Validate the done quantities.
- Click on valuation button. It will raise trackback
Error caused by commit: a080337closesodoo/odoo#124956
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce the bug:
- Install mrp_plm
- Create a BoM with an analytic account
- Create an ECO
- Start the revision
Problem:
The new BoM version doesn't have the analytic account from the original
one.
opw-3329901
closesodoo/odoo#125111
X-original-commit: 0210980037ccf843d73033d2a240369112899ff1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce:
* Create an analytic account
* Create MO with Analytic Account
* Create WO on MO
* Create Time Tracking on WO
* Delete the WO
Bug:
The analytic line related to the work duration remains on the Account
Fix:
Remove the lines when the WorkOrder is deleted
opw-3174736
closesodoo/odoo#124014
X-original-commit: 59ebf21d126d9d5c93e97e6b404b23270050aa6f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Upon changing/removing/adding the analytic account on a manufacturing order, only the analytic lines due to the raw material moves are updated, but not the ones for workcenter costs.
To reproduce:
- Create an MO with a workorder on a workcenter which has an operating cost set
- Complete time on this workorder to generate the [WC] AALs on this MO
- Change the analytic account on the MO (or delete it)
Bug: The [WC] AALs never get correctly updated.
This fix builds on https://github.com/odoo/odoo/pull/79614 to correct this behaviour and also take into account changes for the workcenter cost AALs when the analytic_account of a manufacturing order is changed.
Community PR: https://github.com/odoo/odoo/pull/117308closesodoo/odoo#122396
Task: 3252742
X-original-commit: 35e3af77051d1dfdf54600b607acfb593aa49e34
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Claeys Pieter (clpi) <clpi@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit changes the process flow of stock pickings. A new picking will
always be created in immediate transfer mode and 'ready' state. From
their, it can be validated directly or 'reset to draft'. This second action
switch the immediate mode to planned mode and reset the state as draft.
From their the classical workflow is processed
confirm -> (assigned ->) validated
Task: 3256447
Part-of: odoo/odoo#117513
Currently, when a specific capacity is defined for a product in a
workcenter, if a setup / cleanup time is given, it will be added to the
existing setup / cleanup time of the workcenter.
What we want instead is to be able to fully define what the
setup/cleanup time is for this specific product. So the given times in
the specific capacity override the times defined in the workcenter for
that specific product.
To help with that, we set the workcenter's setup/cleanup time as a
default for their related specific capacities, since if not changed,
they will follow the workcenter times.
Updated the tests so their specified capacities match the new behaviour.
closesodoo/odoo#119212
Related: odoo/upgrade#4576
Signed-off-by: Tiffany Chang <tic@odoo.com>
Related enterprise PR: odoo/enterprise#39669
Steps to reproduce:
Install mrp_workorder
Create Product P1, Workcenter W1
Edit W1 > Specific capacities > Add line: Product = P1, Start time = 5, End time = 5
Create BoM > Product: P1, Operations tab > Add line: Workcenter = WC1, Default duration = 60:00 min > Save
Click on overview stat button
Issue:
The created operation has expected time of 60:00, instead of 70:00. The workcenter start and stop times are considered in this calculation, so the workcenter capacities should be considered too.
Solution:
Use `_get_expected_duration` to compute the expected duration.
opw-3229485
closesodoo/odoo#121060
X-original-commit: 7b5a30fb3e51434154050052ec39ed299c6094d3
Related: odoo/enterprise#40905
Signed-off-by: Tiffany Chang <tic@odoo.com>
account
1. We introduced a new Production Cost account that can be set on
locations with Production type. When products move into/out of a
production location. The account entry will be post on this account
instead of previous Stock in/out account.
2. On the accounting setting page, we can now set the default values for
all stock accounts. Users can also disable automatically accounting for
stock there.
Task-3046333
closesodoo/odoo#113973
Related: odoo/enterprise#37653
Signed-off-by: Tiffany Chang <tic@odoo.com>
When a product category valuation is set to `real_time`, we use the
stock accounts. However, in the code, to know which account we
should use, we do: "use stock accounts if defined, else use basic
ones" (the best should be "use stock accounts if `real_time`" but
this refactoring task will be done in master). So, here, we need to
ensure that stock accounts are not defined when the valuation is manual.
This is the case when installing `stock_account` module: the
valuations will be set to manual, so we need to force the stock
accounts to `False`. Same when creating a new company, we also need to
ensure that the stock accounts are not defined. This explains the
changes in `_post_load_data`
About changes in `_check_valuation_accouts`, the explanation is in
the method body: the defined values directly depends on the value of
`property_valuation`
Note about test modification: for the tests in `stock_landed_costs`
module, we set the categ to auto so the stock accounts are defined.
Otherwise, when validating the landed costs, it will lead to an error
https://github.com/odoo/odoo/blob/9cd316f038dc95051814ede9474f8f15f7d165df/addons/stock_landed_costs/models/stock_landed_cost.py#L396-L397
OPW-2746384
X-original-commit: 2780c37cfdb8560ac7c725fd27f4fe272f1d3072
Part-of: odoo/odoo#119564
Current behaviour:
Cannot add a Work Order to a Manufacturing Order
if the analytic account linked to the MO doesn't
have an associated company.
Expected behaviour:
Should be able to add a WO to a MO even
if the linked analytic account doesn't have
an associated company.
Steps to reproduce:
1. Activate analytic accounts
2. Activate work orders
3. Create an analytic account without company associated
4. Create a Manufacturing Order
5. In miscellaneous, link the analytic account
6. Try to add a WO line
7. Error log
Reason for the problem:
When trying to add a WO line, if the MO has been linked
to an analytic account, it checks for the currency in
the company in the analytic account, which was not
existent, since the company didn't exist.
Fix:
When trying to access currency, if the company in the analytic
account doesn't exist, it defaults to the company in the WO.
opw-3210708
closesodoo/odoo#117708
X-original-commit: f0d8f5e82e62e0bcfc05e25dac2504f8f07537f4
Signed-off-by: Demany Antoine (ande) <ande@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Add the group 'mrp.group_mrp_routings' on the main user to make field
'workorder_ids' visible in the form view of 'mrp.production'. Many
tests use that view, and require the subviews of that field to be
present in order to create records.
closesodoo/odoo#116779
Related: odoo/enterprise#38858
Related: odoo/documentation#3968
Signed-off-by: Raphael Collet <rco@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Since starting a workorder and marking it as done replaces the
planned dates with the actual ones,
there is no need to keep dates which will always end up being the same.
task: 3108291
see odoo/enterprise#36102
see odoo/upgrade#4247closesodoo/odoo#110550
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
If the stock move (consumed_moves) has more than 1 stock valuation
layers (stock_valuation_layer_ids), it will cause an expected singleton
error.
closesodoo/odoo#113764
X-original-commit: 2efe6bea6887ebd6528eba084eb3eaee8af7ab9e
Signed-off-by: Tiffany Chang <tic@odoo.com>
UI improvements for the form of product.product model.
task-3043184
closesodoo/odoo#111052
X-original-commit: d8bc64e6cf04291370e577abe8c58303ae4a9741
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
before this commit, the action name was not getting translated to user language.
after this commit, the action name will get translated to user language.
closesodoo/odoo#110856
X-original-commit: 6758cde0358359d76642b0cbea4c208eac57dd92
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- Go to product category → set the inventory valuation to
“Automated”
- Create a BoM:
- Add a component with the cost set to 10$
- Add an analytic account
- Create a MO to produce one unit of “P1”:
- Confirm the MO:
- an analytic account line is created with the amount of $10
- Mark as done the MO:
- The amount is updated to $0
Problem:
In the case where the inventory valuation is set to “automated” we use
the analytical distribution since this commit:
https://github.com/odoo/odoo/blob/7e3403068fc3fbc40182b3cfeb80e97a9300e8ff/addons/account/models/account_move_line.py#L2326
but in the case of MO it shouldn't use it
Solution:
If we are in MO, ignore the type of inventory valuation
opw-3081877
opw-3086626
closesodoo/odoo#110478
X-original-commit: af7be17b71fc72d15149c4baabadeacdcf77cc99
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Adapt tests for other moudules to use
ENT PR odoo/enterprise#33399
X-original-commit: 88cad50cac8130e1ff66a21ab63d53b41488a74a
Part-of: odoo/odoo#106007
Adapt community to make it possible to add employee cost when calculate
bom cost.
closesodoo/odoo#105645
X-original-commit: a239802249b2af2cc3fc2b3bb9fdfd0a408d887a
Related: odoo/enterprise#33898
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
Steps to reproduce:
- set time effeciency of a workcenter to less than 100
- on a product page with a BoM using that workcenter
- for the cost click on compute price from BoM
Bug:
workcenter effeciency is not taken into consideration
Fix:
included time_effeciency in computing the expected duration
addepted tests to take it into consideration aswell
opw-3033672
closesodoo/odoo#104566
X-original-commit: 1dcd9dbef0a5e6d9bd2c5e52a42cff9aec98f1d0
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
With the change to 'always edit' on form views by default, several
'oe_read_only' fields had to be modified to play nice with the fact
that in most cases, there is no read_only mode
closesodoo/odoo#101188
X-original-commit: 868992abeeda983768323e1126b5643eff8fdb33
Related: odoo/enterprise#31810
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Steps to reproduce the bug:
- Create a storable product “B1”:
- Costing Method: average
- With BOM:
- BOM Type: Kit
- Components:
- 3 units of “C1” (cost c1 = $2)
- Go to the “B1” product form:
- Click on “Compute Price from BOM”
- Cost = 3 * $2 = $6
- Create a storable product A1:
- Costing Method: average
- BOM
- BOM Type: Kit
- Components:
- 2 units of B1
- Go to the “A1” product form:
- Click on “Compute Price from BOM”
So: 1 unit of A1 → 2 units of B1 → 3 units of C1
- Cost = (2 * 3 * $2) = $12
- Create a SO:
- Add 1 unit of “A1”
- save
- cost(`purchase_price`) = $12
- Confirm the SO
- The cost is recomputed and becomes = $6
Problem:
When the SO is created and the product “A1” is added, the cost is
retrieved from the product: https://github.com/odoo/odoo/blob/14.0/addons/sale_margin/models/sale_order.py#L27
But when the SO is confirmed, a picking is created, therefore the
cost is recomputed: https://github.com/odoo/odoo/blob/14.0/addons/sale_stock_margin/models/sale_order_line.py#L18
So The `_compute_average_price` function is called, in which a loop is
made for each move related to the `sale.order.line`, but the
`bom_line.product_qty` is used for each component (in this case the qty
necessary of the product `C1 ` to make a single unit of `B1`, but this
is not multiplied by the number of units needed to be used in the
parent's bom_line
opw-2971248
closesodoo/odoo#101012
X-original-commit: 9ec7aa9b89bc929af15473d0cc29084fd831cf94
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
*: base, mrp_account, product, mail, website_blog, website_event,
website_forum
This commit improves the button that allows to go to the backend view of
an object when you are on its corresponding page on the website. The
button is more visible and the user can see which object he is going to
edit. Note that this commit also:
- Changes the access key to translate a website page to ALT + T.
- Adds a new access key to edit an object in backend with ALT + E.
- Removes the possibility to duplicate a blog post (but this feature
will be reintroduced later for all models, generically) **.
**: Note that the duplication of blog posts actually had a mistake:
The controller to create a new blog post has been added with [1] where
it has been decided to not be a follower of the blog posts at their
creation. A new controller has been added by [2] to be able to duplicate
a blog post, to be consistent with [1], here also the user does not
become a follower of the new blog post (the copy). So far, so good.
Finally, [3] has changed the blog post creation controller so that the
user who creates the blog post is a follower of the new blog post.
Unfortunately the same change was not made for the duplicate controller,
which is a mistake. There is no reason to be a follower of the newly
created blog posts when you go through the add blog post controller but
not when you go through the duplication controller. The behaviors should
be consistent and there is no reason for there to be a difference.
[1]: https://github.com/odoo/odoo/commit/4c3b516a7b988d758a67ff19242e8ed0837d756c
[2]: https://github.com/odoo/odoo/commit/fe40538aff2b65f7719840c8e2d6e51e858f560f
[3]: https://github.com/odoo/odoo/commit/4bf9dc4078a5ca413539a6fd16400fd5aad46907
task-2889929
closesodoo/odoo#97353
Related: odoo/enterprise#30075
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
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
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>
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@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>
Gorash