After removing the `sha_in` params a while ago, we get rid of
the deprecated `token_field` option.
- Make `token_field` a model attribute, so that each model can easily
define the token field that should be used, and it does not need
to be passed around all the time anymore.
- Rename `_special_access_object()` to `_has_token_access()`, much more
readable since it returns a bool
- Do not forward the `attachment_ids` keyword arg to message_post,
as it sometimes contains unrelated IDs (the helper is not meant
to post attachments anyway)
- Update callers accordingly
The command does not need to remove existing relations, as there is no relation
yet on new records. This saves one query per many2many field with that command
in a `create`.
Before this commit, and since the combination of new views + datepicker
library update, the datepicker opened at the top left of the window
when using it in a domain selector. It also could not be used at all.
This was because the current scenario occured:
1) Click on the datepicker
2) The datepicker triggers that it has changed on opening
3) The whole domain selector is rerendered
4) The datepicker computes where it should open... on basis of the
old destroyed domain selector
As the main cause of the problem here was the (2), this commit changes
the datepicker odoo widget to only notifies that it has changed when it
has really changed.
Purpose
=======
Steps :
- Blank DB (without demo)
- Install inventory, Sales
- Create some products + update qty + activate serial number from setting and create some products (I tried this step and faced traceback)
- Now try to install Purchase app
It gives traceback..
Specification
=============
As the field po_lock is defined on the res_company and a related field is defined on the res_config_settings.py file, modify the import order.
change the position of res.company file, so that fields of po_lock will define first and then it will not generate field's error in res.config.settings file.
Before this commit, the web client did not properly destroy field
widgets when updating a one2many after an onchange. This is rarely an
issue, because in general, there are no other field widgets besides the
row currently in edition. However, if we specify explicitely a widget,
or if we use a custom widget, it may be a problem.
- correctly update the pager when a record is added or removed
- destroy the widgets of the removed row when the user clicks on
'Cancel' when creating a new record
- ensure that the list always contains 4 rows (before this rev.,
in list views with less than 4 records, if the user created a
new record, then clicked on 'Discard', there were only 3 rows
left
- properly destroy field widgets when removed from the DOM
Note that the change of parent.parentID to parent.static is not a
bug fix, but it's better to use the key that indicates the type of
list element, instead of implying it from other attributes.
When you open the produce wizard, see all the move lines for a product
to consume with a serial number, we should only see the ones that have
not been already process.
When you are processing a MO or WO, you can set two times the same serial
number for the same product.
To avoid this behavior, we created a onchange on the stock move line to
warn the user when he enter two times the same SN. We also create a
constraint on stock move line to avoid having two times same SN in a
picking.
When you are processing a picking, you can set two times the same serial
number for the same product.
To avoid this behavior, we created a onchange on the stock move line to
warn the user when he enter two times the same SN. We also create a
constraint on stock move line to avoid having two times same SN in a
picking.
When processing picking containing moves without
quantity done and without initial demand. These moves
were moving automatically to a new backorder.
It was also possible to validate picking without
quantity done for all moves.
This commit raise an error if the user try to valiate
a picking with all moves without quantity done and without
initial demand. Or cancel all these moves if the picking
is validate with correct moves.
before this commit, when retrieving the price for a variant for the shop, a floor division was operated, giving out the wrong result.
Now, a standard division is operated
when coming back using the breadcrumbs.
The settings form view should always be displayed in 'edit' mode.
Before this rev., it was re-rendered in 'readonly' when the user
clicked on a link in a setting view (opening another view stacked
in the breadcrumbs), and then came back to the settings view using
the breadcrumbs. For instance, go to 'General Settings', click on
'Activity Types', come back.
- correctly update the pager when a record is added or removed
- destroy the widgets of the removed row when the user clicks on
'Cancel' when creating a new record
- ensure that the list always contains 4 rows (before this rev.,
in list views with less than 4 records, if the user created a
new record, then clicked on 'Discard', there were only 3 rows
left
- properly destroy field widgets when removed from the DOM
Note that the change of parent.parentID to parent.static is not a
bug fix, but it's better to use the key that indicates the type of
list element, instead of implying it from other attributes.
* account, maintenance, mrp, payment, point_of_sale, sales_team
Previous system was:
- `flex: 1 1 300px;` on kanban records
- If a specific record needs a different size, add custom style to
either change the `flex` rule or set a `min-width` for >=SM screens
Now:
- `flex: 1 1 auto;` and `width: 300px;` on kanban records
- If a specific record needs a different size, add custom style to
change the `width` rule.
This allows some standardization of the way to customize the suited
width and also allow lesser LESS code (as the previous version required
either the use of the flex mixin or the use of a media query).
Note:
- Also remove useless app record rule
- Also fix MRP Work Centers record width
Note2:
This system should be improved for version 12.0.
A product can have multiple included taxes (i.e. one by company).
When computing the product price with function _fix_tax_included_price,
only the taxes of the company should be considered. Otherwise it could remove
all the included taxes of all companies.
ps: When no company is set on the SO, all the taxes visible from the company of the user
are set for the product of the line. Same behavior as in _compute_tax_id.
Closes#19566
opw:770464
It exists a different behavior when moves do not have an
initial demand. It will not set the initial demand to the quantity
processed once the move is done. It will also not propagate the
extra quantities to next moves.
This commit modify _create_extra_move method in order to
use the same behavior than other usecases. It will create
a move without quantity done and without initial demand
(which do not make sense) but this move will be merged in
the new one and will not be visible for the user.
Olivier Dony