* = {account, sale, purchase, hr_expense}
When a plan is mandatory for SOL, POL or expenses, the flow should still be blocked when pressing the button, and not only when creating analytic lines.
We add the info in the context of the button, so automatic flows are still not blocked.
When the applicability rule requires a mandatory analytic distribution, raise an error upon :
- confirming PO,
- sending or confirming SO
- approving Expense Report by manager.
t-3040929
closesodoo/odoo#107166
X-original-commit: 8623a7850288828759db125b1054b0fed6b6b135
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce
==================
- Use a mobile phone / mobile view in devtools
- Go to Purchase > Purchase Orders
- Click on one item
-> A traceback occurs, the uom is missing
Cause of the issue
==================
The field is declared as
`<field name="product_uom" groups="uom.group_uom"/>`
The raw value is accessed with
`<t t-esc="record.product_uom.value"/>`
Solution
========
Add the missing group
opw-3033650
closesodoo/odoo#105487
X-original-commit: bc6c2d8d15e22f6af720db6a28e21739defede94
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
# Description
The absence of those fields can generate a log note spam & performance issue when updating an order line value.
# HOW TO REPRODUCE
- Create PO with 40+ order lines (50 recommend) (* SA to reproduce would be nice)
- Confirm PO (state needs to be "purchase")
- Update the Ordered Quantity of the first line.
- Save
=> PO Lines from page 2 and beyond have each created the following log message:
"The ordered quantity has been updated."
# Explanation
The purchase.order.line onchange will not save any update on 'price_total' because it is not on the onchangeSpec.
Then a purchase.order onchange is done, and this one does have 'order_line.price_total' on the onchangeSpec, forcing the onchange method to return the field 'order_line' (aka ALL the order lines) as updated.
When saving the changes, the JS framework, who does not have the data for the order_lines on the 2nd page, will not correctly filter the fields with real changes, and add the 'product_qty' field (and more) to the "write" call for every order_line not in the 1st page.
Then the write method, without checking if there is any real change on the product_qty, for each lines that has product_qty in the Write's values, will write in the log note and call a performance intensive method: _create_or_update_picking()
OPW-2982004
closesodoo/odoo#104549
X-original-commit: e99cdd6430bf85bcae8ec3b8febcf8e3719169a5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David <dafr@odoo.com>
The `analytic_distribution` field is a Json.
It was stored temporarily as a char.
Search is not available yet, so we do queries by hand when we need to search on keys.
Also added a constraint on account_analytic_distribution_model,
so we don't have models with accounts specific to a company when the model has no company or another company.
It would cause an issue when looking at the models from another company.
X-original-commit: 7064c95aa04e5138bb12ae97acfee04ebb67cc0e
Part-of: odoo/odoo#103097
Adapts the Purchase Order Line form to the new grid css system for
groups.
closesodoo/odoo#102760
X-original-commit: 91582733e413e28e9f26f16e7209f6d91ca546c4
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Add choices for the business domain on applicability rules, so rules are more precise
Also put 'general' as domain from the view when it's what should have been.
Make analytic field visible since owl migration (for sale and purchase)
closesodoo/odoo#102461
X-original-commit: c5867d5009a7fb448fff1be487b9e9c3e7945d4b
Related: odoo/enterprise#32421
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Avoids breaking the layout by hiding the label instead of fully removing
it from the DOM
Part of task-2985735
X-original-commit: 36eab7d034b52657bae988e5c35b0c429df2c05b
Part-of: odoo/odoo#102495
Steps to reproduce the bug:
- create a new product “p1”
- Create a purchase order with “P1” → confirm it
- Click on “Purchase history”
Problem:
No purchase order is displayed for this product, whereas we have a
confirmed PO.
Because the partner id is formatted as a string and added to the domain,
so when the `web_search_read` function is executed, it will return an
empty result because the id is supposed to be a number instead of a
string: https://github .com/odoo/odoo/blob/master/addons/web/models/models.py#L62
Solution:
The filter on the vendor can be removed because it's already added when
calling the action: https://github.com/odoo/odoo/blob/678bc958fafd5502a61ce54069b13160ad37d2d4/addons/purchase/models/purchase.py# L1240
opw-2976152
closesodoo/odoo#100892
X-original-commit: 9431adc5bfce525bd3a9ec4c3f7215f2ee312841
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>
This commit converts the purchase dashboard to owl component
and removes its legacy code.
closesodoo/odoo#97590
Taskid: 2920812
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The widget `account-tax-totals-field` needs the value of the
`currency_id` field, even when not in multi-currency mode.
The widget is used in `sale.order`, `account.move` and
`purchase.order`. The only place where the field
was not included when not in multi-currency mode
was the purchase.order.
A traceback was raised when attempting
to open the purchase order form when
not in multi-currency.
This is an oversight of odoo/odoo#95729closesodoo/odoo#98597
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
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>
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>
The new list and form views were merged recently [1], but they
weren't activated because they weren't 100% ready yet. This is now
the case. This commit adds those views to the view registry. As a
consequence, a lot of qunit tests and tours needed to be adapted,
mostly for selector changes.
We also add legacy list and form views to the view registry, with
keys 'legacy_list' and 'legacy_form'. This allows to force those
legacy views when necessary. For instance, we did it in views
using complex custom legacy x2many field widgets that haven't been
converted yet (we have a compatibility layer but it isn't complete
and doesn't support every advanced usecases).
[1] odoo/odoo#92475
Part-of: odoo/odoo#78221
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
SPECIFICATION
Various change for the partner view:
- Moved the activity widget to the bottom right of the kanban
- Moved the informations badge to the bottom right next to the
activity widget and made them clickable
- Change the address options order and add a small help below
- Change the 'Remove' button function from delete to remove from
the company and add a delete button to the right end.
- Correct some typo
- Add an 'Archived' ribbon to the kanban card
- Change various small things
LINKS
Task-2821356
closesodoo/odoo#89249
Related: odoo/enterprise#26442
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add a reception/delivery status on sale orders and purchase orders.
The idea is to have an indication in list view about the situation
of pickings linked to the SO/PO.
Inside the document itself, the quantity delivered decoration are
designed to indicate if everything is correctly deliver or if
it still something to do. (red if the delivery/receipt is late and
incomplete)
Task-2381757
closesodoo/odoo#63356
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Some html field are not in their ideal style.
As the style for html fields is now dependent of
where you are in the xml view ( in group or not),
we have to adapt some views and flags some fields
to ensure they have the correct look.
This change is only be a visual enhancement
and should not prevent the function of said html fields
even if the views are not updated.
task-2637488
# Conflicts:
# addons/mail/wizard/mail_compose_message_views.xml
# addons/website_slides/views/slide_channel_views.xml
# Conflicts:
# addons/sale/views/sale_views.xml
closesodoo/odoo#83792
Related: odoo/enterprise#23911
Signed-off-by: Antoine Guenet <age@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Since 6f182eeeab UoM should be created through the UoM category tab as the UoM form view is now unusable.
To ensure that this is the case, we remove menu link to the form view and update the other to lead to UoM category instead.
opw-2702953
closesodoo/odoo#81221
X-original-commit: 58a3954d606d48b2a4cf678eb0bf13d6e28b1aef
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Sometimes it's difficult to track the price of a product, with the
different discounts you can obtain.
Price of products might change often and it's very practical to track
the price at the moment of the order to verify that it's in line with
what you paid in the past.
Also hides the Forecast Report button when a new line is created (and
not yet saved) as the button is disabled anyway without any feedback).
New purchase history button will also hide at creation.
Task-2658786
closesodoo/odoo#78438
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before, when a foreign VAT fiscal position was used on a purchase order or sale order, no filtering was applied on the available taxes. We now make their behavior consistent with the invoices'.
Part-of: odoo/odoo#79144
A new field on tax groups makes it now possible for this group to be displayed under a subtotal label. If not set, this defaults instead to "Untaxed Amount", keeping the traditional behavior. This is intended for withholding taxes, which can now be implemented with negative taxes and a tax group with this field set.
To do that, this commit entirely refactors the way amount_by_group worked, and replaces it with a more complete json field called tax_totals_json. It also streamlines the way taxe totals are displayed on invoices, PO and SO and makes it so that a common code is called instead of copy-pasting the same block 3 times as before.
[IMP] purchase: always display tax totals by groups on purchases orders
Before, tax totals on purchase.order's form were not shown by group, and were instead all aggregated in a single "Taxes" category. The same went for the pdf export. The portal view, though, did show the totals by group. We now display the tax groups in the same way all the time.
closesodoo/odoo#74138
Task: 2457374
Related: odoo/enterprise#19802
Related: odoo/upgrade#2670
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Be able to search origin and move origin in a notebook page to avoid
issue if the origin is too long (in case of multiple MO with semi
finished products)
opw-2625476
closesodoo/odoo#75144
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Accrued liabilities, or accrued expenses, occur when you incur an expense that you haven’t been billed for (aka a debt).
For example, you receive a good now and pay for it later (e.g., when you receive the invoice). The same opposite approach for sales.
Why do accountants need such entries ?
- Accounting must give a fair view of the financial situation of a company. The loss/profit must be booked regarding the effective deliveries of goods/services, not on the paperwork only.
- On a fiscal point of view, if you want to be allowed to deduct a loss from your taxable basis, it has to be in the right period. If you didn't announce it on time, the loss might be rejected by fiscal authorities. Same goes for the augmentation of the taxable basis, it has to reflect real deliveries and not only paperwork.
was Task: 2555642
was PR #73707
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Steps to reproduce the bug:
- Go to purchase app > create a request for quotation
- click on confirm > Lock
Problem:
Date confirmation becomes invisible, and date order becomes visible
Solution:
As we have already confirmed the purchase order and the lock button only appears when the PO is confirmed,
it makes sense to leave the confirmation date visible
https://github.com/odoo/odoo/blob/13.0/addons/purchase/views/purchase_views.xml#L138-L139
opw-2612608
closesodoo/odoo#75014
X-original-commit: ebf6708b5962a54e9fbed133596dcdfdd204e33d
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Steps to reproduce:
- Create Bill from Purchase order
- Raise Refund for the Same Bill
Current Behavior before commit:
Field Unit Price is readonly in PO line as invoice is already created.
Expected behavior:
Price should be editable as Qty Invoiced is Zero after Refund.
With this commit, Price unit will be readonly based on `qty_invoiced`
closesodoo/odoo#74526
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Define `data-hotkey` on most used action buttons.
For the modals, the following keys are dedicated for "special"
actions:
- Alt+G: add
- Alt+V: save
- Alt+Z: cancel
closesodoo/odoo#73275
Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, suppose we have a scenario like below
Task-A:
Activity-1:
name: Email ( Today )
Assigned to: User-1
Task-B:
Activity-1:
name: Email ( Today )
assigned to: User-2
Activity-2:
name: Call ( Due in 3 Days )
assigned to: User-1
When User-1 goes through the systray 'Today' filter shortcut he gets both
Task-A and Task-B in the list instead of only Task-A. Indeed currently
activities are not filtered based on current user with its deadlines.
However purpose of systray is to indicate activities current user has to
perform instead of global activities.
After this commit activities will be filtered based on deadlines as well as the
current user. In order to achieve this behavior we needed to pass a domain like
[
('activity_ids.date_deadline','=', fields.Date.today()),
('activity_ids.user_id','=', 1)
]
And for that purpose we introduced a non-stored compute field with a search
method.
Task ID-2438822
COM PR odoo/odoo#72219
X-original-commit: f4eaf4d8fb2f97240201104dcd4fc7e2674bce02
Currently, to identify records based on state, in most of the list views we
use 'badge' widget on 'state' fields which can be decorated as needed.
However, for the list views, best approach would be to also add list
decoration along with 'badge' widget so that the whole line is colored
and it's easy for user to 'scan' the information
This commit improves the behavior adding decorations to several list-views.
To check the list of changes, kindly see the task specification
Apart from that, this commit also improves label of the module state from
'Not Installed' to 'Uninstalled'.
TaskID-2527119
closesodoo/odoo#71367
Related: odoo/enterprise#18587
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- set correct decoration-info attribute on purchase.order tree view, replacing unexisting states ('wait','confirmed') by existing ones ('draft','sent')
- Move the decoration-info from tree line to name field to comply with the new display standards
closesodoo/odoo#70158
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- Currently all menus are out of order in app switcher.
- For example, Sales app is 16 menu away from Accounting,
Social Marketing app is 25 menu away from Email Marketing, etc.
So, all menus should be reordered.
- This commit will reorder the menus of the app switcher in order to reduce
the distance between correlated applications,
and bring the most common apps upward.
- And in this commit we have left gap of 5 subsequent sequence for further new menus.
PR: #69984
TASK ID: 2513082
Related: odoo/enterprise#17989
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
1. add packaging to PO lines
2. packaging on PO/SO lines can be propagate to MO
3. add package type to packaging
4. on picking types, we can choose to only reserve full packaging. That
means if you want 1 pallet(100 units) and you have 50 units in stock. It
won't be reserved.
5. suggest suitable packaging for PO/SO/MO line according to the product
qty
Task-2357259
PR #68654
UPG PR odoo/upgrade#2444
* account, analytic, calendar, coupon, crm, crm_iap_lead_website,
delivery, digest, event, event_crm, fleet, gamification, hr,
hr_expense, hr_skills, im_livechat, lunch, mail, maintenance,
mass_mailing, membership, mrp, point_of_sale, pos_mercury, product,
purchase, purchase_requisition, sale_management, sales_team, sms,
stock, stock_landed_costs, survey, website_crm_partner_assign,
website_event_exhibitor, website_event_track, website_forum,
website_slides, base
This commit removes oe_edit_only labels and adds placeholder
on fields in form views from a lot of apps to minimize the
shift when switching mode.
task 2330101
Related fields are by default readonly and they should be when it
is possible. A editable related field will write on the related
model and will cause extra unwanted write of data. These unwanted write
can cause performance issues in some case (see odoo/odoo#63865).
Then remove the `readonly=False` of some related fields
(where it is useless):
- In 'mrp.workorder' (mrp): `working_state` and `production_date`
should be readonly.
- In 'purchase.order' (purchase): `product_id` should be readonly.
- In 'purchase.order.line' (purchase): `state` should be readonly.
- In 'product.supplierinfo' (purchase_requisition):
`purchase_requisition_id` should be readonly.
- In 'purchase.requisition' (purchase_requisition):
`product_id` should be readonly.
- In 'product.template' (stock):
`route_from_categ_ids` should be readonly.
- In 'stock.move.line' (stock):
`is_initial_demand_editable` should be readonly.
- In 'stock.move' (stock):
`product_tmpl_id` should be readonly.
- In 'stock.production.lot' (stock):
`product_uom_id` should be readonly.
- In 'stock.quant' (stock):
`product_tmpl_id` should be readonly.
- In 'stock.rule' (stock):
`route_sequence` should be readonly.
- In 'stock.change.product.qty' (stock):
`product_variant_count` should be readonly.
- In 'stock.return.picking.line' (stock):
`uom_id` should be readonly and also because it
is forced by `_prepare_stock_return_picking_line_vals_from_move`,
it should be related to the product uom not the one on the move.
task-2424248
account: the field was present twice in the view
purchase: was not using the right group, same as c9e8ec50ca1c
Fixesodoo/odoo#35073closesodoo/odoo#62910
X-original-commit: c3f0d0387f2cab7e45cd298858038be25e113185
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In 376891294 the default purchase.order view tree was changed to have
different view with dashboard.
But the current view referenced:
('parent.state', 'not in', ('purchase', 'done'))
which seems incorrect because an x2many view towards purchase.order
could currently only be used for purchase.requisition (doesn't have
purchase/done as state value) and stock.production.lot (doesn't have
state field) or a customization that might not have state field.
With this change, we copy what there was originally on this field.
opw-2381767
closes#62903closesodoo/odoo#62964
X-original-commit: 4628675caf37c1699d8c25fe2ff6ef8b7bbc72a0
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Purpose of the task is, user's get 'stuck' through onboarding because
of multi edit feature.
When records are selected user can't open that records just when they
leaves from multi edit/mass edition then that feature will works.
So in this commit, removing multi_edit="1" from some onborading
tree views.
closesodoo/odoo#61264
Taskid: 2373161
Related: odoo/enterprise#14578
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, There would be Traceback (AttributeError: 'bool' object has no attribute 'date')
on `Confirm Receipt Date` If order has no `Receipt Date`.
Now, Button `Confirm Receipt Date` will be hidden if there is not `Receipt Date` to confirm.
Closed#60222closesodoo/odoo#60723
X-original-commit: 6f37f489b065d5534709c0eaf6c647ab5ad469df
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, Button to Send Sample reminder was always visible which doesn't makes sense as It would work on saved record only.
Now Button will be hidden on unsaved record.
Fixes#58744closesodoo/odoo#59972
X-original-commit: 3cb26da782042ee391777ed15bcca4eef4a10677
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
As explained in issues-59664, the commit
f18bdc4fcf2b6b0bdb7699c3b2aa38d332301a84 add
readonly attribute in the `purchase.order.line` state field
to avoid to save bad `state` in the server (then the state of the
PO line != PO line).
But it breaks the feature to add product
when the PO is already confirm (the state will be 'purchase' and the
`product_id` is readonly when state == 'purchase').
To fix both issues, add a `default_state` in the context.
It will "bypass" the attrs of `product_id` and the state of PO
('draft') line won't be save because it is readonly.
resolve#59664closesodoo/odoo#59729
X-original-commit: 74780e95a2a3db9d9875aea7e644bf064ecf6b46
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
gawa-odoo