These changes are made as a result of simplifying attrs and 'states' in
views.
Before applying the migration script, it is necessary to fix some views.
These views are erroneous and either work by chance or are simply
untested. We have for example wrong domains, elements used by modifiers
but not present in the view, obsolete domain operators, inherit views
not targeting the right views, xpaths using attributes as target, the
use of %(...)s in views, false attribute value types in python.
Part-of: odoo/odoo#104741
To reproduce:
1. Create a Sales Order for a product whose product category is set to
FIFO and automated. Use route "dropship".
2. Confirm the PO created.
3. Deliver the products (DS transfer)
5. Return, for example, 1 unit of product
6. Return the return
This is a continuation of commit f9a1c1d7bb8234eb96c48dddae9930a419bfb696
If the origin of the move is a dropshipped_returned, then the error describe in the mentioned commit will still happen.
opw-3283436
closesodoo/odoo#127403
X-original-commit: b7a91e3682aad7ecc1a4a8a42b2d6368573ba906
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: David Fesquet (dafr) <dafr@odoo.com>
To reproduce:
1- Activate dropshipping from settings
2- Create lot tracked product and enable dropship route
3- Add a vendor in product purchase tab
4- Create a SO with the product and confirm
5- Go to generated PO and confirm
6- Go to generated dropship transfer linked to SO /PO
7- Enter a lot name for the product move line validate
8- Go to 'Inventory>Products>Lots/Serial Numbers'
9- Expand the dropshipped product, find the serial number used in dropship
10- Show the 'Transfer To' field if not visible, you will find it empty
Expected:
The 'Transfer To' field should have the last partner the serial was delivered to
in this case the customer in the SO
This commit fixes the issue and adds a test (also imporves the test class)
opw-3225342
closesodoo/odoo#125842
X-original-commit: 27356b1046ab534fec9b5d5fa3380cb7a5eafed5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce:
1. Create a Sales Order for a product whose product category is set to
FIFO and automated. Use route "dropship".
2. Confirm the PO created.
3. Deliver the products (DS transfer)
4. Create the customer invoice
5. Return, for example, 1 unit of product
6. Add a credit note to the invoice for that 1 unit returned (reset to
draft then change qty and post)
Issues:
The value on the valuation layers of the returned picking is 0, posted
entries for COGS and stock interim (delivered) account for credit note
is also 0.
Since #85751, When create valuation layer for return, we take all svls
of origin_returned_move_id into account to calculate the price unit.
However, then dropshiping, 2 svls are created for the original move, and
the sum of them is 0 since there is no impact of the stock when
dropshiping. So when return, the price unit will be calculated as 0.
To fix, when calculate price unit for return of dropshiping, we only
take non-negative svls into account. Note that we use non-negative ones
instead of positive ones because when subcontract dropshiping,
additional negative svls will be added for the cost of the components.
opw-3283436
closesodoo/odoo#124856
X-original-commit: 1c6c163f72301cab29c2f26021bb1ae6fb20dc7f
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@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
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>
Stock moves don't have a `partner_id` if they are created before setting
the picking's `partner_id`
Steps to reproduce (from v15):
1. Create a new transfer with operation type 'Delivery Orders'
2. Add a move, then a delivery address and save
3. Mark as todo and validate
4. Print the delivery slip
5. The warehouse address is printed but it should be the delivery
address
Solution:
Replace `onchange_partner_id` of `stock.picking` by a compute method in
`stock.move`. It assigns the partner_id of the `stock.move` to its
picking's partner_id if the move is part of the picking's
`move_ids_without_package` (in purchase_stock, also check that it is not
a dropshipping)
Problem:
When creating a picking, its moves' `partner_id` is only set if the
picking's `partner_id` was already set in the form
opw-3091139
closesodoo/odoo#107625
Signed-off-by: Tiffany Chang <tic@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>
Divide "Delivery"/"Incoming Shipment" smart button of "Sale"/"Purchase"
order form between normal "Delivery"/"Incoming Shipment" and a
"dropship" picking.
Also clean a little bit technically
task-2486811
Part-of: odoo/odoo#75041
For customer invoices:
* do not set default date because if you prepare an invoice (and it gets
a default date), then validate it the next day, the date will be wrong
* set the date when posting if it wasn't set, because why not?
For vendor bills:
* do not set default date because you rarely encode a bill at the bill
date. Forcing the user to enter it reduces risks of user error
(duplicated vendor bill)
* do not set it when posting, same reason.
opw-2492862
Related #68368Closes#68367closesodoo/odoo#69639
X-original-commit: 41041d8016d11f017d92d28f32ab2cf42f1349a9
Related: odoo/enterprise#17866
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Add a warning to explain that create a second
warehouse will activate the multi-location automatically.
task-2439909
X-original-commit: 4964a9482b8b195f5b629ea5c91f7d7bfcce2163
Allow to add serial numbers as tags on the move in production order and
stock picking. The purpose is to earn time for database with
only tracking installed.
Also when only create_lots is checked on picking type. New lots
could select existing lot and an onchange trigger a warning if
it's used.
closesodoo/odoo#55883
Task: 2280985
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- The deadline of MO generated via procurements is calculated differently.
Now, it doesn't take anymore in account the manufacturing_lead
of the company (Security Lead Time of MO). The computation of planned date remains unchanged.
- The date_expected fields was duplicated with the date fields
except when the move was done. Merge both fields.
The only information lost is: we can't know what was the
scheduled date before processing move (`state` == done).
Indeed, the date becomes the actual move processing datetime.
- The `date` in `stock.picking` field contained the time of
(purchase) order `date_order` (`purchase.order`).
This field is was wrongly used in the kanban view where we
expected to see date_planned instead. Also, the `_order` used
this date instead of date_planned too.
- The `delay_alert` is activate independently of stock rules.
Then it is now activate in all case.
- Remove the auto-reschedulting process of stock move via
the stock rule (`propagate_date` and `propagate_date_minimum_delta`).
Replace it by a automatic deadline date (`date_deadline`) propagation.
The deadline is the promise done to/by vendor/client (SO/PO)
then it is a readonly fields on picking/move and MO.
- Now the Scheduled date (`date`) of stock move is never propagate
and it is only related to the Scheduled date of
related document (MO or picking).
- Now when a move is created from procurement (sale),
`date_planned` = `date_deadline` - `security_lead`.
- The `delivery_date` of sale is no editable after confirmation
and propagate as the deadline to related stock move linked to order_line
- Adapt filter and decoration of MO and picking.
- Because we are the client in case of purchase (PO), the promise of vendor
can be not respected. Then we add the lead security to the deadline
(inverse the sale order logic) of PO picking (promise reciept date
+ security lead) to match with the replenishment.
task-2246665
Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )
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: 2301180
This restricts the attributes of a BaseModel instance to `env`, `_ids`
and `_prefetch_ids`. This way, one can only assign fields on a record;
other assignments are programming errors.
This also reduces the memory footprint of records from 168 to 64 bytes
(-62%), and makes their instanciation faster.
closesodoo/odoo#51075
Related: odoo/enterprise#10529
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
followup of rev [0]
If these wizards are called on multiple pickings, display the list of
the pickings that could be impacted and allow to select which one should
be impacted.
We also adapt the sanity checks at the start of `button_validte` in
order to specify the concerned pickings if needed. We do not enable the
multi behavior for batch at the moment, so it's only enabled for the
validate multi in the list view.
[0] 6ab4b0d496
task-2069646
closesodoo/odoo#41497
X-original-commit: ff276c6484b138982f185ec9c832f2dbf25baaef
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Overwrite the method ``write`` of the model ``product.product``.
When we write on ``standard_price``, if
- the context key ``disable_auto_svl`` is not set
- the ``cost_method`` is not "fifo"
We automatically compute ``stock.valuation.layer``
(before we needed to manually call ``_change_standard_price``)
Task #2031422closesodoo/odoo#41265
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
So we have to adapt
- the sanity checks
- the immediate/backorder wizards
- split the call to _action_done with and without backorder
This is a preliminary work to remove all the override in
stock_picking_batch and to allow choosing the pickings to immediate or
backorder directly in the wizards.
Before this commit, both wizards were calling _action_done and one
another. We make them go back through `button_validate` so that it is
more sane to handle and allow future extensions to add pre-action done
wizards.
Also the first part of button_validate is some sanity check. We adapt
them to be multi (inside of a loop over self) without any other
changes.
Now the wizard can work on the records (immediate: write the done
quantities) or work with the context (backorder: picking ids to not
backorder in the context).
Also we adapt the stock sms weird wizard (a confirmation wizard but the
feature is auto installed? wth). Now there it isn't manually called in
the middle of button_validate but it uses the pre_action_done_hook.
task-2069646
`action_done`on pickings should be a private method,
and called only trough the picking validation process.
task-1938108
closesodoo/odoo#39174
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- This commit moves the Payment Term "End of Following Month" from
demo data to data and adds two new Payment Terms: "21 Days" and
"30% Now, Balance 60 Days".
It allows the customer to define less Payment Terms
task-2032586
Steps to reproduce the bug:
- Create a quotation and a SO line SOL with one product and route "Dropship"
- Confirm the SO and a PO is created
- Validate PO and process the dropship picking
- Add 4 units to the SO line SOL
Bug:
A new PO was created but the related picking was type "Receipts" instead of "Dropship"
opw:2034398
closesodoo/odoo#35323
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
This commit merges the following models
* account.invoice and account.move
* account.invoice.line and account.move.line
* account.voucher and account.move
* account.voucher.line and account.move.line
It was the opportunity for a big cleanup of the code, so it also restructures the whole account module, its different models/fields, the tests etc. for a better world and a better code readability.
==== Rationale ====
The rationale of this huge change is that we want journal entries / invoices to be easily edited, and changes reflected in the other model. It's a HUGE feature and very strategic for the fiduciary companies. For example, changing the account of a journal entry needs to be automatically reflected on the related invoice.
The same reasoning applies to sale/purchase vouchers.
==== Changes made in features =====
When creating an invoice, you are now creating a journal entry directly.
--> The object account.invoice no longer exists.
In the same fashion when creating an invoice line, you're now adding journal items directly in the journal entry representing the invoice. If this invoice line has some tax, it may create additional journal items as well.
--> The models account.invoice.line & account.invoice.tax no longer exist
Identically, when creating a sale/purchase receipt with its lines, you are now creating a journal entry directly and there's no more usability difference between encoding a receipt or an invoice.
--> The object account.voucher no longer exists.
--> The object account.voucher.line no longer exists.
--> The whole account_voucher module no longer exists.
Positive side-effects coming from these changes are
* draft invoices/bills/sale or purchase receipts now create a draft accounting entry. Validate these objects now simply post its journal entry. That means that draft invoices/bills/sale or purchase receipt can straightforwardly be included in reporting or budgets.
* opening a journal entry in form view will now always open the correct view: if it's a sale/purchase journal entry we will have a customer invoice/vendor bill view or a sale/purchase receipt view, whatever the menu we're coming from.
* code & business logic simplification. It is also condensed in a single place instead of being partially duplicated on invoices, vouchers and journal entries.
There should be no feature loss, except the one allowing to group multiple journal items together based on the same product during the invoice validation.
==== Changes made in models =====
* account.invoice: model removed. Instead, now use account.move with following mapping
field (account.invoice) field (account.move)
----------------------- --------------------
name invoice_payment_ref
number name
reference ref
comment narration
user_id invoice_user_id
amount_ total_company_signed amount_total_signed
residual amount_residual
state state + invoice_payment_state /!\ selection changed
date_invoice invoice_date
date_due invoice_date_due
sent invoice_sent
origin invoice_origin
payment_term_id invoice_payment_term_id
partner_bank_id invoice_partner_bank_id
incoterm_id invoice_incoterm_id
vendor_bill_id invoice_vendor_bill_id
source_email invoice_source_email
vendor_display_name invoice_vendor_display_name
invoice_icon invoice_vendor_icon
cash_rounding_id invoice_cash_rounding_id
sequence_number_next invoice_sequence_number_next
sequence_number_next_prefix invoice_sequence_number_next_prefix
'invoices' subset of account.move can be accessed by using the selection field 'type' or one of the many helpers like is_invoice()
* account.move: now has a valid state 'cancel' that has to be excluded from all business logic
* account.move: field 'amount' renamed into 'amount_total'
* account.move: field 'reverse_entry_id' renamed into 'reversed_entry_id'
* account.move.line: now has a field 'display_type' that has to be excluded from all business logic, in order to support invoice layouting
* account.invoice.line: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.line) field (account.move.line)
---------------------------- -------------------------
invoice_id move_id
uom_id product_uom_id
invoice_line_tax_ids tax_ids
account_analytic_id analytic_account_id
'invoice lines' subset of all account.move.line from a journal entry can be accessed by using the boolean field 'exclude_from_invoice_tab'
* account.invoice.tax: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.tax) field (account.move.line)
--------------------------- -------------------------
invoice_id move_id
account_analytic_id analytic_account_id
amount price_unit
base tax_base_amount
'tax lines' subset of all account.move.line from a journal entry can be accessed by using the relational field 'tax_line_id'
* account.invoice.confirm: model removed. Instead, now use the 'post()' function of account.move
* account.invoice.refund: model removed. Instead, now use account.move.reversal to reverse the entries with the same options as we had for invoices
* account.voucher: model removed. Instead, now use account.move of type in ['out_receipt', 'in_receipt]
* account.voucher.line: model removed. Instead, now use account.move.line
==== Changes made in functions ====
* on account.move, method _run_post_draft_to_post() renamed into _autopost_draft_entries()
* on account.move, method action_account_invoice_payment() renamed into action_invoice_register_payment()
* on account.move, method action_invoice_reconcile_to_check() renamed into action_open_matching_suspense_moves()
* on account.move, method _get_domain_edition_mode_available() renamed into _get_domain_matching_supsense_moves()
* on account.move, method _get_intrastat_country_id() renamed into _get_invoice_intrastat_country_id()
* on account.move.line, method _get_domain_for_edition_mode() renamed into _get_suspense_moves_domain()
* in account.bank.statement, contextual key 'edition_mode' renamed into 'suspense_moves_mode'
Was task 1917430
The tests of this module showed multiple issues with the anglos axon
accounting entries creation so we fix them by getting the value on the
valuation layer and not directly on the stock moves.
About the changes in
test_crossdock.py
> To change a standard price, we need to open the wizard
test_lifo_price.py
> To change a standard price, we need to open the wizard + read the
valuation on the layers.
test_stockvaluation.py
> Now that we create a layer in and out for a dropshipped move, the
accounting entries are similar to an in followed by an out, thus we need
to increment the number of generated AML. Not that the balance of the
accounts stay the same.
There's a slight change in fifo_perpetual_anglosaxon_ordered though.
Let's say for a start that this config doesn't make sense. Ordered means
we don't read the value on the stock move to create the accounting
entries but only the standard price. We had to change 8 by 10 in this
test because, before this task, the standard price was updated when
running fifo, even in dropshipped. As the PO line was valued at 8, the
anglos axon in stock out was at 8 because the standard price was changed
to 8 after the delivery.
task-1875873
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
The invoice status of a sale order line depends on its product's
`invoice_policy` and `qty_delivered` fields.
`invoice_policy` is also used to compute the "anglo saxon price
unit" which is, once multipled by the invoiced quantity, the
amount we will take from the stock delivered account to put into
the cost of goods sold account if we are in anglo saxon mode.
The default `invoice_policy` is set as "ordered". In this mode and in
anglosaxon, the "anglo saxon price unit" will always be standard price
of the product, resulting in unbalanced accounts.
In this task, we chose to use the real delivered price if something was
delivered, whatever the value of `invoice_policy`. We fallback on the
standard price if nothing or not enough things were delivered.
test_dropship_fifo_perpetual_anglosaxon_ordered and
test_dropship_fifo_perpetual_anglosaxon_delivered do have the same
result now.
task-2003196
closesodoo/odoo#34644
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This commit merges the following models
* account.invoice and account.move
* account.invoice.line and account.move.line
* account.voucher and account.move
* account.voucher.line and account.move.line
It was the opportunity for a big cleanup of the code, so it also restructures the whole account module, its different models/fields, the tests etc. for a better world and a better code readability.
==== Rationale ====
The rationale of this huge change is that we want journal entries / invoices to be easily edited, and changes reflected in the other model. It's a HUGE feature and very strategic for the fiduciary companies. For example, changing the account of a journal entry needs to be automatically reflected on the related invoice.
The same reasoning applies to sale/purchase vouchers.
==== Changes made in features =====
When creating an invoice, you are now creating a journal entry directly.
--> The object account.invoice no longer exists.
In the same fashion when creating an invoice line, you're now adding journal items directly in the journal entry representing the invoice. If this invoice line has some tax, it may create additional journal items as well.
--> The models account.invoice.line & account.invoice.tax no longer exist
Identically, when creating a sale/purchase receipt with its lines, you are now creating a journal entry directly and there's no more usability difference between encoding a receipt or an invoice.
--> The object account.voucher no longer exists.
--> The object account.voucher.line no longer exists.
--> The whole account_voucher module no longer exists.
Positive side-effects coming from these changes are
* draft invoices/bills/sale or purchase receipts now create a draft accounting entry. Validate these objects now simply post its journal entry. That means that draft invoices/bills/sale or purchase receipt can straightforwardly be included in reporting or budgets.
* opening a journal entry in form view will now always open the correct view: if it's a sale/purchase journal entry we will have a customer invoice/vendor bill view or a sale/purchase receipt view, whatever the menu we're coming from.
* code & business logic simplification. It is also condensed in a single place instead of being partially duplicated on invoices, vouchers and journal entries.
There should be no feature loss, except the one allowing to group multiple journal items together based on the same product during the invoice validation.
==== Changes made in models =====
* account.invoice: model removed. Instead, now use account.move with following mapping
field (account.invoice) field (account.move)
----------------------- --------------------
name invoice_payment_ref
number name
reference ref
comment narration
user_id invoice_user_id
amount_ total_company_signed amount_total_signed
residual amount_residual
state state + invoice_payment_state /!\ selection changed
date_invoice invoice_date
date_due invoice_date_due
sent invoice_sent
origin invoice_origin
payment_term_id invoice_payment_term_id
partner_bank_id invoice_partner_bank_id
incoterm_id invoice_incoterm_id
vendor_bill_id invoice_vendor_bill_id
source_email invoice_source_email
vendor_display_name invoice_vendor_display_name
invoice_icon invoice_vendor_icon
cash_rounding_id invoice_cash_rounding_id
sequence_number_next invoice_sequence_number_next
sequence_number_next_prefix invoice_sequence_number_next_prefix
'invoices' subset of account.move can be accessed by using the selection field 'type' or one of the many helpers like is_invoice()
* account.move: now has a valid state 'cancel' that has to be excluded from all business logic
* account.move: field 'amount' renamed into 'amount_total'
* account.move: field 'reverse_entry_id' renamed into 'reversed_entry_id'
* account.move.line: now has a field 'display_type' that has to be excluded from all business logic, in order to support invoice layouting
* account.invoice.line: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.line) field (account.move.line)
---------------------------- -------------------------
invoice_id move_id
uom_id product_uom_id
invoice_line_tax_ids tax_ids
account_analytic_id analytic_account_id
'invoice lines' subset of all account.move.line from a journal entry can be accessed by using the boolean field 'exclude_from_invoice_tab'
* account.invoice.tax: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.tax) field (account.move.line)
--------------------------- -------------------------
invoice_id move_id
account_analytic_id analytic_account_id
amount price_unit
base tax_base_amount
'tax lines' subset of all account.move.line from a journal entry can be accessed by using the relational field 'tax_line_id'
* account.invoice.confirm: model removed. Instead, now use the 'post()' function of account.move
* account.invoice.refund: model removed. Instead, now use account.move.reversal to reverse the entries with the same options as we had for invoices
* account.voucher: model removed. Instead, now use account.move of type in ['out_receipt', 'in_receipt]
* account.voucher.line: model removed. Instead, now use account.move.line
==== Changes made in functions ====
* on account.move, method _run_post_draft_to_post() renamed into _autopost_draft_entries()
* on account.move, method action_account_invoice_payment() renamed into action_invoice_register_payment()
* on account.move, method action_invoice_reconcile_to_check() renamed into action_open_matching_suspense_moves()
* on account.move, method _get_domain_edition_mode_available() renamed into _get_domain_matching_supsense_moves()
* on account.move, method _get_intrastat_country_id() renamed into _get_invoice_intrastat_country_id()
* on account.move.line, method _get_domain_for_edition_mode() renamed into _get_suspense_moves_domain()
* in account.bank.statement, contextual key 'edition_mode' renamed into 'suspense_moves_mode'
Was task 1917430
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Fine tuning of commit b9e3c153, for the same use-case.
The route may not be passed in values, in which case the bug is still present.
There are two ways to go around that.
We could add the stock.rule in values, which contains the route.
The solution we adopt here is to use the sale_line_id field on the purchase line
If it is present, it was added through _prepare_purchase_order_line,
and thus we want to keep track of the origin.
opw 1957701
closesodoo/odoo#32683
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Commit 52c89ade added a test in v11.
Commit 1e0a92c9 forward-ported that commit to v12, that already had a test.
As a result, the class TestDropship was defined twice.
It follows that the first test was not executed.
opw 1957701
closesodoo/odoo#32792
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Gorash