When you import a record in Odoo, you can specify an id without
prefixing it by the name of the module. e.g. 'project_project_x'
The result of this is an empty string as module name.
(This value is valid for a required field...)
Plus, when you check metadata, you see 'false.project_project_x'.
Now, the default module name is '__import__' instead of an empty string.
We already have similar behavior with '__export__' triggered by
'export_data' method.
That operation was previously forbidden because it could be potentially costly as we may end up having to recompute the 'amount_residual' and 'amount_residual_currency' fields on a lot of account.move.line.
Basically, we now authorize it and manually handle the update of that field via a manual SQL query.
Was PR #19204. Was task 32125.
Most field widgets are synchronous, but some of them have to do extra
work before being ready (for example, the pad widget, or widget which
needs to lazy load JS/CSS files). Because of that, the new views have
been well tested with synchronous widgets, but not completely with async
widgets.
Some code depended upon the fact that the widget was ready immediately
after being created. This was incorrect, and is fixed in this commit,
by adding a new hook that is called in (basic) views after a widget is
ready (meaning, start and willstart are done)
With this commit, we change the behaviour of the web client with respect
to spaces in char fields. Most of the time, starting and ending spaces
have no value, and worse, make the data not so reliable.
After this commit, field char will trim by default (so, if the user input a
char as ' abc ', the string 'abc' will be sent to the server instead).
Note that this only applies when the value of the field is changed. If
someone open a form view, then switches to edit mode and save, nothing
will change.
This is the desired behavior most of the time. However, in some rare
cases, this is actually harmful. For example, if we trim the
'decimal_point' field, it will not be possible to enter a whitespace as
decimal separator. In those cases, we introduce a new attribute 'trim',
which allow the developer to desactivate that feature.
It regularly happens that people do not close their POS session for a
long time. When too many orders are linked to a session, the session
closing duration can therefore take a lot of time to execute. This leads
to timeout issues.
We add a label on the POS session Kanban view if it has been opened for
more than 1 day.
*board,sale_timesheet
This rev. changes the API of load_views, as it now assumes that
the given context has no longer to be evaluated. This is more
convenient that way, as we can now call load_views with contexts
that are dict, and not instances of the Context class.
instead of createView. This allows to log info like RPCs or
uncaught Odoo events even if we are not in a view.
Also remove the logLevel param from MockServer as it wasn't really
used.
Purpose
=======
As the 'function' tag is re-evaluated on the module update (even when noupdate="1"), the ir.model.data will be created a second time with the function 'create'.
This leads to the record deletion after the update when calling '_process_end'.
Specification
=============
Use '_update' instead of 'create' and '_update_dummy'.
- _update won't create another ir.model.data if it already exists.
- _update already calls _update_dummy to avoid the record deletion.
Instead of use the original string by default.
Currently odoo export a PO translation file using the logic:
"If there is not a translation then use the source."
This generate a false 100% of file translated for tools based on PO
files.
This commit change this logic to:
"If there is not a translation then use empty string."
Odoo import a PO translation file supporting empty string because
if a item is empty string odoo use the original source.
Closes#17925
Purpose is to be able to move mail tests in a separate module without
breaking other tests. It seems dependency is not real, only some data
to add. It is better to have self contained tests anyway.
Purpose is to be able to move mail tests in a separate module without
breaking other tests. It seems dependency is not real, only some data
to add. It is better to have self contained tests anyway.
Purpose is to be able to move mail tests in a separate module without
breaking other tests. It seems dependency is not real, only some data
to add. It is better to have self contained tests anyway.
Before this commit, whenever an ir_module_module that had been
installed/uninstalled at least once would be unlinked, an Exception
would be raised since the field module_id references an ir_module_module
and it is a required field.
This commit fixes this by adding an ondelete='cascade' to the field.
Fixes#20720
New feature:
- New Transparent tag visual (grey border & text, white bg),
- By default, newly created kanban tags are transparent,
- Tag's colorpicker has now a 'Hide in Kanban' checkbox,
to select the transparent color.
Toggling off 'Hide in Kanban' sets the color of the tag as follow:
- Previous color, if 'Hide in Kanban' was toggled on on the
same formview session.
- Color 1 (dark orange), otherwise.
The rev. odoo/odoo@ab900bb fixes an issue in mail which needed an include
on BasicModel and FormController. As this rev. has been done in a stable
branch, the includes have been done in an existing file.
This rev. correctly separates the includes in different files.
When trying to list db's, the db_user is searched and verified before
searching for the databases.
As it's enclosed in a db.cursor context manager, we can assume that
there is a db user at this very moment.
This commit uses a single query to find databases that belongs to this
cursor user.
Also, this commit adds a message in the logs when an exception occurs
to facilitate debugging instead of silently returning an empty list.
Rev [1] was intended to be applied when changing the lot of the produced
product on the manufacturing order, somewhere along the line the code
was also called when setting the lot_id on the work order. When used in
this context, it broke the reconciliation between the reserved move
lines and the temporary move lines because a lot_produced_id was wrongly
set.
We fix the issue by only applying the code on prod move. This is done by
checking if the move is a production one through the stock move, because
there we are able to differenciate the raw material and production move,
not on the move line where production_id is always set.
[1] 471115b06aFixes#20964
Before this fix, when adding the attribute delete=0
on a listview, it was still possible to delete records
via the menu 'Delete' in the sidebar.
After this fix, this should not be possible to delete
records when delete=0.
The attribute delete was hard-coded to true, as there was
a traceback when it was set to false. It was simply due
to a misplaced closing brackets that was hiding an
assignment, which resulted to calling a method on undefined.
Before this fix, when adding the attribute delete=0
on a listview, it was still possible to delete records
via the menu 'Delete' in the sidebar.
After this fix, this should not be possible to delete
records when delete=0.
The attribute delete was hard-coded to true, as there was
a traceback when it was set to false. It was simply due
to a misplaced closing brackets that was hiding an
assignment, which resulted to calling a method on undefined.
Before this commit, it was not possible to reexecute functions using the
_.throttle function in the same test (e.g. drag and drop two elements in the
studio tests).
Do not forward-port this after 11.0
After sending a message, if one switched in edit mode in the form view, the
created message disappeared.
This is because the model is not aware of messages (they are created through
their own routes, message are not handled as other one2many fields with commands)
and the widget was reset with a new datapoint instance when switching in edit mode.
In this rev. we keep the model informed of the new messages by directly writing
the message ids in the datapoint.
Note that the includes on FormController and BasicModel are one in the
form_renderer.js file to fix this issue in existing database without adding
files. Another revision will be done in master to add the correct files.
opw-781353
Purpose
=======
From product stat button (purchase) on click of purchase lines open Purchase line's form view, the view is not correct and it is not intended.
Specification
=============
Stat button of purchase orders in product form view, on click of line do not open form view of purchase order line only list view...not form view (restrict to open form view).
- Create manually an account move
- Add a line with a credit != 0
- Click on "Add a line" => crash
`line_ids` does not contain the credit since it was not filled in.
opw-782980
This commits make the computation of amount to invoice
and amout already invoiced on sale order line works
with invoice policy based on delivered quantities.
Before this, the upselling of delivered quantities
was not working: you were seeing the upsell amount
in the amount to invoice (qty delivered > qty ordered).
Notes:
- When a product is not delivered (qty delivered = 0), its
amount to invoice is zero too
- Draft invoice are not take into account really; they are
included at sale order price (discount on draft invoice does
not impact amounts to invoice/invoiced)
Also, when a SO in state 'draft' or 'cancel', its amount
to invoice should be zero, but its invoiced amount should
take all validated invoices into account.
Finally, more correct trigger are set on the compute
method, to trigger recomputation on right moment.
This commit also compute the 2 amount fields as sudo, since
the amount should not be dependent of access right of current
user.
To check those different points, this commit provide some
more tests with ordered and delivered product, SO cancelling,
upselling or delivery, ...
Thibault Delavallée