- 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.
When pickings are created or modified they will be automatically
'Marked as todo'. Draft pickings can still be created through the
'Planned transfer' link on the stock.picking.type kanban card.
Form views with a chatter in a dialog on a large screen are styled by
the side chatter feature. This is not a problem as it is made to be
automatically adapted whether a chatter is displayed or hidden, but
in-dialog only rules had to be adapted.
- Fix several contexts where the emoji popover was hidden by a webclient
element (control panel / ...). To solve this bug, the design has been
improved to not use popover but instead use custom design (better
integrated with new chatter design)
- Chat window is now still usable when a modal is opened
- Simplify chatter LESS
Before this commit, clicking on the button opened the emoji popover
then closed it immediately. This was because of a handler which said
that clicking on any part of the composer should focus the input
element. This is indeed required when the UI is blocked (thanks to
the `blockUI` function). Solution is to not force this focus when
clicking on any composer's button element.
To prevent breaking those two behaviors (blockUI focus and emoji), two
tests were implemented.
If the server was launched with ``--test-enable``, `routing_map` tries to load
the routing map of module `None`, which is the current module being tested...
After the refactoring of the wkhtmltopdf engine, the headers/footers are managed in a very different way to be able to call wkhtmltopdf only once. The subst JS function must select the right header/footer corresponding to the current page company. However, a <div> was suppressed during the process and then, some external customization might be ignored (see github issue for more details).
-issue: https://github.com/odoo/odoo/issues/19544
Changing the address type of a contact in the "Contact & Addresses" tab
could in some instance lead to a dead image (just visually, saving it
would not change it) because the image is set to something like
"data:image/png;base64,5.23 Kb" because of a combination of kanba/form
x2many view, onchange, the differences of field present.
In 9.0 this did not happen because the image was not a field in the form
view corresponding to a contact of the kanban contacts view.
In saa-15 thanks to bf26445 the image_small is different than image in
the kanban view and this got us out of the issue.
In saas-16 it is solved even further because new views only load missing
fields.
This commit just get out of the issue by preventing an update of the
records field (with bin_size which caused the issue of the image) when
opening the modal form view of a contact's contact.
Ideally we should solve this more deeply but this is dangerous code to
change (eg. removing the bin_size would solve it but this was done for a
reason and could affect performances) and the effect is just visual in a
very particular set of factors (if we save the form after the image is
dead, the previous image reappeared).
opw-765952
closes#19491
An update by a list of commands is now guaranteed to have at most three SQL
queries to update the relation, whatever the number of commands and records.
* account, hr, hr_recruitment, maintenance, mrp, sales_team, stock
Adaptation of https://github.com/odoo/odoo/commit/a79d83e436e5e965d59663d4a06a0f8a62d8f694 for saas-18 new colors.
Also change back all color defaults to 0 instead of 1 (see
mentioned commit: they were changed from 0 to 1 as in saas-16
the color was applied to kanban headers which had to be gray
(the old color 1) by default).
Also add default violet color for 'Customer Invoices' and 'Vendor Bills'
dashboards.
Before the new views (SAAS15 and before), the 'readonly' modifier was
kind of weird: a field which was in a readonly state was not saved (the
field was not present in the RPC), UNLESS it is a subfield (for a
x2many).
With the new views, we changed the semantics, to make it more consistent:
fields in readonly state are never sent to the server. This is a much simpler
semantic, but it may introduce some problems, when we actually want to
save the record. This is solved with a new attribute 'force_save',
where we explicitely have to declare which fields should be save, even
if they are in readonly mode.
In this commit, we simply add the missing force_save attribute to the
order line form view. This allow the user to create a new SO, add an
order line with some invoice line, and save the result (without this,
the server complains about a missing product_id field)
In python3, items() and keys() returns iterators.
Modifying a dictionnary while iterating on it may trigger an error:
dictionary changed size during iteration
Go to General Settings, click on 'Change Document Template', and
in the opened dialog, click on a template.
Before this rev., it automatically closed the dialog, which was
not really convenient.
This rev. introduces a new field widget (image_selection) for
this use case, and ensures that the dialog doesn't close when
a template is selected.
Test written by @mba-odoo
- Create a product with:
Product UoM: kg
Purchase UoM: lb(s)
Tracking: By lot(s)
- Purchase 100 lb(s), validate and receive picking (set lot 001)
- Return the picking
- Set the lot
The quantity to do is 45.36 instead of 100.
We make sure to convert the quant UoM (=Product UoM) into the
appropriate UoM.
opw-771930
In this commit, we make sure that if an onchange in a x2many modifies
another line, then the new data is properly shown. This is quite
tricky, because the field x2many ignores the full extent of the changes.
Also, we obviously want to preserve the editing state (focused field,
...)
So, what we actually do is to rerender the full x2many (minus the new
line) to make sure that we preserve the correct row order.
Note: thanks to MGE for the test and some preliminary work.
Since the rev. https://github.com/odoo/odoo/commit/2728fe1ec1ac7e99819d0f30f29a1814b00c82a4 the onchange create
command (0) send the virtual id as second argument. This argument is sent
back from the server and can then be used by the client.
As the client knows the virtual id, it can easily reuse the datapoint created
for this record and thus avoid creating a new one.
Creating a new datapoint can potentially lead to problems if the record has
for example specialData, that won't be kept.
Modifiers (eg. required, readonly, ... on a field) are computed after a
record has been changed. When loading a record they could be computed
based on x2many in a inconsistent state.
eg. on res.partner form, by defaut the email is required depending on:
[('user_ids','!=', [])]
but when switching from one record to another this was computed
wrongly based on the difference between the two records.
This change make the x2many when loading a record ready to be used as
soon as it is set to solve this issue.
forward-port: not needed after saas-15 thanks to framework views rewrite
fix#18239
opw-749483
closes#18815
The method _procure_orderpoint_confirm in stock/procurement is calld in sudo() by run_scheduler.
Even if this method receives the company as parameter, the company is not enforced for all
the processes trigerred into the method. i.e. If a PO is generated by the run of the procurements
the sequence used is the one of the admin's company and not the one for the given company.
To enforce the company to use, we force the company into the context if it's not the same as
the user's company.
opw:771851
Add a `peek` option in the bus event dispatcher polling in order to let
an external event dispatcher fetch the notifications and their
corresponding channels.
Cherry-pick of rev. f2f99dc091
qsm-odoo